hadMember vs has_Element

[cmungall]

Member and element are synonyms in set theory. These seem to be used arbitrarily.

Why the past tense? What does it mean for a set of trees to have had some tree member in the past?

[hlapp]

hadMember comes from the PROV Ontology. It is being recommended here for the purposes of establishing provenance for collections of things, such as collections of trees from sampling posterior distributions of Bayesian phylogenetic inference. These collections are ephemeral, so it may not exist any more in a recoverable form.

[cmungall]

I can see the need for temporal qualification for collections like the Supreme Court, which change constituents over time. But the Supreme Court is not a set.

If SetOfTrees is a mathematical set then I recommend against using any wacky hadMember object property.

If it's not a set, then I recommend calling it something else. Use PROV "Collection" if you like PROV (personally I would not use Prov for anything other than provenance and perhaps not even for that).

Also - even if the collection is ephemeral, the property that connects a collection to its members can still be atemporal. If you really need to model the fact that a collection can change its members over time I would use something capable of representing this, not prov.

Either way, it seems an odd mixture, I suppose CDAO uses has_Element, and MIAPA uses hadMember. Surely it's confusing for users to mix and match this way?

[hlapp]

miapa:SetOfTrees is one of the things to be back-propagated to CDAO, where other cdao:SetOfThings are already (but sets of trees were apparently forgotten). So the naming is really a CDAO issue, not a MIAPA issue.

How the members are asserted for the purposes of comparative analysis use cases is a different story - that is in CDAO's hands, not MIAPA's. We could assert cdao:has_Element to be a subproperty of prov:hadMember, and thus have the provenance-relevant membership automatically inferred by reasoners that are capable of subproperty reasoning. However, as much as possible I'd like to stay compatible with simple RDF triple store reasoners, and often enough the fact that a consensus tree was derived from a set of trees is, and how that set of trees was obtained, is only interesting for provenance (in the scope of MIAPA), but not for comparative analysis (in the scope of CDAO), and thus such annotation will likely only be added at the step of adding MIAPA annotation. I.e., the subproperty reasoning typically won't buy anything.

Whether prov:hadMember is wacky or not is a discussion to be had with the authors of PROV. While PROV has its issues and may warrant further improvement (it is under public comment right now), I do believe it will eventually be widely supported. At least much more widely than other PROV models that have been in circulation (and which have, to the best of my knowledge, not been adopted by projects independent from their creators).

[cmungall]

I think I must be misunderstanding something. Are you saying that if I need to record provenance about axioms that use some object property P in their signature, then P must either be in PROV or a subPropertyOf a property in PROV?

If so then PROV will be unmanageable. If not, then why not use a more appropriate member-collection relation and use PROV orthogonally?

[hlapp]

This is about data provenance, not axiom provenance. Such as, how was a given phylogenetic tree generated. See this as an example: http://www.evoio.org/wiki/File:PetersGraphic.jpg

[arlin]

I'm rather confused by this discussion. The concept of sets was introduced several years ago in CDAO because we needed it in various ways, but mainly to assign annotations to instances of sets, such as a set of trees (e.g., Hilmar's example of a posterior distribution) or a set of sequences. A workflow might operate on a set S of 85 sequences (identified by some method), and then generate a set T of 1000 trees, and another method might take that set of 1000 trees as an input and produce a "consensus" tree C as an output. S, C, and T are all instances, and S and T are instances of sets (or they are sets of instances).

I do not understand the role of impermanence (the "hadMember" issue) in this. We need to be able to express that C came from an operation carried out on T, which came from an operation carried out on S. The idea that a tree could be "removed" from the set T at some later point in time doesn't make sense, because this has no effect on C, which already was computed. After the workflow has run and generated C, no human action changes what T ought to mean-- it is defined historically, solely for the local purpose of describing this workflow.

Or am I missing something? I'm not familiar with how Prov looks at history.

Arlin

On Mar 24, 2013, at 8:32 PM, Hilmar Lapp wrote:

This is about data provenance, not axiom provenance. Such as, how was a given phylogenetic tree generated. See this as an example: http://www.evoio.org/wiki/File:PetersGraphic.jpg

—
Reply to this email directly or view it on GitHub.

---

Arlin Stoltzfus (arlin@umd.edu)
Fellow, IBBR; Adj. Assoc. Prof., UMCP; Research Biologist, NIST
IBBR, 9600 Gudelsky Drive, Rockville, MD, 20850
tel: 240 314 6208; web: www.molevol.org

[cmungall]

I agree with Arlin.

Set theory has a well-defined semantics. When you start messing with it to include notions of once-was-a-member, always-a-member things get complicated. And from Arlin's response, it seems you don't need this anyway.

