Re: PROV-ISSUE-267 (TLebo): annotate all subproperty axioms to justify them [Ontology]

On the general topic of using axioms to justify sub-properties (or to put it another way, using axioms to justify a property's super-properties), is there a specific property or set of properties we intend for presenting a justification?  Do we intend for a comparison of prov:definition on a property and it's super-property to be the justification?  Is a link into prov-dm considered justification?

I read the rdfs:comment and prov:definition on tracedTo and wasAttributedTo and I can make sense of the WG's justification, but I was also there for the discussion so I have prior knowledge.

Perhaps we should have someone not in the WG review the comments/definitions and see if the relationship is clear.

I compared the definitions of properties and their super properties and have noted my opinion on the clarity of the relationship

wasAttributedTo -> tracedTo (mostly clear)

Reader must relate ascribed (from wasAttributedTo) to responsibility (tracedTo)

wasDerivedFrom -> tracedTo (clear)
derivedByInsertionFrom -> wasDerivedFrom (clear)
derivedByRemovalFrom -> wasDerivedFrom (clear)
hadPrimarySource -> wasDerivedFrom (clear, but definition of hadPrimarySource is possibly out-of-date)
wasQuotedFrom -> wasDerivedFrom (clear)

Note: wasQuotedFrom comment is "An entity is derived from an original entity by copying, or "quoting", some or all of it.".  Suggest change "an entity is derived..." to "Entity was derived..."

wasRevisionOf -> wasDerivedFrom (clear)

Note: definition on tracedTo mentions responsibility, no sub-properties of tracedTo currently mention responsibility

Comments on earlier email below:

On Jun 4, 2012, at 7:10 AM, Timothy Lebo wrote:

> Stephan,
> 
> On May 31, 2012, at 3:39 AM, Stephan Zednik wrote:
> 
>> Hi Khalid, Tim, Paulo
>> 
>> I am reviewing the property annotations on sub-properties of prov:tracedTo
>> 
>> Comments:
>> 
>> 1) I think we should use rdfs:isDefinedBy to reference the latest PROV-DM document with an anchor to the section about the specific term.
> 
> That property usually links to a RDF vocabulary in practice, as suggested by the recommendation:
> 
> http://www.w3.org/TR/rdf-schema/#ch_isdefinedby
> 
> (that is, the following statement would not be appropriate:
> 
>       rdfs:isDefinedBy rdfs:isDefinedBy <http://www.w3.org/TR/rdf-schema/#ch_isdefinedby> .
> 

Ok, I see it now.  I agree, rdfs:isDefinedBy would not be the correct property to use here.

> 
> You don't like that we are using our own annotation property, prov:prov-dm ?
> We are defining it in our ontology [1] with a comment:
> 
>    <owl:AnnotationProperty rdf:about="http://www.w3.org/ns/prov#prov-dm">
>        <rdfs:comment xml:lang="en">A reference to the principal section of the PROV-DM document that describes this concept.</rdfs:comment>
> 
> [1] http://dvcs.w3.org/hg/prov/raw-file/default/ontology/ProvenanceOntology.owl

I am happy with a prov-X annotation properties as currently defined.  I missed their existence on my first pass since we are not utilizing them with tracedTo or its sub-properties.

I would recommend updating prov:tracedTo and it's sub-properties to utilize the prov:prov-dm annotation.

> 
> 
>> 
>> 2) Why define prov:category and prov:component annotations when a rdfs:isDefinedBy annotation would suffice and be easier for users to follow?
> 
> rdfs:isDefinedBy usually points to an RDF vocabulary that describes the predicate in RDF.
> 
> prov:category reflects prov-o's organization; 
> prov:component reflects the DM's.
> As annotations, they are intended to provide supplemental information.

Agreed.  I table the suggestion to use rdfs:isDefinedBy.

If we use prov:prov-dm to reference the relevant section in the PROV-DM document, is there still a justification for using prov:category and prov:component?

