Re: Datatyping issue, too many options?

Pat,

I pretty much agree with all you say, in particular that (1) and (3) are 
not the same.  I think any difference is one of emphasis and usage style.

I see (2) and (3) as being more similar - they both provide a way to use a 
literal to indicate a node denotes some value according to a datatyping 
scheme - in this case an integer represented by a decimal numeral.

So, bearing in mind your comments at the last telecon, my question for you 
would be:  is there a need for (3) that is not satisfied by (2)?

#g
--

At 04:53 PM 3/16/02 -0800, Pat Hayes wrote:
>>I can't remember if we agreed this was an issue:
>>
>>The latest datatyping proposal [1] provides three different ways to apply 
>>datatyping:
>>
>>(1) Sections 1, 5:
>>
>>    ex:Jenny ex:age "10" .
>>    ex:age rdfs:drange datatype:decimal .
>>
>>(2) Section 3:
>>
>>    ex:Jenny ex:age _:x .
>>    _:x datatype:decimal "10" .
>>
>>(3) Section 5:
>>
>>    ex:Jenny ex:age _:x .
>>    _:x rdfs:dlex "10" .
>>    ex:age rdfs:drange datatype:decimal .
>>
>>I think that options (1) and (2) cover the use cases that have been put 
>>forward.  I don't recall a use-case that needs (3), so this may be an 
>>issue to the extent that the proposal goes to some additional effort to 
>>support more options than may be really needed.
>
>3 is the case that corresponds to the version of idiom (1) where a literal 
>can denote its value. That was the original P-style idiom which is used in 
>DAML, for example. We have ruled out the P idiom, but case (3) above is 
>its substitute.  I think we need this in order to be able to do range 
>datatyping properly.  It isnt really fair to say that (1) and (3) are 
>alternative *ways* to do datatyping: they are the same way, but used for 
>different purposes. (1) imposes a check on lexical forms, (3) assigns a 
>value based on the form.
>
>>
>>(This presumes a slight weakening of one of the stated desiderata 
>>concerning uniform application of "local" and "global" typing 
>>idioms.  Effectively, option (1) is a "global" (or "remote") mechanism, 
>>which can also be applied locally.  Option (2) is a strictly local 
>>mechanism.  (3) might be viewed as a "global" (or "remote") variant of (2).)
>>
>><aside>
>>
>>(4) Another option, not explicitly part of the datatyping spec, but noted 
>>here for completeness since this is implicated by the non-datatyping 
>>elements of RDF schema:
>>
>>    ex:Jenny ex:age _:x .
>>    _:x rdf:type datatype:decimal .
>>     :
>>    (other properties for _:x, etc.)
>
>Right, but in this proposal, that would NOT invoke any particular datatype 
>checks. It just uses normal RDF schema reasoning about a class which 
>happens to be the one used by a datatype.
>
>>
>>which would be rdfs-entailed by:
>>
>>    ex:age rdfs:range datatype:decimal .
>>    ex:Jenny ex:age _:x .
>>     :
>>    (other properties for _:x, etc.)
>>
>></aside>
>>
>>....
>>
>>A very much lesser possible issue:  is the name "rdfs:drange" appropriate 
>>for its use to indicate allowable lexical forms?
>
>Well, I suggested that we change it to rdfs:dcrange in order partly to 
>make it even less similar to rdfs:range. The 'range' part does make some 
>sense, since it applies to the object of the property rather than the 
>subject, but I agree it is potentially confusing.
>
>Pat
>--
>---------------------------------------------------------------------
>IHMC                                    (850)434 8903   home
>40 South Alcaniz St.                    (850)202 4416   office
>Pensacola,  FL 32501                    (850)202 4440   fax
>phayes@ai.uwf.edu http://www.coginst.uwf.edu/~phayes

-------------------
Graham Klyne
<GK@NineByNine.org>

Received on Tuesday, 19 March 2002 11:07:53 UTC