Actions 211 and 212: proposed changes to the extensions of basic graph pattern matching

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