> 
> 
>> 
>> 3) Why define the prov:inverse annotation?  Either we define inverse properties or we do not, but suggestions via annotations are not very useful.  Tools and queries cannot be constructed around suggestions via annotations.  I understand the issue of constructing queries using inverse properties when an endpoint may or may not support reasoning of inverse properties, but why define an annotation that approximates (half-heartedly) an existing OWL axiom?
> 
> The prov-o team discussed this over several weeks during our telecons, and agreed about a month ago to what is now described in 
> 
> https://dvcs.w3.org/hg/prov/raw-file/default/ontology/Overview.html#names-of-inverse-properties
> 
> The prov:inverse property has a comment:
> 
>    <owl:AnnotationProperty rdf:about="http://www.w3.org/ns/prov#inverse">
>        <rdfs:comment xml:lang="en">PROV-O does not define all property inverses. The directionalities defined in PROV-O should be given preference over those not defined. However, if users wish to name the inverse of a PROV-O property, the local name given by prov:inverse should be used.</rdfs:comment>

I understand, this just stuck out as an odd decision when seeing the outcome of the decision after the fact.  The Appendix does help justify the decision quite well.

> 
> 
>> 
>> 4) There appears to be dual usage of the prov:qualifiedForm annotation.  It has been used to reference both the Involvement class and the property that references the Involvement class.  For example prov:wasAttributed to has a prov:qualifiedForm annotation referencing both prov:Attribution and prov:qualifiedAttribution.
> 
> Yes.
> 
>> Based on the description associated with prov:qualifiedForm, I think ti should only reference prov:Attribution.
> 
> If the description is inconsistent, then it needs to be updated to suit "pointing at both".
> Much of the prov-o automation is built around this "dual use".

What about having a qualifiedForm and unqualifiedForm?  Would that cause problems for the prov-o automation?

> 
>> 
>> Also, the comment on prov:qualifiedFrom should change 'prov:Involved subclass' -> 'prov:Involvement subclass'
> 
> I'll update. Thanks.
> 
>> 
>> 'This annotation property links a prov:involved subproperty with a prov:Involved subclass.'
>> 
>> should be
>> 
>> 'This annotation property links a prov:involved subproperty with a prov:Involvement subclass.'
>> 
>> This is an issue with prov:wasTracedTo and all its sub-properties.
> 
> I'll look at that.
> 
> Regards,
> Tim
> 
>> 
>> --Stephan
>> 
>> On May 1, 2012, at 11:57 AM, Khalid Belhajjame wrote:
>> 
>>> 
>>> Hi Tim and Paolo,
>>> 
>>> I updated the ontology to include annotations that justify the hierarchy of sub-properties. In particular, was wasAttributedTo, wasDerivedFrom, derivedByInsertionFrom, derivedbyRemovalFrom, hadOriginalSource, wasQuotedFrom, and wasRevisionOf. Regarding the properties involved and involvee, the comments used for their annotation justify the existence of their su-properties, so I don't think we need to add justification for each of their direct sub-properties.
>>> 
>>> Please let me know if you are happy with the update and accept to close this issue.
>>> 
>>> PS: Tim, I updated the ProvenanceOntology.owl, I notice that there is also another file called ProvenanceOntologyFull.owl. I didn't update this one.
>>> 
>>> Thanks, khalid
>>> 
>>> 
>>> 
>>> On 24/02/2012 06:05, Provenance Working Group Issue Tracker wrote:
>>>> PROV-ISSUE-267 (TLebo): annotate all subproperty axioms to justify them [Ontology]
>>>> 
>>>> http://www.w3.org/2011/prov/track/issues/267
>>>> 
>>>> Raised by: Timothy Lebo
>>>> On product: Ontology
>>>> 
>>>> all subproperty axioms need to be annotated to justify why they are subproperties.
>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>>> 
>>> 
>> 
>> 
>> 
> 
> 
>

Received on Monday, 11 June 2012 18:15:57 UTC