Re: specializationOf and inference

Stian, James, thanks for your answers.

Overall, they confirm my intuitions:

* my N3 "inheritance rule" is a bit too strong
* owl:inverseFunctionalProperty is, somehow, as "dangerous" as owl:sameAs

On 27 July 2017 at 12:12, Stian Soiland-Reyes <
soiland-reyes@manchester.ac.uk> wrote:

> 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.
>

I don't think that this is inherent to OWL.
I could very well, using pure OWL2, model a more complex world view with
"snapshot" resources. E.g.

  :Document a owl:Class . # the long-living document
  :Revision a owl:Class.   # a snapshot of a document at a given time
  :revisionOf a owl:ObjectProperty ;
      rdfs:domain :Revision ;
      rdfs:range :Document .
  :title a owl:DatatypeProperty ;
      owl:propertyChainAxiom (:revisionOf :title).

The last axiom states that revisions inherit the title of their document.
The big difference here (with prov:specializationOf) is that I have to
specify explicitly *each * property that can be inherited though
:revisionOf, so it is my responsibility to avoid inheriting IF-properties...

So it *is* possible in OWL to adopt a complex world view with different
"aspects / snapshots / alternatives" of the same resource.

However, and this is where I join you, most **vocabularies** are not
designed for this, and clearly, the definition of properties as inverse
functional limits the use of those properties to world views where there is
no such thing as "almost the same" entities...

So if I want to state the SSN of <#me>, I can not reuse a predicate from an
existing ontology if their author decided to make it an IF-property. I
would have to define my own notion of SSN, which is not inverse functional.

  pa


> 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 <jcheney@inf.ed.ac.uk>
> *Sent: *26 July 2017 18:01
> *To: *Pierre-Antoine Champin <pierre-antoine.champin@univ-lyon1.fr>
> *Cc: *public-prov-comments@w3.org; Stian Soiland-Reyes
> <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> 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 <pierre-antoine.champin@univ-lyon1.fr>
> *Sent: *26 July 2017 15:35
> *To: *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
>
>
>
>
>