RE: A summary of the proposal for resolving the issues with rdf:text --> Could you please check it one more time?

Boris - thank you for the summary.



There seem to be 3 approaches around:

1/ Ensure that rdf:text is rendered in the RDF forms (@en etc) as it cross into RDF specs, not appearing across the entailment boundary or RDF graph exchange.  

2/ Transport it opaquely as a plain datatype with no meaning as a language to RDF.

3/ rdf:text is just used to give a name for the value space -- no lexical forms, no datatype mapping.


All these would seem to work (details to be worked out) although I have only come across (3) recently so I'm less up-to-speed on the implications.


(1)&(2) both respect the current RDF invariant that a literal has a language tag or a datatype, but not both.

(1) is safe and can be relaxed later presuming work to show how the RDF and rdf:text forms would be equivalent and not generate some differences.  It is as for the current LC test of rdf:text about graph exchange - there needs to be equivalent text in rdf:text on BGP-extension in SPARQL (roughly, the scoping graph has the RDF forms only in it). [*]

(2) is, almost by it’s very definition, safe for SPARQL and RDF.  It does lead to changes in meaning if rdf:text is then incorporated into RDF or relaxed in someway.  To work with lang tags in RDF originating data in OWL/RIF, the translation of the RDF forms to the rdf:text forms is required. The rdf:text document already requires such systems to convert RDF form to rdf:text form and to be able to work meaningfully with RDF data would continue to so it has elements of (1).

 Andy

[*] One aspect of the BGP extension mechanism is so that SPARQL can be extended to other entailment regimes without needing to go back to DAWG or SPARQL working groups.

Received on Monday, 18 May 2009 11:20:20 UTC