RE: High-level comments on datatyping draft

> -----Original Message-----
> From: ext Sergey Melnik [mailto:melnik@DB.Stanford.EDU]
> Sent: 26 August, 2002 17:33
> To: w3c-rdfcore-wg@w3.org; Stickler Patrick (NRC/Tampere)
> Subject: High-level comments on datatyping draft
> 
> 
> 
> I think in the current draft a more clear separation between 
> the abstract
> syntax and the RDF/XML syntax is needed (the original RDF 
> spec suffered
> from exactly this problem). The first figure in Sec. 3.1 illustrates
> nicely what datatypes are about in the abstract syntax - they are
> first-class citizens in graphs. This point can be made earlier.

OK. Perhaps it would be good to have an initial "Datatyping in a Nutshell"
section that provides this up-front, and then explains it in detail in
the remainder of the spec. A kind of "Quick Glimpse for Gurus" so to
speak.

Or perhaps this would be something the Primer could provide?

> I'm also uneasy about nailing down the internal structure of datatype
> values as a 4-tuple or the like. I think literals should be 
> opaque wrt RDF
> abstract syntax. This makes the data model simple and appealing.

Well, the string-xmlbit-lang portions can be opaque, but the datatype
portion (either URIref or systemID) needs to be visible to the MT.

I originally defined literals as 3-tuples (per the Bristol f2f) and
then typed literals as structured objects consisting of datatype 
name (explicit or implicit) and literal, where the literal structure
would be opaque to the MT but the typed literal structure would not.

The reason I went with a 4-tuple is that the datatype denotation is
required, even if implicit as a systemID.

I'm quite open as to how the typed literals themselves are modelled,
so long as the MT works correctly.

What do you recommend?

> In addition, in implementations literals might be mapped directly to
> native types and not have any structure whatsoever. Insisting 
> that they do
> would make implementations more complex and less efficient.

Well, we've already agreed that literals have structure, the
string, xmlbit, and lang -- even if the latter two are irrelevant
to the DT MT and that structure is opaque to RDF in general -- and
applications will have to preserve that structure whatever their
internal representation. I see no reason why an internal struct
couldn't have fields for xmlbit and lang as well as native value
representation.

> It seems that all that business of rdfs:Datatype, value spaces and
> lexical spaces could be eliminated. What we care about are the value
> spaces, c'est tout.

I'm not sure I follow you here. We are stuck with lexical representations,
and thus mappings from lexical forms to values -- and thus we are stuck
with lexical spaces, mappings, etc. and rdfs:Datatype is the vehicle
by which we define those entities.

How would you capture datatype semantics otherwise? It already seems
to be defined as minimally as possible.

> Finally, I think that global datatyping (Sec. 3.2) is out of 
> scope of the
> current document.

Eh? Global datatyping has been in scope from the start and has never
become out of scope insofar as the desiderada and interests of the
WG as a whole (even if one or more proposals have omitted it). It
certainly is in scope, and is a key requirement. This also was recently
re-inforced by the CC/PP community and was an expectation of the
original RDF WG.

C.f.

http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2002Aug/0150.html
http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2002Aug/0111.html

So, yes, global datatyping is definitely within scope.

> At this point of time we do not have a mechanism
> robust enough to standardize on global datatyping. If we trash it the
> document might appear sparse. IMO a simple but beautiful incremental
> step is way better than a "lemon".

If the global datatyping as defined is a "lemon" then all RDF typing
is a "lemon". Global datatyping is really little more than RDF
typing as it is presently defined and used.

Can you perhaps elaborate on why you see it as a "lemon", and
are those then issues to be addressed for RDF typing in general?

Patrick

Received on Tuesday, 27 August 2002 03:06:37 UTC