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 19:40:02 +0200
Message-ID: <CAJCyKRprnrB_osjPAbzRAQpqmTq3MdWy4_XHZrdSf=XPaqr8Hw@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,

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.


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)
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 17:40:30 UTC

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