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 14:40:48 UTC