RE: Comments on Datatypes almost WD and N-Triples for datatypes (was Re: A Dublin Core with RDF datatypes use case)

> -----Original Message-----
> From: ext Dave Beckett [mailto:dave.beckett@bristol.ac.uk]
> Sent: 22 August, 2002 13:09
> To: Stickler Patrick (NRC/Tampere)
> Cc: RDF Core
> Subject: Comments on Datatypes almost WD and N-Triples for datatypes
> (was Re: A Dublin Core with RDF datatypes use case)
> 
> 
> 
> >>>Patrick Stickler said:
> > 
> > Thanks, Dave.
> > 
> > Your examples are very similar to the ones I am now
> > using in the updated DT (almost) WD. I'll add them to
> > the DC use case appendix.
> > 
> > Pat is now reviewing the latest revision of the WD and
> > should post it to the list in time for Friday's telecon. In
> > the meantime, if anyone wants to see the latest snapshot,
> > it's at http://www-nrc.nokia.com/sw/rdf-datatyping.html
> 
> Hmm, it seems you are using rdf:type on literals which frankly I find
> disgusting ;)

Hmm, interesting, since that's what the semantics of typed
literals means (at least in the latest proposal from Pat and I).

Essentially, a typed literal denotes a member of the
value space of the datatype, and since the class extension
of a datatype is its value space, it denotes a member of
the datatype class.

It is analogous to

   <ex:friend rdf:type="&foo;Person" rdf:resource="#Bill"/>

which gives us

   _:x ex:friend Bill .
   Bill rdf:type foo:Person .

Since literals can't be subjects, we couldn't get 

   _:x ex:age _:y"25" .
   _:y"25" rdf:type xsd:integer .

even though that reflects the semantics of the typed literal, but
rather, we'd get a compact typed literal node such as

   _:x ex:age <&xsd;integer>"25" .

which, according to the datatyping MT, means the same
thing, where the typed literal node has an rdf:type of 
xsd:integer and denotes the value twenty-five.

An alternative serialization for typed literals, which could
avoid the rdf:type vs. xsi:type vs ???:type question could be

   <ex:age><xsd:integer>25</xsd:integer></ex:age>

which is analogous to

   <ex:friend><foo:Person rdf:about="#Bill"/></ex:friend>

This representation would allow the RDF parser to treat
xsd:integer as a Class, which is the rdf:type of the typed
literal, but also allows XML Schema validators to also
recognize the literal "25" as a lexical form of xsd:integer,
without recourse to using xsi:type, and allow folks to
use an XML Schema defining their datatypes to validate
typed literals. In the case of local typing, no special
steps need be taken other than defining the datatypes. In
the case of global typing, one need only defined the 
data content of the property elements per the particular
datatypes.

Thus, a typed object in RDF/XML must either have an rdf:about
or rdf:ID attribute, and be empty (a URIref node); or it must 
have neither rdf:about nor rdf:ID and have literal content
(a typed literal node). 

Eh?

> > In a nutshell, it's the stake-in-the-ground, but with the
> > explicit typed literal nodes and untidy literals (the latter
> > now being considered both a requirement of OWL as well
> > as being the majority preference of the RDF community).
> > 
> > Note that it is less than half the size of the previous
> > revision, owing to the fact that it is based on the
> > existing rdf:type and rdfs:range semantics.
> 
> Well, rdf:type above isn't being used in that manner.

It is. The WD probably then should be clearer about this.

An rdfs:Datatype is an RDF Class just like any other. It's
class extension is the value space of the datatype. So a
typed literal node, which denotes a member of the value
space of the datatype of course has an rdf:type of the
datatype class. Likewise, rdfs:range asserts that every
value of a property is a member of a given class, and in
the case of a datatype class, that means that every property
value is a member of the value space of the datatype.

So, rdf:type is being used exactly as it should in the
case of datatypes.

> > This updated (almost) WD should be considered a
> > proposal to be ratified by the WG and is not (yet)
> > presumed to reflect WG consensus. It's in WD form
> > to save editing time and effort so that when the WG
> > signs off on it, it's ready for publication.
> 
> Looks ok to me.  I'd like to see a list of (resolved/unresolved)a
> issues somewhere in an appendix, linked to WG decisions, if possible.

Good idea. I'll try to compile one.

> --
> 
> With respect to N-Triples changes for datatyping, I don't like using
> different quotes ' vs " - that's very prone to error especially in
> small fonts.
> 
> N-Triples has a "only 1 way to encode this" model and I'd like to
> keep that for now. The 'xsd:decimal' qname-like form gives two ways
> and since there is nothing in the RDF model or datatypes almost WD
> that requires this, I propose not adding it.

Yes. Absolutely. Sorry. I was thinking more pragmatically about
NTriples being a subset of N3 and how N3 might express typed
literals using qnames. I was not suggesting NTriples have qnames.
Sorry for not being clear on that.

In the case of non-XML literals, there's no problem. But if N3
adopts the NTriples convention of signifying XML literals by
prepending 'xml' before the double quoted string, then prepending
the qname directly to that can arise in ambiguity since the 
partition between the qname and the xml flag is ambiguous and
one cannot be sure whether the qname itself ends in 'xml' or
whether it is an XML literal.

So, if double quotes are used for both XML and non-XML literals,
some other syntax will be needed to maintain the explicit partition
between the qname and the 'xml' flag.

> In the future, it would be sensible to consider doing this (like N3)
> and use it throughout for all URIrefs including allowing defining the
> namespace prefix/uri-ref mapping (like N3) and so on.  But not now.

Well, while I agree that it's not an official concern of ours how
N3 represents things, I suspect that folks using N3 will be alot
happier with the datatyping solution if it lends itself to an
elegant representation in N3 as well as NTriples. No, it's not
something to get held up about, but worth thinking a bit about
as much as we can...

> So, keeping those in mind I give you the minimalist change:
> 
> non-XML literal                      "25"
> non-XML literal with lang            "25"-en
> URIref typed non-XML literal         
> <http://example.org/foo#integer>"25"
> URIref typed non-XML literal + lang  
> <http://example.org/foo#integer>"25"-en
> 
> XML literal                     xml"<a>Foo</a>"
> XML literal with lang           xml"<a>Foo</a>"-en
> URIref typed XML literal        
> <http://example.org/foo#a>xml"<a>Foo</a>"
> URIref typed XML literal + lang 
> <http://example.org/foo#a>xml"<a>Foo</a>"-en

That would work for NTriples.

I do wonder, though, if we could figure out a way to make the
XML and non-XML distinction compatable with direct concatenation
of qnames. 

But I can live with the above.

> I'd like clarifying if datatyped literals can have languages.  Please
> add this as an issue.  At present I don't see them, so the above
> <uriref>"25"-en and <uriref>xml"25"-en forms may not apply.

Well, in some cases, language could apply. E.g. 

   MyBook dc:title <&xsd;string>"The Tao of Foo"-en .

Clearly, most simple datatypes will not be language-sensitive, but some will,
so we have to be able to capture it. Many, if not most XML literals, I think, 
will be language sensitive.

I consider it up to the extra-RDF application to decide, based on
the semantics of the datatype, whether the language should be
discarded or not.

> Dave

Thanks for your comments, Dave.

Patrick

Received on Thursday, 22 August 2002 12:30:16 UTC