Re: entailment review - part 2

Thanks for your comments!
[snip]
>> > I am not sure, actually, condition 1. doesn't require consistency of SG, it only says:
>> > "The scoping graph, SG, corresponding to any consistent active graph AG is uniquely specified and is E-equivalent to AG."
>> >
>> > So, hmmmm, *actually*, this wording actually doesn't limit at all what the scoping graph to an
>> > inconsistent graph is: In fact, this even seems to let open that the SG for an inconsistent
>> > graph is e.g. empty, implementation dependent, etc.
>>
>> Well, if the active graph is inconsistent and the scoping graph is
>> E-equivalent to an inconsistent graph, then also the scoping graph
>> must be inconsistent. I don't see how a consistent graph can be
>> E-equivalence to an inconsistent one otherwise.
>>
> Hmmm, as I read it litereally: this condition only says that SG
> need to be uniquley defined for *consistent* AG. So, for inconsistent AG,
> this condition simply doesn't apply and thus it doesn't restrict SG it to be E-equivalent
> for inconsistent AGs, but rather doesn't restrict what SG is for inconsistent AGs at all...
>
> The spec says, at a later stage only that ...
>
>> > Still, the issue remains how to proceed with inconsistent graphs, since the behavior
>> > has to be specified for each extension:
>> >
>> >  "The effect of a query on an inconsistent graph is not covered by this specification,
>> >  but must be specified by the particular SPARQL extension."
>>
>>
> ... the effect of such inconsistency has to be specified and that
> is why I came to this conclusion:
>
>> > My (Axel- chairthatoff) interpretation of this 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 implementation-dependent (i.e. different
>> > for implementations that do or don't perform consistency checking.) So, the currently seemingly
>> > suggested path seems to be fine:
>> >  - implementations that don't do inconsistency checking can construct SG as for a consistent graph
>> >  - consistency-checking implementations should throw an error
>> >
>> > That is, I think the wording in the editors note is too strong:
>> >
>> > "[...] explicitly mentions that the scoping graph must be E-equivalent (RDFS equivalent in this case)
>> >  to the active graph and that AG must be consistent. "
>>
>> Hm, I disagree. See my arguments above.
>>
> Likewise :-)
> BTW, the other comments following below this point are non-critical for the moment, I think.

I'll try and get Ian to have a look at it. Firstly he is a native
speaker and secondly he has a lot of experience with W3C specs. If I
am wrong, I am happy to change that.

[snip]
>> > 6)
>> > I am not sure about Section 6.2 ... "The defined semantics allows for certain forms of higher order queries."
>> > What defined semantics do you mean? Actually the example says that such queries do not give results.
>>
>> I rephrased that paragraph. The "defined semantics" refers to the
>> entailment regimes. That is hopefully clearer now. Variables can bind
>> not only to elements of the domain (data values or individuals), but
>> also to sets of the domain, i.e., to classes or properties. This is
>> beyond standard conjunctive queries. What is still not allowed is
>> variables in the position of quantifiers. I hope the rephrased
>> paragraph is clearer.
>>
>>
> Hmmm, would you mind changing
> "The Direct Semantics entailment regime allows for certain forms of higher order queries."
> to
> "The Direct Semantics entailment regime allows for certain (but not all) forms of higher order queries."
> ?

Not at all, if changed that.

> Maybe what confused me was just that the negative example is elaborated fully, whereas the positive example
> (BGP ?x rdfs:subClassOf ?y) is just appearing as a side remark... maybe it would help to have that positive example fully elaborated, but can wait until next draft.

I see whether I can find the time tomorrow. Otherwise I'll do it after
the next WD.

[snip]

>> > 9) OWL specific comment to section 8:
>> >
>> > Wouldn't for the datasets a semantics that would take into account owl:imports make sense?
>
> I was probably mislead by owl:imports not being mentioned explicitly,
> when re-reading now at http://www.w3.org/TR/owl2-mapping-to-rdf/#Mapping_from_RDF_Graphs_to_the_Structural_Specification
> I am still a bit unsure,  since this speaks in section 3.1.1 explicitly about "retrieval" of the "document accessible from the IRI *:y"
> but it seems that section 3.2 of http://www.w3.org/TR/owl2-syntax/#Ontology_Documents actually allows that such
> "retrieval" may be definied for our purposes e.g. as that resp. graph being in the named graphs?
> either way, we may in the next version elaborate a bit more, although I agree with your conclusion that owl:imports seems
> to be addressed sufficiently with that.

I don't even think it is required that the imported graph is actually
in the named graph. It could be at some other place, but for computing
inferences that triples from the imported graph have to be taken into
account. That could mean that they have been added to the graph, but
it could also mean that the system stores them somewhere else as long
as they are taken into account that does not matter. We usually load
them into the ontology (graph) so that in the end we have one ontology
containing the merge of all relevant axioms.

In the next WD, I can add a further note on this.
Birte

Received on Tuesday, 12 January 2010 01:06:40 UTC