W3C home > Mailing lists > Public > public-prov-wg@w3.org > October 2012

Re: [PROV-O] Proposed OWL change: Dealing with Issue 568 (hadRole)

From: Paul Groth <p.t.groth@vu.nl>
Date: Fri, 19 Oct 2012 20:17:09 +0200
Message-ID: <CAJCyKRo7_UwV3ALESTwR9m_wj5h=LD4QEjbqmpb0nXDvcWHTxA@mail.gmail.com>
To: Stephan Zednik <zednis@rpi.edu>
Cc: Daniel Garijo <dgarijo@delicias.dia.fi.upm.es>, "<public-prov-wg@w3.org>" <public-prov-wg@w3.org>
Hi Stephan,

I think you summarize the issue well. Maybe we should see what others think
about this choice.

Another solution would be to add a reminder about how inference works in
OWL... but maybe that's redundant :-)

regards
Paul


On Fri, Oct 19, 2012 at 7:59 PM, Stephan Zednik <zednis@rpi.edu> wrote:

>
>  On Oct 19, 2012, at 11:40 AM, Paul Groth <p.t.groth@vu.nl> wrote:
>
> Hi Stephan,
>
>  Here's the concrete issue: http://www.w3.org/2011/prov/track/issues/568
>
>  It seems the question is, do want want to make the inference you
> outlined?
>
>  I agree that all the relations that are allowed to have a role are
> influence but dm specifically doesn't list influence as something you can
> apply a role to. Thus, this is something you probably don't want to
> explicitly state.
>
>
>  I think right now the best argument for removing Influence from the
> domain is the confusion that it is causing.
>
>  From a modeling perspective I believe it is consistent with the DM, but
> confusion about the semantics of property domains is causing a great deal
> of stumbling on this.
>
>  We aren't saying that all influence relations can have a role, just that
> any relation (DM term) that has a role can be inferred to be an influence
> relation (which I believe is consistent with the DM text through
> inheritance of the relation 'type').
>
>  I think the issue here is trying to get the most reasoning possible
> while in the RL restriction.  Since Influence is the most specific
> RL-compatible super-class that covers all the role-able classes, that is
> the most detailed domain we can set that an RL reasoner will act upon.
>
>  I guess at this point I am ok with removing Influence from the domain,
> but I would argue that the current modeling is consistent with the DM.  We
> should make the change because the modeling causes more user confusion than
> the benefit of the inference.
>
>  --Stephan
>
>
>  cheers
> Paul
>
>
>
>
> On Fri, Oct 19, 2012 at 6:21 PM, Stephan Zednik <zednis@rpi.edu> wrote:
>
>>
>>  On Oct 19, 2012, at 10:03 AM, Daniel Garijo <
>> dgarijo@delicias.dia.fi.upm.es> wrote:
>>
>> Thanks Stephan, you are right. However the current problem is that it is
>> not consistent with DM.
>>
>>
>>  I think it is worthwhile to remember what a property domain in RDFS
>> implies.
>>
>>  rdfs:domain is an instance of rdf:Property<http://www.w3.org/TR/rdf-schema/#ch_property> that
>> is used to state that any resource that has a given property is an instance
>> of one or more classes.
>>
>>  With the currently modeling, a DL reasoner will infer that the subject
>> is an instance of the union class, and a RL reasoner will infer only that
>> the subject is an instance of Influence.  Since all of the classes in the
>> union class are specializations of Influence, the RL inference is not
>> incorrect or inconsistent with the DM, it is just not as precise as the DL
>> inference.
>>
>>  An RL reasoner
>>
>>  :ex prov:hadRole [ a prov:Role;  prov:label "example role"; ] .
>>
>>  Will infer the following statement
>>
>>  :ex rdf:type prov:Influence .
>>
>>  Which I do not believe is inconsistent with the DM.
>>
>>  --Stephan
>>
>>
>> I have been looking further, and there are other properties where we have
>> just
>> a union in the domain (e.g., qualifiedInfluence, wasInfluencedBy,
>> atLocation). In
>> these cases the properties would have an empty domain in DL. I think that
>> it's better
>> to have it empty rather than allow inconsitencies with the DM.
>>
>> Thus I still propose to make the change to the documents. Thoughts?
>> Best,
>> Daniel
>>
>> 2012/10/19 Stephan Zednik <zednis@rpi.edu>
>>
>>>  Looking at the domain of hadRole again, I believe what we have right
>>> now is the result of the RL++ compromise.  The current domain in DL would
>>> be the intersection of prov:Influence and the union of prov:Association and
>>> prov:InstantaneousEvent, which equates to just the union of
>>> prov:Association and prov:InstantaneousEvent.  In RL, the union is ignored
>>> so the domain would be recognized as prov:Influence.  There was no way to
>>> get the domain aligned with the DM under RL, so adding Influence was a
>>> fallback, otherwise the domain would be unspecified.
>>>
>>>  That is at least my recollection of why it is as it currently is.
>>>
>>>  --Stephan
>>>
>>>  On Oct 19, 2012, at 7:49 AM, Daniel Garijo <
>>> dgarijo@delicias.dia.fi.upm.es> wrote:
>>>
>>> Prov-o team:
>>> there seems to be a bug in the ontology, which Luc highlighted in the
>>> last telecon:
>>>
>>> prov:Influence is listed as domain of prov:hadRole, and this is not
>>> compatible
>>> with PROV-DM. I have checked the latest documents and the only changes
>>> to do are:
>>>
>>>    - Remove prov:Inflluence from the domain of prov:hadRole in the
>>>    ontology.
>>>    - Remove prov:Influence from the domain of prov:hadRole in the
>>>    Overview.html document.
>>>    - Remove prov:hadRole in the "described with properties" box in
>>>    Overview.html
>>>
>>> If nobody disagrees with these changes, I will commit them on Monday.
>>>
>>> Best,
>>>
>>> Daniel
>>>
>>>
>>>
>>
>>
>
>
>  --
> --
> 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
>
>
>


-- 
--
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
Received on Friday, 19 October 2012 18:17:37 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:58:20 UTC