RE: DATATYPES: mental dump.

> >Similarly, in the S proposal, would not xsd:byte be a subProperty of 
> >xsd:short which is a subProperty of ...
> 
> Sure.

But only insofar as the value spaces are concerned. The lexical
space of a data type subclass is not necessarily a subset of
the lexical space of its data type superclasses. Though in the
case of xsd:byte and xsd:short, I think they are.


> >
> >>They can all be straightforwardly handled in RDF/XML.
> >>
> >>
> >>The S and CD proposals require that users conform to a given 
> >>'idiom', and are often incompatible with current common usage in 
> >>which literals are used to refer to things other than strings;
> >
> >
> >I know what you mean here, but I object to the term incompatible. 
> >Current RDF does not do anything about datatypes.
> 
> I said current USAGE, and I was going on what others have said about 
> people writing things like
> 
> Pat shoeSize "10" .
> 
> I know we don't currently have an official position on this, but I 
> thought it was a common observation that people do these wicked 
> things whether we say it is OK or not.

But if we had the definition

   shoeSize rdfs:range xsd:integer .

and the user making the above statement knows about that range
definition, then it's not really "wicked".

Granted, the statement re-expressed as

  Pat shoeSize [ rdf:value "10"; rdf:type xsd:integer ] .

or

  Pat shoeSize <xsd:integer:10> .

is more explicit and safe.

> >In one interpretation all literals denote strings, and if I have a 
> >property with value "10", then that's just fine.  An application can 
> >'know' that it should interpret that as an integer.  With for 
> >example, the X and S and DC proposals they can continue to do so. 
> >The datatype information is simply not represented in the RDF model; 
> >its encoded in the definition of the property.

I think that relying on property range constraints in this manner
is not going to address all cases and as my recent examples show,
in cases where non-locally typed literals are bound by inference
to superordinate properties, things blow up.


> ? That is what the P(++) proposals do; seems to me that is exactly 
> what the others fail to do. (??)

The X proposal doesn't fail to do this, and in fact could
be viewed almost as an extension of the P++ proposal, adding
to it a statement-centric model but agreeing that all components
of a statement (including literal objects) are nodes which may
serve as subjects of other statements.
 
> Well, see my response to Sergey on that example. That would only work 
> in that form if there was a datatype mapping from numerals to 
> kilogram weights, which is unlikely.

See my URV re-expression of Sergey's examples for how that
might be done in a generic manner.

Patrick

Received on Wednesday, 14 November 2001 05:17:34 UTC