[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 euro: 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, Manos
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC