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

Colleagues:

Watching this from the sidelines, as it were, I have a very bad  
feeling about what is going on here. This is a train wreck. None of  
these alternatives will support full interoperability in the sense of  
exchanging meanings transparently. We will have three distinct,  
incompatible, ways to represent what is possibly the simplest semantic  
notion ever invented, viz. a piece of plain text (four if we include  
rdf:XMLLIteral), and users will need a manual, or at least a booklet,  
to remind them which form to use under which combinations of  
circumstances. Simple information in elementary RDF will not round- 
trip between formats. The various WGs seem more concerned to protect  
their various home turfs than to try to achieve harmonization. This is  
how the semantic web will end, not with a bang but with a whimper (the  
noise made by an unbounded number of engines devoted to translating  
literal forms back and forth.)

This situation seems to have arisen from the use of rdf:text in OWL2.  
It is disingenuous to say that this is merely another datatype, and  
refer to D-entailment, as it has been made abundantly clear that  
rdf:text is intended to represent a change to a basic feature of RDF  
syntax, with consequences for simple entailment and hence for all of  
RDF entailment. Perhaps then we should, as a community, bite the  
bullet and agree either that this is a good change to RDF, and assign  
the relevant WGs the work of revising the RDF and SPARQL  
specifications accordingly, or else to that it is not a good change,  
and then require that OWL 2 eliminate it before proceeding to  
recommendation. I honestly have no axe to grind either way (though I  
devoutly wish that if the first road is chosen, that rdf:text be  
modified to remove the insane trailing '@' when there is no language  
tag), and I realize that either path involves a lot more work when  
everyone is exhausted. Nevertheless, I strongly believe that any of  
these compromises are going to create years of problems for everyone  
except us.  None of them will work.

Pat


On May 18, 2009, at 6:18 AM, Seaborne, Andy wrote:

> 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.
>

------------------------------------------------------------
IHMC                                     (850)434 8903 or (650)494 3973
40 South Alcaniz St.           (850)202 4416   office
Pensacola                            (850)202 4440   fax
FL 32502                              (850)291 0667   mobile
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes

Received on Monday, 18 May 2009 15:18:57 UTC