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

Hello,

The idea was indeed to treat "abc" and "abc@"^^rdf:text as being identical --
that is, to map them into the same objects in the value space. The only
potential clarity problem I can see is in the notion of selection.

If I've understood RFC 4647 properly, the language-range production says that a
basic language range is either "*" or is not empty. Thus, one currently cannot
use the empty string in the rdf:langRange facet on rdf:text (because the empty
string does not match the language-range production). Furthermore, the "*" basic
language range matches only to strings with language tags. The latter seems
quite useful, as it can be used in languages such as OWL to specify the
"language tag required" condition. To summarize, the language tag selection that
we currently have in rdf:text does not provide for selecting strings without a
language tag.

I'm not sure, however, whether the latter is really needed: the xs:string
datatype already identifies the set of all strings without a language tag.
Hence, instead of using the rdf:langRange facet with the empty language tag, one
can just use xs:string.

Is that satisfactory?

Regards,

	Boris

> -----Original Message-----
> From: Phillips, Addison [mailto:addison@amazon.com]
> Sent: 27 March 2009 14:40
> To: Boris Motik; 'Jos de Bruijn'
> Cc: public-rdf-text@w3.org; 'Jie Bao'; 'Axel Polleres'
> Subject: RE: Further changes to rdf:text + a proposal for a change
> 
> BCP 47 says that the empty string is not a language tag, but that is not true
> of XML (and other W3C specs), where the empty value is permitted. In fact, the
> empty language tag has a number of useful properties, such as the ability to
> "mask" non-natural-language text off from acquiring an inappropriate language
> tag.
> 
> I don't have a problem with this change, provided that plain xsd:string
> objects are treated as if they were rdf:text literals with an empty language
> tag (and vice versa). That is these two:
> 
>    "abc" (s form)
>    "abc@"^^rdf:text (s, l form)
> 
> ... are treated as identical, can be selected using the empty language range,
> etc.
> 
> Addison
> 
> Addison Phillips
> Globalization Architect -- Lab126
> 
> Internationalization is not a feature.
> It is an architecture.
> 
> > -----Original Message-----
> > From: public-rdf-text-request@w3.org [mailto:public-rdf-text-
> > request@w3.org] On Behalf Of Boris Motik
> > Sent: Friday, March 27, 2009 3:41 AM
> > To: 'Jos de Bruijn'
> > Cc: public-rdf-text@w3.org; 'Jie Bao'; 'Axel Polleres'
> > Subject: RE: Further changes to rdf:text + a proposal for a change
> >
> > 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 15:00:26 UTC