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

/me late to the game; found this conversation indirectly through mail
to my seldom-polled gmail account.

On Mon, May 18, 2009 at 10:17:44AM -0500, Pat Hayes wrote:
> 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.

I appreciate Pat's desire not to do things half-assed, but I think
rdf:text can work within a D-entailment which *never* manifests in
triples of the form "foo"^^rdf:text (option 1 below). (By "work" I
mean "have an awkward by survivable semantics which doesn't cause
us to lay down a new foundation".)

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

I promote this approach (as I understand it to mean that lexical form
of the notional ""^^ ). The text should say nothing about
serialization but instead RDF graphs. Consider the use case of the
OWLIM plugin for Sesame. If OWLIM forward chains some triples into the
Sesame repository with objects like "bob"@en, existing SPARQL queries
on the existing Sesame engine will match them as expected. RIF rules
can consume those triples and know that any rules applying to a domain
of rdf:text apply.

The minimal effort required for deployment would be that systems which
would act on rdf:text would be extended to apply those rules, either
reacting to, or generating, literals like "bob"@en .

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

-- 
-eric

office: +1.617.258.5741 32-G528, MIT, Cambridge, MA 02144 USA
mobile: +1.617.599.3509

(eric@w3.org)
Feel free to forward this message to any list for any purpose other than
email address distribution.