RE: HM.Frameworks: Physical Description

["Bullard, Claude L (Len)" <clbullar@ingr.com>]

In reverse order:  yes I posted after putting up the draft Schema fragments

that measurements were an issue.  Most systems use a naming system

then map that to a specific measurement system for conversions.  In one

of Grubner's articles, he mentions the principle of least ontological commitment.

There is also the old saw that one should not store anything that can be

calculated, but ...  All world maps have the problem of picking coordinate systems

and mapping these to local naming systems.

 

Understand, a correlative mechanism is fine as long as we can show an

application example that makes sense to a customer.  Correlatives among 

schemas and topic maps have a lot in common.   That's fine.

 

But before we do that, I am playing devil's advocate.  We

have a certain amount of work to do coming up and we should ask when

we are debating mechanisms of language if it is time yet, or is it preference.

Where we have a customer (say Albeck for hypothetical), we should be

looking at that material and asking what we provide.   It would be useful 

to look at EMOTE and comment.     For public safety,

were I your customer, I would ask questions relevant to that domain.

You will find there are some analytical systems in that domain that

may use probabilities and strength measures.   Others use strict

comparison and depend on human authority because of the requirements

of contesting assertions and the results of that.   The more we

try to make this a Semantic Web app, the further behind we are

likely to get on deliverable, IMO.  Why?  Because the Semantic

Web is work in progress too and though laudable, churning. 

Schemas are basically a done deal.  They have issues but that

doesn't slow us down.  RDF is a done deal, right?  So in terms

of tools, que bueno.

 

Now, if Physical Description is the current candidate for a data module,

we need at the very minimum to provide some delimiters about how

deep that goes.  Are we defining deep enough for identification
(a fairly shallow set), or for medical systems (possibly deeper 

than we can go soon).  The obvious candidates can be roped in very quickly

and these become information to use in the next set of examples.

That way, our example reflect work done and decisions made and

we don't have to use imaginary sets.   One might say that is

the Extreme Programming approach:  we posit something that

might work and integrate every week. 

Len Bullard
Intergraph Public Safety
clbullar@ingr.com
http://www.mp3.com/LenBullard

Ekam sat.h, Vipraah bahudhaa vadanti.
Daamyata. Datta. Dayadhvam.h

-----Original Message-----
From: Kurt Cagle [mailto:cagle@olywa.net]
Sent: Tuesday, August 28, 2001 2:33 PM
To: Bullard, Claude L (Len); humanmarkup-comment@lists.oasis-open.org
Subject: Re: HM.Frameworks: Physical Description

I'm just responding to a thread on this - the KindaLike is Sean's terminology <grin/>.

 

Seriously, all I'm trying to do is look at potential correlative mechanisms based upon specific relational operators. One potential arena where I can see something like this in play is in preference mechanisms, which I see as one specific region in which HumanML has definite applications. As I mentioned before, in some cases these measures are subjective, though I suspect there are relatively few areas where a more formal definition of a given measure couldn't be formulated. Consider color equivalences, for instance, where two reds may be fairly distinct from one another but is more alike than green and very much more alike than blue. If I describe someone as having red hair, for instance, and I want to draw a correlative link to another person with red hair, the like attribute would not likely be 1.0 (I have two daughters with red hair, and yet it is obvious looking at them that one is not the same shade as the others).

 

These don't have immediate bearing to the HumanML schema itself, only to the creation of correlative mechanisms between two instances of that schema.  In that sense, the discussions here are application oriented rather than schema oriented. However, having said that, I would think that correlative measures would make a great deal of sense in Public Safety issues, especially as it brings up another point that has been bothering me for a while. We need to be concerned about the nature of the measurements involved. Should units be introduced into the schema itself, and if so, how? Is it more reasonable to describe a map of units of a given type as a prolog block to any measurement indicators. For instance, it may be more reasonable to basically describe in the schema that a person's height measurement is given as being of type Length, and in the prolog all units of type Length are described as being in centimeters or inches. This makes it possible to make all measurements scalars without the ugly necessities of parsing out unit measures from strings. Note that this may have already been addressed. I'm somewhat backed up in my reading at the moment.

 

-- Kurt