RE: some review comments on datatype draft

> -----Original Message-----
> From: ext Frank Manola [mailto:fmanola@mitre.org]
> Sent: 26 August, 2002 16:10
> To: Stickler Patrick (NRC/Tampere)
> Cc: w3c-rdfcore-wg@w3.org
> Subject: Re: some review comments on datatype draft
> 
> 
> Patrick.Stickler@nokia.com wrote:
> 
> > 
> snip
> > 
> >>2.  there are a number of paragraphs that say something 
> more or less 
> >>similar to this (some in greater detail), such as this one 
> >>from section 2.3:
> >>
> >>"RDF datatyping is primarily concerned with the implicit or 
> explicit 
> >>designation of typed literal pairings. RDF datatyping only 
> >>provides for 
> >>the designation of typed literals. The internal structure and 
> >>semantics 
> >>of all datatypes are opaque to RDF; i.e. membership of value 
> >>and lexical 
> >>spaces, datatype mappings, etc. have neither representation nor 
> >>interpretation in RDF. Actual interpretation of typed literals 
> >>(determination of the actual value denoted by the typed literal) is 
> >>performed externally to RDF by applications which have sufficient 
> >>knowledge of the particular datatypes in question. RDF 
> >>datatyping only 
> >>provides the datatype context within which such 
> interpretation is to 
> >>take place."
> >>
> >>Maybe this is just me, but it seems to me this could be 
> clearer.  The 
> >>point, if I understand it correctly, is that RDF datayping 
> >>defines a way 
> >>to associate an RDF literal with a URI that identifies a 
> data type in 
> >>some type system.  
> >>This allows RDF to provide a form of 
> >>metadata about 
> >>the literal (what someone intends its data type to be), but 
> >>the role of 
> >>RDF is limited to indicating the association between the 
> >>literal and the 
> >>datatype.  RDF itself doesn't actually define any data types, 
> >>or define 
> >>the value that is denoted by an RDF typed literal.  The 
> value must be 
> >>determined by some application that uses the RDF-supplied 
> >>association, 
> >>together with its own knowledge of the type in question.  Right?
> >>
> > 
> > Right. But RDF does define certain aspects of the nature of those
> > datatypes, such that an RDF processor can know that given a pairing
> > of datatype and lexical form, that pairing consistently denotes
> > a specific value and every time that pairing is encountered the
> > same value is meant. RDF can't tell you what the value is, but
> > it can tell you there's only one of them for a given pairing
> > of datatype and lexical form and it will always be that particular
> > value.
> > 
> 
> 
> That's fine, but I think the point you make above in 
> particular needs to 
> be made much more clearly, as it might not be clear that that 
> is one of 
> the ramfications of the mechanism.

Right. I'll work on the verbage.

> 
> > 
> > 
> >>Section 1.4:
> >>
> >>[I made this comment at the telecon] I think it would be 
> >>clearer if the 
> >>first example would *not* use these abbreviations;  write the whole 
> >>thing out once, and then abbreviate.  In particular, it needs to be 
> >>clear that the reference to the data type is a URI.
> >>
> > 
> > I've adopted the use of full N-Triples in all the examples, which
> > I hope will make this clear. Let me know what you think (I'll post
> > the revised version shortly).
> 
> 
> OK
> 
> 
> > 
> > 
> >>Section 2.1:
> >>
> >>I don't want to keep riding this hobbyhorse, but is "RDF 
> >>datayping" part 
> >>of the "RDF" language or the "RDFS" language (OK, I won't use 
> >>"processor" unless I have to!).  The "rdfs" prefix here 
> suggests that 
> >>it's part of RDFS, and so does Section 5, but is it really?  
> >>
> > 
> > I consider it a layer above RDF and RDFS. It uses rdfs:range
> > semantics to assert the rdf:type of property values, which in 
> > the case of implicitly typed literals can provide the datatype
> > context for proper interpretation. Thus
> > 
> >       -------------------
> >       | RDF Datatyping  |
> >       -------------------
> >       |     RDFS        |
> >       -------------------
> >       |      RDF        |
> >       -------------------
> > 
> > 
> >>For local 
> >>datatyping anyway, it seems that RDFS is not required.  (Are these 
> >>separate languages or not?)
> >>
> > 
> > Well, I don't know if I'd call them separate languages,
> > but yes, separate layers. Since the only new term is
> > rdfs:Datatype, it seemed rather silly to create yet another
> > namespace such as rdfd: just for it.
> 
> 
> I'm not worried about what namespace it's in, I'm worried about being 
> clear concerning how many languages we're defining (and, if 
> folks will 
> pardon the expression, how many combinations of languages people will 
> think they might be able to build processors for).  My idea 
> was, before 
> datatyping, we were defining two languages:  RDF, and RDFS, 
> the latter 
> extending the former.  You could provide RDF content without 
> using the 
> RDFS vocabulary, and a processor that said it was an RDF 
> processor would 
> have to be able to correctly interpret any such RDF content.  
> Other RDF 
> content could include RDFS vocabulary, and an RDF processor would 
> interpret that RDFS vocabulary as referencing additional 
> resources, and 
> using additional properties, but the RDF processor wouldn't 
> attach any 
> special meaning to those other resources and properties (as an RDFS 
> processor would).  So in my idea, we had two layers.  Now we 
> have three, 
> and your diagram suggests that "vanilla" support for RDF does 
> not need 
> to support datatyping, even of the local variety where 
> rdfs:range is not 
> used.  Moreover, "vanilla" support for RDFS will not have to support 
> datatyping, even of the global variety.  Is that correct?

