Re: actions related to collections

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

So, member(c,e)  implies wasDerivedFrom(c,e)
meaning that to generate collection c we needed 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 am not too sure what would happen then.


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 < 
> <>> 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
>>>>     < <>> 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]
>>>>         [2]

Received on Wednesday, 18 April 2012 22:22:07 UTC