Re: actions related to collections

Hi Stephan

Some. Comments below.

Professor Luc Moreau
Electronics and Computer Science
University of Southampton
Southampton SO17 1BJ
United Kingdom

On 19 Apr 2012, at 00:13, "Stephan Zednik" <zednis@rpi.edu<mailto:zednis@rpi.edu>> wrote:


On Apr 18, 2012, at 4:20 PM, Luc Moreau <L.Moreau@ecs.soton.ac.uk<mailto:L.Moreau@ecs.soton.ac.uk>> wrote:

Hi Jun,

So, if I understand you correctly, the only thing you would like to see
is a relation eg. member(c,e) expressing that e is a member of c.

We should remember that we are defining a provenance ontology, and
to me, collection-specific relations should be "subrelation/specialization/refinement"
of other existing relations in the model.

Given that collections are themselves entities, than the only Entity x Entity relation
we have that make sense here is a derivation.

I think you lost me here.  Collections are not derived from their members and members are not derived from collections they are part of.


If it's the case, then this is also the justification for not having membership relation in a provenance ontology.

However I am not sure it is always the case. E.g. A data structure is in a given state because of what I put  in it.


You can infer entity existence if it is stated to be a member of a collection... but what do we gain from that?


So, member(c,e)  implies wasDerivedFrom(c,e)
meaning that to generate collection c we needed e.

'Derived from' simply means 'must logically exist'?  I thought it carried more meaning than that.


The weakest form of derivation is that c just depends on the existence of e.


That is workable I believe. It's a new relation in the derivation component.

However, if you want to be able to say that set c was changed into c1,
by adding/removing another entity, then you need further relations.

As to your question, what would happen if you have optional key,
I am not too sure. Currently, we have only one entity associated with one key.
You are in fact suggesting a set of entities for one key.

I think he is asking if we can relax our existing dictionary structure (making keys optional) to support more general collections.

I would say not.

Keys should be required in Dictionaries and we shouldn't try to use dictionaries to model generic collections.


Fine.

Luc

--Stephan

I am not too sure what would happen then.

Luc


On 18/04/12 22:41, Jun Zhao wrote:
Luc and all,

Apology if I destroyed any proper threading!

I want to say that I absolutely agree that the current collection structure will be very useful for describing some type of provenance. I have no doubt about its usefulness and the necessity for its relatively more restrictive structure.

However, Satya and I are trying to provide some examples to show the need for some alternative more relaxed collection structure from DM, like set.

I don't like proposing people to use rdf collection or bag. Actually the sioc use case doesn't need to use such rdf constructs. If sioc can support this in their vocab, why can't ours? It's a very simple membership relationship I am pushing for. No orders, no list, just a set of stuff.

Out of interest, what do we lose if we get the key as optional in the model?

Jun

Sent from my iPad

On 18 Apr 2012, at 22:20, Luc Moreau <L.Moreau@ecs.soton.ac.uk<mailto:L.Moreau@ecs.soton.ac.uk>> wrote:

Hi Satya,

Therefore, in your cell line example, I suppose you don't want/cannot enumerate the cells, and
therefore express insertion into/removal from the cell line?

You may still want to distinguish the states of the cell line at two different instances and
relate them by derivation?

Luc

On 18/04/12 21:33, Satya Sahoo wrote:
Hi Luc,

Do I understand correctly that those two collections do not change: a cell line has a given number of cells, and the cohort involves a set of patients.

A cohort remains static during the period of study. The number of cells may increase (by cell division) or decrease (by cell death).

Thanks.

Best,
Satya

So, yes, I understand that removal/insertion are not necessary for such static collections.

Regards,
Luc


On 18/04/12 17:35, Satya Sahoo wrote:
Hi all,
The issue I had raised last week is that collection is an important provenance construct, but the assumption of only key-value pair based collection is too narrow and the relations derivedByInsertionFrom, Derivation-by-Removal are over specifications that are not required.

I have collected the following examples for collection, which only require the definition of the collection in DM5 (collection of entities) and they don't have (a) a key-value structure, and (b) derivedByInsertionFrom, derivedByRemovalFrom relations are not needed:
1. Cell line is a collection of cells used in many biomedical experiments. The provenance of the cell line (as a collection) include, who submitted the cell line, what method was used to authenticate the cell line, when was the given cell line contaminated? The provenance of the cells in a cell line include, what is the source of the cells (e.g. organism)?

2. A patient cohort is a collection of patients satisfying some constraints for a research study. The provenance of the cohort include, what eligibility criteria were used to identify the cohort, when was the cohort identified? The provenance of the patients in a cohort may include their health provider etc.

Hope this helps our discussion.

Thanks.

Best,
Satya


On Thu, Apr 12, 2012 at 5:06 PM, Luc Moreau <L.Moreau@ecs.soton.ac.uk<mailto:L.Moreau@ecs.soton.ac.uk>> wrote:

Hi Jun and Satya,

Following today's call, ACTION-76 [1] and ACTION-77 [2] were raised against you, as we agreed.

Cheers,
Luc

[1] https://www.w3.org/2011/prov/track/actions/76
[2] https://www.w3.org/2011/prov/track/actions/77