W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > January to March 2010

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

From: Ivan Herman <ivan@w3.org>
Date: Mon, 11 Jan 2010 10:09:15 +0100
Message-ID: <4B4AEABB.5030505@w3.org>
To: Andy Seaborne <andy.seaborne@talis.com>
CC: Axel Polleres <axel.polleres@deri.org>, SPARQL Working Group <public-rdf-dawg@w3.org>


On 2010-1-9 20:03 , Andy Seaborne wrote:
> 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
> 

I pretty much agree with that...

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

For direct semantics I may imaging a stricter requirement. For RDF Based
semantics (ie, OWL 2 RL) I would expect the same as for RDFS.

Ivan

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

-- 

Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF   : http://www.ivan-herman.net/foaf.rdf
vCard  : http://www.ivan-herman.net/HermanIvan.vcf



Received on Monday, 11 January 2010 09:08:39 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:41 GMT