Re: specializationOf and inference

('binary' encoding is not supported, stored as-is)
Hi Pierre,

In Prov, prov:Entities stand for aspects/views of things, not the things themselves.  

In your example, <#me> is a more general prov:Entity representing a person's whole existence and <#me-today> is a more specific one representing a part of that existence, so in particular we can infer <#me-today> :ssn "123456789" from <#me> :ssn "123456789".  You assert that :ssn is inverse functional, which means that since the two URIs have the same predicate value, then they are equal (owl:sameAs).  But this is much stronger than you want: it amounts to saying that the entity <#me> - presumably corresponding to a person's whole existence/timeline - is the same as <#me-today> which only refers to one day of that person's existence.

I think in PROV terms, what would work instead is the weaker constraint that if two URIs have the same :ssn then they are prov:alternateOf each other; this says that the two URIs are aspects/views of the same thing but not that they are the same aspects/views of that thing.  

Hope that makes some sense,
--James

> On Jul 26, 2017, at 5:37 PM, Stian Soiland-Reyes <soiland-reyes@manchester.ac.uk> wrote:
> 
> Thanks for your comments!
>  
> BTW - in PROV-DM the attributes of entities do *not* include the PROV relations, so the prov:specializationOf (and other PROV relations) are not directly inherited. (The whole purpose of specialization is to provide alternate histories or timelines of a thing)
>  
> In a way just the attributes “describing” the entity are inherited. So I think your N3 rule is a bit too simple.
>  
>  
> If you include OWL functional properties as part of these attributes, then you are combining two semantic schemes, mixing PROV Constraints and OWL.  I think the ‘easy’ way out here is to then use only OWL2 semantics – which in PROV-O do not imply anything from  prov:specializationOf on OWL level (beyond domain/range prov:Entity  and subproperty of prov:alternateOf).
>  
>  
> We did have a think about expressing the PROV Constraints in OWL – but wanted to keep that as an optional extra so it was not added to PROV-O and some of the constraints could be non-trivial in OWL2. Contributions welcome!
>  
> If you want to do a richer semantics integration of PROV Constraints and OWL then you have to ensure any OWL-reasoned “sameness” don’t leak over.  
>  
> -- 
> Stian Soiland-Reyes, eScience Lab
> School of Computer Science, The University of Manchester
> http://orcid.org/0000-0001-9842-9718 <http://orcid.org/0000-0001-9842-9718>
>  
> From: Pierre-Antoine Champin <mailto:pierre-antoine.champin@univ-lyon1.fr>
> Sent: 26 July 2017 15:35
> To: public-prov-comments@w3.org <mailto:public-prov-comments@w3.org>
> Subject: specializationOf and inference
>  
> Hi all,
> 
> I'm currently interested in using prov:specializationOf, as it seems to provide a weaker (and hence more flexible) "sameness" as owl:sameAs. Indeed, the "specializer" inherits the properties of the "specializee", but not the other way around (as would be the case for owl:sameAs).
> 
> More precisely, I interpret inference rule 21 [1] as the following N3 rule:
> 
>    { ?x1 prov:specializationOf ?x2. ?x2 ?p ?o } => { ?x1 ?p ?o }
> 
> So, from
> 
>   <#me-today> prov:specializationOf <#me> .
>   <#me-today> :mood :happy.
>   <#me> foaf:name "Pierre-Antoine".
> 
> I could infer
> 
>   <#me-today> foaf:name "Pierre-Antoine".
> 
> That's very well. But now, assume that I have
> 
>   :ssn a owl:InverseFunctionalProperty .
>   <#me> :ssn "123456789".
> 
> Similarly, I would also infer
> 
>   <#me-today> :ssn "123456789".
> 
> But this would also lead me to infer
> 
>   <#me> owl:sameAs <#me-today>.
> 
> which is precisely why I wanted to avoid :-(
> 
> 
> What is wrong in my reasoning?
> 
> 
> [1] https://www.w3.org/TR/2013/REC-prov-constraints-20130430/#specialization-attributes-inference <https://www.w3.org/TR/2013/REC-prov-constraints-20130430/#specialization-attributes-inference>
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

Received on Wednesday, 26 July 2017 17:00:20 UTC