RE: RDF/XML Syntax problems with datatyping literals

> -----Original Message-----
> From: ext Dave Beckett [mailto:dave.beckett@bristol.ac.uk]
> Sent: 29 August, 2002 15:41
> To: w3c-rdfcore-wg@w3.org
> Cc: Stickler Patrick (NRC/Tampere)
> Subject: RDF/XML Syntax problems with datatyping literals
> 
> 
> 
> I've already mentioned a few times that using the rdf:type attribute
> to indicated datatyped literals is a bad idea *for the RDF/XML
> syntax*.  It is ambiguous and difficult to parse.  We should not be
> adding more ambiguity to the syntax, and I will oppose it.

Well, I certainly respect your intuitions on this matter, and
don't wish to debate the point to death, though I will offer still
just a few comments below.

> Here is what I consider a fatal case.
> 
> Consider a datatyped literal that has a lexical form which is the
> null string.  The datatype URI is, for example, 
> http://example.org/datatype1
> 
> So the RDF/XML proposed would be:
> 
>   <ex:prop rdf:type="http://example.org/datatype1"></ex:prop>
> 
> This is, by XML rules, equivalent to
>   <ex:prop rdf:type="http://example.org/datatype1" />
> but that's not the issue.
> 
> The problem is that this form already has a different meaning in the
> RDF/XML defined in M&S and the current draft.  An empty property
> element with property attributes is equivalent to the
> expansion below, which adds a blank node to hang the property off:
> 
>   <ex:prop>
>     <rdf:Description>
>       <rdf:type rdf:resource="http://example.org/datatype1" />
>     </rdf:Description>
>   </ex:prop>
> 
> which isn't what you wanted.  

Well, I'm not convinced that this is a problem. After all, if
they don't specify any lexical form at all, then all we *could*
use to represent the property value would be a bnode.

No, that's not particularly useful, but that's not really wrong.

They're just saying that the value is "something" of the 
specified type, and how else would we capture that than by
a bnode of the specified type?

If, however, they also specify a lexical form then we are
able to say what the value is more accurately in the form
of a typed literal node.

So I don't see that the above result is not what is wanted.

I.e, it doesn't seem to me to be a fatal case, but in fact
the correct result.

> If the lexical form is not the null string, say
>   <ex:prop rdf:type="http://example.org/datatype1">a</ex:prop>
> then that is bad syntax and will very likely break all 
> existing parsers.

I knew this, but was thinking it would be an easy thing
to support -- and of course, no matter what we call the
attribute, we'd have to expand the grammer to allow both
attribute and data content for the property element.

I.e. even if we use rdf:ltype, parsers will still break.

The only change to the parsing is simply licensing the
occurrence of the rdf:type attribute when there is also
data content, and in that special case, producing a typed
literal node.

Is that really all that ambiguous or difficult?
 
> This is better done using any new rdf: term such as rdf:ltype.
> 
>   <ex:prop rdf:ltype="http://example.org/datatype1">a</ex:prop>
> 
> which may either give a warning or error with a current parser as an
> unknown rdf: term, but should not be interpreted as a property. 

Well, the same warning or error will occur with rdf:type as well,
and rdf:type does precisely reflect the semantics, so if the
above case of an empty property element with rdf:type defined
is no longer a problem (and I don't think it is) than better to
use the most precise attribute rather than create a new one,
right?

> It can be defined to work something like xml:lang, i.e. sets a
> property (sic) of the contained literal.

Well, that would only be true if folks agree that literals are
now 4-tuples, but that doesn't seem to be a very popular
idea.

Also, if we end up not saying anything about the semantics of
untyped inline idioms, it's probably good to keep untyped literals
as 3-tuples and define the typed literal as something else.

Patrick

Received on Thursday, 29 August 2002 09:16:14 UTC