- From: Boris Motik <boris.motik@comlab.ox.ac.uk>
- Date: Thu, 21 May 2009 11:33:07 +0200
- To: "'Seaborne, Andy'" <andy.seaborne@hp.com>, "'Alan Ruttenberg'" <alanruttenberg@gmail.com>
- Cc: "'Eric Prud'hommeaux'" <eric@w3.org>, <public-rdf-text@w3.org>, "'Sandro Hawke'" <sandro@w3.org>, "'Axel Polleres'" <axel.polleres@deri.org>
Hello, Please understand I am not an expert on SPARQL, so I don't know all the details there; therefore, I find input from experts really valuable. Given what Andy has said below, it seems to me that we already have a solution for the issues surrounding D-entailment regarding the rdf:text literals. Hence, we should be in good shape overall. In that light, it seems to me that there is just one issue in the rdf:text specification that might need addressing: do we want any special treatment of rdf:text literals during graph exchange? This relates to the following part of the specification: - In the Introduction, we have the following sentence: "Furthermore, when exchanging RDF graphs between RDF tools, typed rdf:text literals should be replaced with plain literals, thus maximizing interoperability between RDF tools that support rdf:text and those that do not." - In Section 4 we have the following paragraph: "Despite the semantic equivalence between typed rdf:text literals and plain literals in datatype interpretations, the presence of typed rdf:text literals in an RDF graph might cause interoperability problems between RDF tools, as not all RDF tools will support rdf:text. Therefore, before exchanging an RDF graph with other RDF tools, an RDF tool that supports rdf:text SHOULD replace in the graph each typed rdf:text literal with the corresponding plain literal. The notion of graph exchange includes, but is not limited to, the process of serializing an RDF graph using any (normative or nonnormative) RDF syntax." The question is what to do with those. I see the following possibilities: (1) Drop them. The rationale behind such a decision would be that, since rdf:text is a datatype just like any other, and since according to Andy SPARQL contains mechanisms for dealing with this, there is no real need to keep this text in the spec. (2) Leave them as they are. The rationale is that RDF tools should be "nice" to each other and should take into account that not all tools might support rdf:text and the related D-entailments. (3) Upgrade SHOULD to a MUST. The rationale behind such a decision would be that RDF tools should be "super-nice" to each other :-) I have a slight preference for (1): in general, I find the Occam's razor principle useful in technology. If things seem to work, don't tinker with them. Nevertheless, I would find both (2) and (3) perfectly acceptable. Regards, Boris > -----Original Message----- > From: Seaborne, Andy [mailto:andy.seaborne@hp.com] > Sent: 21 May 2009 11:19 > To: Boris Motik; 'Alan Ruttenberg' > Cc: 'Eric Prud'hommeaux'; public-rdf-text@w3.org; 'Sandro Hawke'; 'Axel > Polleres' > Subject: RE: A summary of the proposal for resolving the issues with rdf:text > --> Could you please check it one more time? > > > > > -----Original Message----- > > From: Boris Motik [mailto:boris.motik@comlab.ox.ac.uk] > > Sent: 20 May 2009 14:39 > > To: 'Alan Ruttenberg' > > Cc: 'Eric Prud'hommeaux'; Seaborne, Andy; public-rdf-text@w3.org; > > 'Sandro Hawke'; 'Axel Polleres' > > Subject: RE: A summary of the proposal for resolving the issues with > > rdf:text --> Could you please check it one more time? > > > > Hello, > > > > This is a purely SPARQL problem: SPARQL should specify precisely what > > the > > semantics of BGPs under the D-entailment regime is. > > > > > > I am just going to briefly speculate as to how this might be done. I > > strongly > > believe this should be done declaratively -- that is, without taking > > into > > account implementations. Hence, one might use the following definition: > > > > Given an RDF graph G and a BBP Q, a substitution s for variables in > > Q is > > an answer to G and Q iff G D-entails s(Q). > > > > Take the following example: > > > > G = { <a, b, "01"^^xsd:integer> } > > Q = { <a, b, ?x> } > > > > Then, the following substitutions are answers to Q over G: > > > > s1 = { ?x --> "1"^^xsd:integer } > > s2 = { ?x --> "01"^^xsd:integer } > > s3 = { ?x --> "1"^^xsd:decimal } > > s4 = { ?x --> "001.000"^^xsd:decimal } > > etc. > > The first SPARQL WG included a mechanism for other entailment regimes. This > framework allows any group to define their own entailment regime without > requiring some future SPARQL-WG exists or be running at the time. The > framework has an approach for this situation. > > Andy
Received on Thursday, 21 May 2009 09:34:41 UTC