Provenance and set-membership are orthogonal concerns. I'm not sure why relations have to come from PROV in order to have provenance attached. You should take relations from the relevant foundational or domain ontologies and then apply provenance on top of that. You could use http://purl.obolibrary.org/obo/RO_0002350 - or the CDAO relation may also be fine, we can declare equivalence between the RO and CDAO relations.

On Apr 4, 2013, at 12:10 PM, Arlin Stoltzfus wrote:

I'm rather confused by this discussion. The concept of sets was introduced several years ago in CDAO because we needed it in various ways, but mainly to assign annotations to instances of sets, such as a set of trees (e.g., Hilmar's example of a posterior distribution) or a set of sequences. A workflow might operate on a set S of 85 sequences (identified by some method), and then generate a set T of 1000 trees, and another method might take that set of 1000 trees as an input and produce a "consensus" tree C as an output. S, C, and T are all instances, and S and T are instances of sets (or they are sets of instances).

I do not understand the role of impermanence (the "hadMember" issue) in this. We need to be able to express that C came from an operation carried out on T, which came from an operation carried out on S. The idea that a tree could be "removed" from the set T at some later point in time doesn't make sense, because this has no effect on C, which already was computed. After the workflow has run and generated C, no human action changes what T ought to mean-- it is defined historically, solely for the local purpose of describing this workflow.

Or am I missing something? I'm not familiar with how Prov looks at history.

Arlin

On Mar 24, 2013, at 8:32 PM, Hilmar Lapp wrote:

This is about data provenance, not axiom provenance. Such as, how was a given phylogenetic tree generated. See this as an example: http://www.evoio.org/wiki/File:PetersGraphic.jpg

—
Reply to this email directly or view it on GitHub.

---

Arlin Stoltzfus (arlin@umd.edu)
Fellow, IBBR; Adj. Assoc. Prof., UMCP; Research Biologist, NIST
IBBR, 9600 Gudelsky Drive, Rockville, MD, 20850
tel: 240 314 6208; web: www.molevol.org
—
Reply to this email directly or view it on GitHub.

[hlapp]

It seems to me we're talking past each other - I actually can't identify where I'm in disagreement with either of you, but it sounds like you're in disagreement with me.

So, to resolve this issue, can I start with first asking that the concrete change request to miapa.owl be stated. If we can't all quickly agree on making the change as requested or in some modified form, let's schedule a conference call to sort out the issue.

[cmungall]

MIAPA:

• Remove prov:had_Member
• Replace it's usage with CDAO:hasMember

CDAO:

• consider importing membership relationships from elsewhere (CDAO issue, not MIAPA)

On Apr 5, 2013, at 3:09 PM, Hilmar Lapp wrote:

It seems to me we're talking past each other - I actually can't identify where I'm in disagreement with either of you, but it sounds like you're in disagreement with me.

So, to resolve this issue, can I start with first asking that the concrete change request to miapa.owl be stated. If we can't all quickly agree on making the change as requested or in some modified form, let's schedule a conference call to sort out the issue.

—
Reply to this email directly or view it on GitHub.

[hlapp]

On Apr 5, 2013, at 6:54 PM, Chris Mungall wrote:

MIAPA:

• Remove prov:had_Member

prov:hadMember is currently used to make the following assertions:

cdao:SetOfNetworks subClassOf "prov:Collection and (prov:hadMember only cdao:Network)"
cdao:SetOfTrees subClassOf "prov:Collection and (prov:hadMember only cdao:Tree)"

(SetOfNetworks and SetOfTrees in reality are currently in the miapa namespace, but they will be pushed to cdao, as them missing from there is a CDAO issue)

Can you state succinctly why these two assertions are evidently wrong or unjustified.

Note that these assertions do not take the place of describing SetOfNetwork and SetOfTrees for the purposes of comparative data analysis. That domain is covered by CDAO, which makes corresponding assertions using CDAO properties, see the following.

• Replace it's usage with CDAO:hasMember

There is no cdao:hasMember. Do you mean cdao:has_Element? This is already asserted:

cdao:SetOfNetwork subClassOf "cdao:SetOfThings and (cdao:has_Element only cdao:Network)"
cdao:SetOfTrees subClassOf "cdao:SetOfNetworks and (cdao:has_Element only cdao:Network)"

(Again, these assertions are currently in miapa.owl, but they are slated to go into CDAO and will then be removed from miapa.owl)

CDAO:

• consider importing membership relationships from elsewhere (CDAO issue, not MIAPA)

The CDAO tracker is here: http://sourceforge.net/p/cdao/bugs/?source=navbar Would you mind filing it there?