Re: Summary of recent issues on current query spec (to be discussed in detail after current WD round)

Useful summary.

On 09/01/2010 2:08 AM, Axel Polleres wrote:
> This is a summary of some of the issues/errata to definitions in the current query spec
> that we stumbled over in some of the  discussions on entailment.
>
> While I don't think it makes sense to strive to resolve any of these for the next WDs,
> I'd keep them ready for discussion in one of the coming TCs after publication
> (Please let me know if I forgot anything or there are any other improvements/errata):
>
> 1) consistency requirement for entailment regimes
>
>   Issue text: For efficient implementations, it might be undesirable to enforce
>   consistency checking, e.g. for RDFS. So, in order to follow:
>   "The effect of a query on an inconsistent graph is not covered by this specification,
>    but must be specified by the particular SPARQL extension."
>   My (Axel- chairthatoff) interpretation is that I don't see that this implies that an
>   extension has to uniquely define the behavior on
>   inconsistent graphs, actually it could leave several options open (e.g. for implementations that
>   do or don't perform consistency checking.)

I thought we had already resolved this for RDFS.  The text in the doc is 
the result of that (I thought) consensus.

[[ Sec 3:
Inconsistency

If the queried graph is RDFS-inconsistent, an implementation MAY 
generate an error or warning and
SHOULD generate such an error or warning if, in the course of 
processing, it determines that the data or query is not
compatible with the request.
]]

[[ ENT sec 3.1.1
Please note that the above definition of the RDFS entailment regimes 
does not require that systems MUST generate an
error or a warning in the case of an inconsistency, but systems MAY 
generate an error or warning.
]]

so behaviour is not rigidly defined which is (my opinion) a good thing. 
  There's a steer ("MAY") but not a requirement. Or, colloqually, 
"garbage in, garbage out".  Hence I believe we have already addressed 
ISSUE-42

The same arguments apply for D-entailment but we have not agreed that.

I don't have an opinion about OWL (either semantics) although I think 
that requiring certain behaviours will not necessarily result in 
implementations following them in day-to-day use (e.g. OWL subsets on 
very large datasets).

> 2) uniqueness of scoping graph
>
>   The current spec of extending BGP matching requires uniqueness of the scoping graph, whereas actually the definition
>   of a scoping graph for simple entailment is only unique up to homomorphic (i.e. simple) equivalence:
>
>   "1 -- The scoping graph, SG, corresponding to any consistent active graph AG is uniquely specified and is E-equivalent to AG."
>
>   It is there fore discussed to clarify this condition, e.g.:
>
>   "The scoping graph, SG, corresponding to any consistent active graph
>   AG is uniquely (modulo simple equivalence) specified and is E-equivalent to AG."

Surely E-equivalence includes simple equivalence?  Otherwise the 
entailment regime does not build on this aspect of RDF.  That can be 
spelt out clearly.

>
> 3) Definition of RDF-B
>
>   ""The term RDF-L denotes the set of all RDF Literals, RDF-B the set of all blank nodes in RDF graphs"
>
> Hmmm, why "in RDF graphs" and in *which* graphs? It might be clearer/easier to simply drop "in RDF graphs",
> or to specify which graphs are talked about here.

Agreed.

>
> 4) Definition of Pattern Instance Mapping
>
>   Birte's suggested clarafication, cf. http://lists.w3.org/Archives/Public/public-rdf-dawg/2010JanMar/0029.html

Isn't it better to extend "RDF instance mapping" and "Solution Mapping" 
to apply to mapping patterns?

	Andy

>
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________

Received on Saturday, 9 January 2010 19:03:59 UTC