Re: Further changes to rdf:text + a proposal for a change

> Another problem is in the treatment of xsd:string. The old version of the
> document said that implementations MAY choose to make the value space of
> xsd:string be a subset of rdf:text. I believe that MAY should actually be a
> MUST. Without this, we could get into the following situation:
> 
> - The typed RDF literal "abc@"^^rdf:text would be interpreted as ("abc","").
> - Type plain RDF literal "abc" would be interpreted as "abc".
> - Clearly, the two literals would NOT be the same.
> - However, the typed RDF literal "abc@"^^rdf:text would be replaced with the
> plain RDF literal "abc", which would suggest that the two literals ARE the same.

it seems to me that this shortcut syntax should not be allowed if we go
for the MAY option.

> 
> This seems seriously flawed. Consequently, I have changed a MAY into a MUST.

I'm not so sure that I like this.  We would require specifications that
want to use rdf:text to interpret the string datatypes in a nonstandard way.

> 
> There is, however, a much nicer solution to the latter problem. We could change
> the value space of rdf:text such that it contains two types of objects:
> 
> - all strings, and
> - all pairs of the form ( s, l ) where l is a (nonempty) language tag.

I like this solution.  The only potential drawback I see is that we
cannot express plain literals with empty language tags, but I don't
think it is a serious issue.

> 
> In this case, rdf:text would *be* interpreted as the set of all plain RDF
> literals. That is, we would not need to fuss about with changing the
> interpretation of xsd:string: the very definition of the value space of rdf:text
> would contain the value space of xsd:string, as well as all plain RDF literals.
> Thus, we could just simply note this in the document and would not need any
> additional definitions. Furthermore, the XQuery functions that work on
> xsd:string would be readily applicable to the subset of rdf:text that does not
> represent strings with language tags.
> 
> The nice aspect of this solution is that rdf:text then just provides an explicit
> name for the set of all plain RDF literals, so we can't really be accused of
> changing anything.
> 
> The only downside is that the definitions of facets and some functions would
> become slightly messier, as they cannot treat literals with and without language
> tags uniformly any more. I think, however, that this is a small price to pay for
> the elegance that this solution brings.

Indeed a very small price to pay.


Best, Jos

> 
> Please let me know how you feel about this. If everyone agrees, I would like to
> make the change as soon as possible (preferably today) so that the document can
> be reviewed soon.
> 
> Regards,
> 
> 	Boris
> 

-- 
+43 1 58801 18470        debruijn@inf.unibz.it

Jos de Bruijn,        http://www.debruijn.net/
----------------------------------------------
Many would be cowards if they had courage
enough.
  - Thomas Fuller

Received on Friday, 27 March 2009 10:31:50 UTC