- From: Stian Soiland-Reyes <soiland-reyes@manchester.ac.uk>
- Date: Thu, 27 Jul 2017 10:12:20 +0000
- To: James Cheney <jcheney@inf.ed.ac.uk>, Pierre-Antoine Champin <pierre-antoine.champin@univ-lyon1.fr>
- CC: "public-prov-comments@w3.org" <public-prov-comments@w3.org>
- Message-ID: <D5780135E58FC940BDB87E7D499910184B41767D@MBXP14.ds.man.ac.uk>
Well it is not wrong with specialization – it’s just that OWL semantics does not have a temporal aspect, the statements are true inside whatever is the “world view” of the ontology (e.g. snapshot as of yesterday). A different snapshot is a different ontology. So to distinguish two different world views (just today or true since the 80s) should in a sense in OWL be in two different ontologies/RDF resources. Usually this is not a problem because we care more about what things are right now, than in the past – obviously for provenance more care is needed – e.g. a provenance document about a :stianEntity that describes my childhood “art” generation in the 1980s would be wrong to claim my name then as “Stian Soiland-Reyes”; as that is a more recent attribute value following my name change from “Stian Søiland” in the 2000s. And so with OWL inference one would have to be careful with how it is used with different PROV entities, e.g. :enrolled might have a domain :Student – but only the shorter specializing entity #me-student can be :enrolled at a university; the current #me is no longer a student. In a sense this means there is very little you can say about a long living entity like #me if you also want to use strict PROV and OWL semantics – as it would have to then be true for the whole entity’s lifetime. Basically such an entity can only be a “grandparent” of a series of shorter snapshot entities that are more easily described with fixed attributes – e.g. the #me covers the atoms appearing around #me-today as well as the slightly different atoms of #me-yesterday. In PROV we also wanted to support “scruffy” provenance so you are not required to declare all your atoms’ positions – so it’s perfectly fine to have just a long-lived entity with “snapshot” attributes – as is normally done in the semantic web descriptions – but then at the price that you can’t apply strict PROV and OWL Semantics against more specific entities. So in a strict semantics, wherever your specialization stop, there you can go scruffy. -- Stian Soiland-Reyes, eScience Lab School of Computer Science, The University of Manchester http://orcid.org/0000-0001-9842-9718 From: James Cheney<mailto:jcheney@inf.ed.ac.uk> Sent: 26 July 2017 18:01 To: Pierre-Antoine Champin<mailto:pierre-antoine.champin@univ-lyon1.fr> Cc: public-prov-comments@w3.org<mailto:public-prov-comments@w3.org>; Stian Soiland-Reyes<mailto:soiland-reyes@manchester.ac.uk> Subject: Re: specializationOf and inference 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<mailto: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 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
Received on Thursday, 27 July 2017 10:12:54 UTC