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.


> 
> 
>>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?


> 
> 
>>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.


> 
> 
>>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.

--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 08:56:05 UTC