Re: PROV comments from Clark&Parsia

Hi Paul, all,

It would be good to discuss this issue today at the teleconference.

I personally think the hierarchy of classes rooted at prov:Influence is 
an intrinsic aspect
of the design of prov-o. The group recently decided to create a parallel 
hierarchy of
subproperties rooted at prov:influence. These hierarchies happen to be 
an implementation of constraint
Inference 15 (influence-inference). Good, it's a bonus.

Luc




On 23/01/2013 17:24, Evren Sirin wrote:
> Hi Paul,
>
> The short summary is we are fine with all the responses from the WG
> except the response for "ISSUE-611 (comments on prov-o)" for which we
> request more clarification. See below for more details.
>
> On Mon, Jan 21, 2013 at 4:56 AM, Paul Groth<p.t.groth@vu.nl>  wrote:
>    
>> Dear Evren,
>>
>> First, thanks for your interest in PROV. We are really excited that Clark&
>> Parsia are looking at implementing PROV within Stardog.
>>
>> The working group has looked at the issues you raised and produced replies.
>> We divided your comment into four parts. You'll find the responses linked to
>> below.
>>
>> - ISSUE-611 (comments on prov-constraints)
>>      
> These changes address our concerns.
>
>    
>> - ISSUE-611 (PROV-CONSTRAINT Test Cases)
>>      
> We are happy with the changes to the tests and the explanation.
>
>    
>> - ISSUE-611 (comments on prov-o)
>>      
> Our comment was not regarding encoding of the constraints in OWL
> (which is not possible to do completely anyway) but about encoding the
> inferences in OWL. Right now, it looks like some of the inferences
> from PROV Constraints document is included in PROV-O. Specifically,
> Inference 15 (influence-inference) [1] and Inference 20
> (specialization-alternate-inference) [2] are included in PROV-O as
> subPropertyOf axioms. But other inferences defined in this document
> are not included in PROV-O which is a little confusing. For example,
> Inference 12 (revision-is-alternate-inference) [3] suggests another
> subPropertyOf relation (wasRevisionOf subPropertyOf alternateOf) but
> this is not in PROV-O. If the WG chooses to encode some of the
> inferences in PROV-O but not others, we would like to understand the
> rationale behind this decision.
>
>    
>> - ISSUE-611 (Test cases for other specifications)
>>      
> Our comment was regarding test cases that test different aspects of
> PROV specification other than validation such as inferences. Analogous
> to OWL test cases where there are tests of (in)consistency and
> (non-)entailment, there could be PROV test cases for just testing
> entailments (transitivity, inverses, etc. as defined in the PROV
> constraints document) in addition to the current tests that check
> (in)validity. Having said that, this comment is meant to be a
> recommendation for additional future tests and we are fine with the
> current set of tests.
>
>    
>> We hope these address your concerns. If you could do us a favour and
>> acknowledge that these responses either address concerns or do not.
>>      
> Best,
> Evren
>
> [1] http://www.w3.org/TR/prov-constraints/#influence-inference
> [2] http://www.w3.org/TR/prov-constraints/#specialization-alternate-inference
> [3] http://www.w3.org/TR/prov-constraints/#revision-is-alternate-inference
>
>    
>> Thanks again for your detailed comments,
>> Paul
>>
>>
>>
>>
>>
>>
>>
>>
>> On Fri, Jan 4, 2013 at 6:23 PM, Evren Sirin<evren@clarkparsia.com>  wrote:
>>      
>>> Hi all,
>>>
>>> We are working towards supporting PROV inferences and constraints in
>>> our RDF database Stardog [1]. Below are some comments about PROV
>>> specification documents that we identified while working on our
>>> implementation.
>>>
>>> * PROV Constraints
>>>
>>> 1. The flow control arrows in Figure 1 seem to be backwards.
>>> 2. Definition 2.1 seems to be missing the id on the right-hand side.
>>> 3. Since uniqueness constraints are ‘applied’ and can derive new
>>> atoms, it is misleading to call them constraints. The same applies to
>>> typing constraints.
>>> 4. The definition of enforcement of uniqueness constraints states one
>>> should apply the resulting substitution to the whole PROV instance.
>>> However, the scope of the variables is not sets of rules.
>>> 5. Inference 9 (wasStartedBy-inference) should be: IF
>>> wasStartedBy(_id; _a,e1,a1,_t,_attrs), THEN there exist _gen and _t1
>>> such that wasGeneratedBy(_gen; e1,a1,_t1,[]).
>>> 6. Inference 10 (wasEndedBy-inference) should be: IF wasEndedBy(_id;
>>> _a,e1,a1,_t,_attrs), THEN there exist _gen and _t1 such that
>>> wasGeneratedBy(_gen; e1,a1,_t1,[]).
>>> 7. Inference 15.4 should be: IF wasStartedBy(id; a2,e,_a1,_t,attrs)
>>> THEN wasInfluencedBy(id; a2, e, attrs).
>>> 8. Inference 15.7 should be: IF wasDerivedFrom(id; e2, e1, _a, _g, _u,
>>> attrs) THEN wasInfluencedBy(id; e2, e1, attrs).
>>> 9. Constraint 56 should be: IF hadMember(c,e) and
>>> 'prov:EmptyCollection' ∈ typeOf(c) THEN INVALID.
>>>
>>> * PROV-O
>>>
>>> PROV Ontology contains several axioms for inferencing but it does not
>>> cover all the inferences described in the PROV constraints document
>>> even though these inferences can be encoded in OWL in a
>>> straightforward way. We think these inferences are useful not just for
>>> validation but also for querying PROV documents. For this reason, we
>>> believe these inferences should be included in PROV-O.
>>>
>>> Here are some example OWL axioms encoding some of the inferences from
>>> PROV constraints document:
>>>
>>> # Inference 16 (alternate-reflexive)
>>> # IF entity(e) THEN alternateOf(e,e).
>>>
>>> :Entity
>>>     rdfs:subClassOf [
>>>         a owl:Restriction ;
>>>         owl:hasSelf true ;
>>>         owl:onProperty :alternateOf
>>>     ] .
>>>
>>> # Inference 17 (alternate-transitive)
>>> # IF alternateOf(e1,e2) and alternateOf(e2,e3) THEN alternateOf(e1,e3).
>>>
>>> :alternateOf a owl:TransitiveProperty .
>>>
>>> # Inference 18 (alternate-symmetric)
>>> # IF alternateOf(e1,e2) THEN alternateOf(e2,e1).
>>>
>>> :alternateOf a owl:SymmetricProperty .
>>>
>>> # Inference 19 (specialization-transitive)
>>> # IF specializationOf(e1,e2) and specializationOf(e2,e3) THEN
>>> specializationOf(e1,e3).
>>>
>>> :specializationOf a owl:TransitiveProperty .
>>>
>>> # Inference 20 (specialization-alternate-inference)
>>> # IF specializationOf(e1,e2) THEN alternateOf(e1,e2).
>>>
>>> :specializationOf rdfs:subPropertyOf owl:TransitiveProperty .
>>>
>>> * PROV-CONSTRAINTS Test Cases
>>>
>>> We appreciate as implementers the PROV-Constraints test suite. We
>>> would like to see test suites for the other operational parts of PROV,
>>> in particular for testing inferences separate from validation. This
>>> request arises from our general belief that interoperability with a
>>> formal spec is typically less high than interoperability with a formal
>>> spec *and* an executable test suite. Test suites are invaluable for
>>> implementations. Further, while we would like to see the test suites
>>> be made normative parts of PROV (since that gives a nice algorithm for
>>> resolving disagreements between spec test and test suite (i.e., tie
>>> goes to the test suite)), we would prefer non-normative test suites to
>>> no test suites at all.
>>>
>>> We identified the following issues in the following RDF test cases:
>>>
>>> * prov-o-class-Invalidation-PASS.ttl: At line 37, there are repeated
>>> semi-colons ‘;;’ which is invalid according to the Turtle grammar
>>> (neither [2] nor [3] seems to allow this).
>>> * prov-o-class-Collection-PASS.ttl: Invalid xsd:dateTime literals
>>> missing minutes and timezone identifier.
>>> * prov-o-property-hadMember-PASS.ttl: Invalid xsd:dateTime literals
>>> missing minutes and timezone identifier.
>>> * ordering-association2-PASS-c47.ttl: This test is marked PASS but it
>>> is inconsistent because the individual ex:ag is an instance of
>>> disjoint classes prov:Entity and prov:Activity.
>>> * prov-o-property-qualifiedCommunication-PASS.ttl: This test is marked
>>> PASS but it is inconsistent because the individual
>>> :writing-celebrity-gossip is an instance of prov:Activity but uses the
>>> property prov:wasAttributedTo whose domain is the disjoint class
>>> prov:Entity. Same argument is also true for the individual
>>> :voicemail-interception.
>>> * prov-o-property-qualifiedRevision-PASS.ttl: This test is marked PASS
>>> but it is inconsistent because the individual :draft2 is an instance
>>> of prov:Entity but uses the property prov:wasAssociatedWith whose
>>> domain is the disjoint class prov:Activity.
>>>
>>> We think following tests should not have been included in
>>> rdf-tests.txt because the invalid PROV-N constructs cannot be
>>> expressed in RDF and thus their RDF representation is valid:
>>>             unification-association-f4-FAIL-c23.ttl
>>>             unification-association-f5-FAIL-c23.ttl
>>>             unification-derivation-f1-FAIL-c23.ttl
>>>             unification-derivation-f2-FAIL-c23.ttl
>>>             unification-derivation-f3-FAIL-c23.ttl
>>>             unification-derivation-f4-FAIL-c23.ttl
>>>
>>> Best,
>>> Evren
>>>
>>> [1] http://stardog.com/
>>> [2] http://www.w3.org/TeamSubmission/turtle/#sec-grammar
>>> [3] http://www.w3.org/TR/turtle/#sec-grammar
>>>
>>>
>>> --
>>> Evren Sirin
>>> CTO
>>> Clark&  Parsia, LLC
>>> http://clarkparsia.org
>>>
>>>        
>>
>>
>> --
>> --
>> Dr. Paul Groth (p.t.groth@vu.nl)
>> http://www.few.vu.nl/~pgroth/
>> Assistant Professor
>> - Knowledge Representation&  Reasoning Group |
>>    Artificial Intelligence Section | Department of Computer Science
>> - The Network Institute
>> VU University Amsterdam
>>      
>    

-- 
Professor Luc Moreau
Electronics and Computer Science   tel:   +44 23 8059 4487
University of Southampton          fax:   +44 23 8059 2865
Southampton SO17 1BJ               email: l.moreau@ecs.soton.ac.uk
United Kingdom                     http://www.ecs.soton.ac.uk/~lavm

Received on Thursday, 24 January 2013 14:32:40 UTC