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


Help: OASIS Mailing Lists Help | MarkMail Help

humanmarkup message

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

Subject: Classification (WAS: RE: [humanmarkup] Re: [h-anim] HumanML Thoughts)

Also posted in the yahoogroups list. 

Hallo Rex! 

> -----Original Message-----
> From: Rex Brooks [mailto:rexb@starbourne.com]

> Actually, HumanML will benefit most from a spare, very functionally 
> practical h-anim 2001 spec that incorporates a way to let the current 
> segmented facial structure work for a continuous mesh face by either 
> allowing the segments to map to an envelope of vertices or translate 
> directly to a set of displacers for the vertices that correspond to 
> the segments, also an envelope.

An excellent thought my friend, but out of our current context IMHO. My
sincere apologies for not jumping in with a more positive attitude on
this; I just believe we have a lot more pressing matters than rendering
issues (we are supposed to be presentation neutral ;-) this is for an
application to handle - Hey I sound like a tape again).
A far more pressing need is classification. Taxonomies/Ontologies are by
far the most essential thing that HumanML will be using (whatever aspect
of Human Topics those may cover).

Besides this getting extremely pressing (again, as I see it at least),
it gets even more complicated. The problem is overlapping efforts. For
example, the W3C Ontology group.

We face a rather critical faze here. We will have to give priorities to
short term work, while also planning long term targets.

What we actually need in short is progress leading to real applications.

I suggest we start discussion on future directions. My quarter of an

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.

Of course, we also have to establish a list of deliverables before the
above get resolved. One has already been proposed but I am sure we can
be more efficient.

As all of as have understand by now, HumanML will not be a mythical
schema that will solve everything. HumanML will be a set of modules (hey
we had figured that out from day one), build with a lot of work.

Since we are a formal TC now, it is time to toss ideas on the table,
sort them out and assign to formed working groups. This is where each
one will The first round of this procedure will probably take long
enough for every one to share his thoughts. Members that have not joined
yet, will have plenty of time to catch up.

[1] http://www.oclc.org/oclc/fp/index.htm
[2] http://www.census.gov/epcd/www/naics.html
[3] http://anthro.palomar.edu/animal/default.htm
[4] http://www.dublincore.org
[5] http://www.w3.org/TR/2000/CR-rdf-schema-20000327/#s2.3.3

Kindest regards,


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

Powered by eList eXpress LLC