RE: [humanmarkup-comment] RE: HM.VR_AI: Goals and Overview :HumanML_VR_AI Facilitator

[Manos Batsis <m.batsis@bsnet.gr>]

> -----Original Message-----
> From: Bullard, Claude L (Len) [mailto:clbullar@ingr.com] 

> I wouldn't do it like that because one would have to 
> microparse to get the value. 

I don't know what you would do or what microparse is supposed to mean
but I am sure that values like 5in, 25,6km, 34cc will become
unmanageable in no time.

> It would be a number in a simple attribute type.  
> It would not include the unit of measurement.  It would 
> also be a floating point and convert to metric.

It would just be a primitive. The schemata would specify the type and
implementation code would be triggered accordingly.

I think numbers mixed with strings are pure trouble and that what you
suggest is:
<foo property='5tm'>
1) figure out if 5tm is a number with a trade mark, a model code, a
measurement system (and what that is, custom systems come up every day)
or whatever and  (not a perfect example but I'm sure you get it)
2) get the number from the string then determine the type from the
string and if the process is successful
3) process the number accordingly

Just use primitives and specify both the primitive for an attribute and
the corresponding abstract type in your schemata, then use this info
from your application. Isn't that what XSD is about?

Kindest regards,

Manos


> 
> len
> 
> -----Original Message-----
> From: Manos Batsis [mailto:m.batsis@bsnet.gr]
> 
> Ok this isn't my territory but let's consider <smile  width="5in"/>
for a
> while. What is this 5in? It's not a number. It's not a string 
> (since you
> want to use the number in it, the string is useless to you.). What is
> it?
> Use XSD to define datatypes for the attribute values. Values 
> like 5in or
> 15sec are hybrids that will need extra processing to determine their
> actual use. Further more, we are drifting to a sea of 
> possible abstract
> datatypes here... I surely wouldn't want to be the one who's going to
> implement an application on these. IMHO, this is bad design (as it
> currently stands).
> 
> If I where to implement a smart agent (let's say in Java) for handling
> this data, it would be far more efficient to either base the 
> design on a
> concise model or at least strictly define the datatypes for each
> property.
>

 
Abstract datatypes should be handled by easy to implement add-ons to the
application while these should be called after reading the abstract
datatype in the property schema (um... RDFS) that mentions the code
implementation for this datatype.