Re: RDF WG Resolution Regarding Various Forms of String Literals

[all Tos/CCs removed except for SPARQL WG and David Wood]

We need to discuss over email and tomorrow on our call how to approach 
this. Here are some miscellaneous thoughts -- I haven't studied this 
closely -- I guess that maybe Andy has thought about it significantly 
more than I have.

0) As a WG, are we OK with this decision by the RDF WG? Do we have any 
feedback to send to the other WG?

1) We ought to do whatever we can to make "foo" and "foo"^^xs:string 
parse as the same abstract thing (a typed literal with xs:string as its 
type) in SPARQL queries. I see two general approaches here, depending on 
_how_ the RDF WG implements their proposal.

   A) If they implement it by removing any mention of "plain literal" 
from their spec, then we need to do the same. This would be a pretty big 
change to SPARQL 1.1 Query, I think, and would also mean that SPARQL 1.1 
Query probably could not advance to Rec until the RDF WG documents do?

   B) If they implement the proposal by redefining "plain literal" such 
that it means the same thing as "literal typed as xs:string", then we 
may not need to make much change to SPARQL at all. In that case, SPARQL 
1.1 Query could proceed forward as normal, and once the new RDF 
documents were Recs, SPARQL's meaning would shift along with RDF's 
meaning. (This is my preferred method forward, but I don't know what the 
RDF editors intend, nor what's possible.)

2) We need to do something about the SPARQL Results XML Format. 
Specifically, we need to give guidance about how to serialize literals 
with type xs:string, since that's what all plain literals will now be. 
Perhaps the best path forward is to change this section:

"""
The value of a query variable binding, which is an RDF Term, is included 
as the content of the binding as follows:

RDF URI Reference U
     <binding><uri>U</uri></binding>
RDF Literal S
     <binding><literal>S</literal></binding>
RDF Literal S with language L
     <binding><literal xml:lang="L">S</literal></binding>
RDF Typed Literal S with datatype URI D
     <binding><literal datatype="D">S</literal></binding>
Blank Node label I
     <binding><bnode>I</bnode></binding>
"""

in 2.3.1 (http://www.w3.org/TR/rdf-sparql-XMLres/#results)

(That section is already a bit less rigorous then it could be, since it 
refers to "RDF Literal S" rather than "RDF Plain Literal S without a 
language".)

My personal preference would be that the XML results format suggest that 
implementations SHOULD serialize an RDF literal with type xs:string as:

       <binding><literal>S</literal></binding>

...excluding datatype="...string".

I'd prefer that this be a SHOULD and not a MUST.

We'll need a volunteer to make whatever change we decide here and to 
help with the publication process. We'll publish this as both a FPWD and 
LCWD in our next publication cycle.

Lee

On 6/15/2011 12:39 PM, David Wood wrote:
> Hi all,
>
> The RDF working group resolved our ISSUE-12 [1] today, which is intended to "reconcile various forms of string literals".
>
> We resolved to accept the proposal at:
>    http://www.w3.org/2011/rdf-wg/wiki/StringLiterals/AbolishUntaggedPlain
> with the modification that preferred output form (SHOULD) is "foo" not "foo"^^xsd:string in RDF; and we recommend that SPARQL and other WGs do the same.
>
> Discussion highlighted several possible areas of concern, which we believe the current proposal addresses.  Specifically, it was noted that:
>
> - The forms "foo" and "foo"^^xsd:string are equivalent input syntaxes.
> - The form "foo" is the preferred output syntax.
> - The WG suggests retaining the term "plain literal" in documents to avoid unnecessary rework.  Such plain literals would be considered semantically equivalent to xsd:strings.
>
> NB: This resolution makes *no statement* about language-tagged literals (e.g. "foo"@en).
>
> We invite discussion regarding the ramifications of this resolution to other working groups and implementors.
>
> Regards,
> Dave
>
> [1] http://www.w3.org/2011/rdf-wg/track/issues/12
>
>
>

Received on Monday, 20 June 2011 04:50:44 UTC