- From: Boris Motik <boris.motik@comlab.ox.ac.uk>
- Date: Fri, 27 Mar 2009 10:41:24 -0000
- To: "'Jos de Bruijn'" <debruijn@inf.unibz.it>
- Cc: <public-rdf-text@w3.org>, "'Jie Bao'" <baojie@cs.rpi.edu>, "'Axel Polleres'" <axel.polleres@deri.org>
Hello, Unless I've misunderstood something, I don't think that plain RDF literals can have empty language tags: according to BCP-47 (as well as the older RDF 3066 cited by RDF), an empty string is not a language tag. So does this mean we have a consensus for this change? Can I just go and implement it? Regards, Boris > -----Original Message----- > From: Jos de Bruijn [mailto:debruijn@inf.unibz.it] > Sent: 27 March 2009 10:31 > To: Boris Motik > Cc: public-rdf-text@w3.org; 'Jie Bao'; 'Axel Polleres' > Subject: 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:42:38 UTC