OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

humanmarkup-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Initial Phase 1 Documents


The most important thing is to ensure that we are all on the same page (or
in this case, the same Discussion List).

Hopefully with that being clear (;-)), we'll center on developing the
following deliverables that we should get to Working Draft status by
September 17th, 2001 (our first meeting).

Much work has already been done in the YahooGroups in these areas.  At this
stage, we will be formalizing the documents and ideas previously created, as
well as incorporating new ones.  These will set the tone for the TC, and
incorporates Manos suggested project progression.

Timetable:  Now until September 17th, 2001

    1) Domain:  Taxonomies to include (what is part of HumanML, what isn't)
    2) Applications:  What are the major application areas of HumanML
    3) Requirements:  What are the design features of HumanML (based on
Applications)
    4) New Deliverable Schedule:  (includes currently listed deliverables
[1] as well as additional applications, alternative classifications,
cross-correlation efforts)

If this sounds reasonable set of "pre-meeting" deliverables, then we can
start organizing our ideas in this fashion...So then, what *is*
HumanMarkup...?[2]



<manos>
1) Study current non XML popular classification systems (from DDC[1] to
NAICS[2] to "Classification of Living Things"[4] (interesting, includes
humans) to whatever we would like to focus on by building modules). This
would provide us with a jumpstart on any topic we might want to get our
hands in. It will also help transitioning existing knowledge bases.

2) HumanML will be used mostly as metadata (let's not argue on the term
context now ;-). I think it is wise to formally import existing
namespaces (e.g. the Dublin Core [4]) to provide interoperability. Of
course this import can be hidden or even extended. For example, we can
define properties of type dc:creator with more specific context. This
can be done via rdfs:subPropertyOf [5] (thanks Sean! Will anyone believe
I had the absurd idea to use XML names for this functionality...
Sheesh). You got to love those OOP concepts in RDF.

3) Define requirements. Per module probably.

4) Develop our own classifications. Different people will head towards
different ways on this, but it is expected and wanted.

5) Start working on real applications. This sector is much dependent on
the above three.
</manos>

[1] http://www.oasis-open.org/committees/humanmarkup
[2] http://groups.yahoo.com/group/humanmarkup


-----
Ranjeeth Kumar Thunga
HumanMarkup Chair
rkthunga@humanmarkup.org
(646) 456-9076





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC