- From: Birte Glimm <birte.glimm@comlab.ox.ac.uk>
- Date: Fri, 9 Apr 2010 16:27:50 +0100
- To: SPARQL Working Group <public-rdf-dawg@w3.org>

Hi all, below are my suggested text changes for the conditions on extensions to basic graph pattern matching. This is to address my open actions 212 and 211. http://www.w3.org/2009/sparql/track/actions/212 Propose change to unique specified extension criteria Old text: 1 -- The scoping graph, SG, corresponding to any consistent active graph AG is uniquely specified and is E-equivalent to AG. Proposed text: 1 -- The scoping graph, SG, corresponding to any consistent active graph AG is specified uniquely up to differences in the identity of blank nodes and is E-equivalent to AG. alternatively (uses RDF graph equivalence as also used in condition 4, see below): 1 -- The scoping graph, SG, corresponding to any consistent active graph AG is specified uniquely up to RDF graph equivalence and is E-equivalent to AG. http://www.w3.org/2009/sparql/track/actions/211 Email out the text change needed to weaken the finite answer criteria in SPARQL Query Old text: 4 -- Each SPARQL extension must provide conditions on answer sets which guarantee that every BGP and AG has a finite set of answers which is unique up to RDF graph equivalence. The condition has actually two purposes. 1) The answer set must be uniquely specified (up to RDF graph equivalence, blank node renaming) and 2) the answer set must be finite. We want to keep the first part and weaken the second part. Propsed text: 4 -- Each SPARQL extension MUST provide conditions, which guarantee that the answer set for every BGP and AG is uniquely specified up to RDF graph equivalence. The conditions SHOULD prevent trivial infinite answers such as those from axiomatic triples and infinite answers that just differ in the identity of blank nodes. Alternatively: 4 -- Each SPARQL extension must provide conditions on answer sets, which guarantee that the answers set for every BGP and AG is uniquely specified up to RDF graph equivalence. The conditions must prevent infinite answers from axiomatic triples and infinite answers that just differ in the identity of blank nodes. I prefer the first proposal. It uses should and mainly suggests which sources of infinity should at least be addressed. The second one uses MUST, but only mentions two sources of infinity and leaves others such as rule recursion and datatypes open, whereas the first one makes it a bit more explicit that the given sources are just examples that should at least be addressed. Depending on the reasoning power, one might have other trivial sources of infinity that should also be addressed. Other immediate sources in datatype aware systems are different but equivalent lexical forms, e.g., the graph with triples ex:a ex:b "1.0"^^xsd:decimal . and a query with BGP ex:a ex:b ?d has infinitely many answers under D-entailment when the datatype map includes xsd:decimal such as: ?d/"1.0"^^xsd:decimal ?d/"1.00"^^xsd:decimal ?d/"1.000"^^xsd:decimal etc. Currently only ?d/"1.0"^^xsd:decimal is returned as answer since only data values that occur in the active/scoping graph are being considered. Under OWL entailment, where you have logical negation and number restrictions, another source of infinite answers are graphs which say, e.g., Peter has at most 1 child, which entails that Peter has not at least 2 children, not at least 3 children, etc. and a query that puts a variable in place of the number will have infinite answers. It is questionable whether we want such infinite answers and the non-RIF regimes at the moment have conditions that prevent those. It is, however, impossible to give a complete list independent of the entailment regime in question. What we don't really want to prevent is the power of rules, e.g., if I have a rule set with the following rule and ground fact: if p(?n) then p(?n+1). p(1). Then I probably did that intentionally. Both proposed changes would allow this. They both also do not force conditions to prevent infinite answers such as those from OWL number restrictions and the different lexical forms of data values. The first proposal suggests to carefully consider the sources of infinity, which the alternative does not really do. Let me know if you have any alternative suggestions or preferences. Birte -- Dr. Birte Glimm, Room 306 Computing Laboratory Parks Road Oxford OX1 3QD United Kingdom +44 (0)1865 283529

Received on Friday, 9 April 2010 15:28:26 UTC