I think so. Yes.

Leaving the representation of typed literal nodes as an aside
for a moment, datatyping is really just an application of the
semantics of rdf:type and rdfs:range. Datatypes are simply
RDF classes (instances of rdfs:Class) and a literal node has
an rdf:type of that class. The class extension, in the case
of a datatype class, is its value space, and thus the literal
node denotes a datatype value.

Now, in addition to that, there is the "extra" semantics about
datatypes themselves. That they also have a lexical space and
an N:1 mapping from the lexical to value space -- and that the
string portion of the literal node constitutes a lexical form,
a member of that value space, which maps to the value that
the node itself denotes.

So, yes, datatyping is a clean layer on top of RDF and RDFS.

Now, as for the representation of typed literals, that is
happening at the lowest RDF layer, and so in that way,
datatyping is requiring a modification to the graph syntax
to provide for explicitly and implicitly typed literals.

Where before we had "LLL", we now have ddd/"LLL" where
ddd may either be an explicit URIref or an implicit
system identifier (similar to a bnode label).

The result is that the untidyness of literals is captured
in the label, and one can generically assert tidyness on
all graph nodes according to their labels. But once that
extension/refinement is made to the graph syntax, RDF
processors can work happily with total ignorance of RDFS
or Datatyping, etc. since below the datatyping layer, those
typed literal labels are functionally opaque.

> 
> > 
> > 
> >>Section 3:
> >>
> >>Echoing Dave I think:  I don't like rdf:type as an attribute 
> >>(right idea 
> >>semantically, but wrong syntactically).
> >>
> > 
> > Feel free to suggest an alternative. It seems to me that using
> > some other term would only obfuscate the semantics. After all,
> > the datatype *is* the rdf:type of the typed literal node, so
> > why not call it what it is?
> 
> 
> Actually, I think the issue is largely independent of particular 
> alternatives (I seem to remember several have been suggested).  As I 
> said, I agree with you about the semantics;  my point was I suspect 
> using rdf:type as both a property and an attribute will obfuscate the 
> syntax.

But rdf:type is already allowed to be an attribute. 

Consider the analogous local typing of a URIref denoted resource:

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

which gives us

   ?s ex:friend <#Bill> .
   <#Bill> rdf:type ex:Person .

How is that any different from the analogous local typing of
a datatype value (resource):

   <ex:age rdf:type="&xsd;integer">10</ex:age>

???

These look pretty similar to me, both semantically and syntactically.

So, if using rdf:type as an attribute in this manner is obfuscating,
then RDF is already obfuscated, and using it for local datatyping 
does not further obfuscate the syntax. This is just taking an existing
legal form of expression and extending it to work with literals in
addition to URIrefs. 

No?

> 
> > 
> > 
> >>It would be helpful in Section 3 to have some explicit 
> discussion on 
> >>using datatypes *other* than those from XML Schema (lest 
> >>anyone think we 
> >>weren't serious about not building data types in).
> >>
> > 
> > Great idea. Any suggestions for examples?
> > 
> 
> 
> I'll see if I can come up with something.  However, unless 
> I'm mistaken 
> it seems to me just a matter of inventing some URIs to identify types 
> from a given type system (Java?) and using them in a short example.

Yeah. I've used Scheme datatypes before in discussions, because
the lexical grammar for integers allows one to specify different
base notations, etc. So that perhaps would provide a good contrast
also with xsd:integer.

I want to see the core technical aspects firm up first, though,
before I put alot of work into additional examples and whatnot.

Cheers,

Patrick


> --Frank
> 
> 
> 
> -- 
> Frank Manola                   The MITRE Corporation
> 202 Burlington Road, MS A345   Bedford, MA 01730-1420
> mailto:fmanola@mitre.org       voice: 781-271-8147   FAX: 781-271-875
> 
> 
>

Received on Monday, 26 August 2002 09:23:19 UTC