Re: actions related to collections

On Apr 18, 2012, at 12:24 PM, Timothy Lebo wrote:

> I've had similar concerns that the definitions for collections are "too heavyweight" to manage the membership of sets.
> 
> But while ignoring is name and looking at the modeling construct it provides, it's clear that this construct will be very useful in many real provenance problems (for example, the very ubiquitous need for provenance of function calls with their argument names and bindings).
> 
> Perhaps we can avoid the "too heavyweight for set membership" concerns raised by Satya and Jun by renaming what we have (prov:Collection) to something more appropriate, like prov:Dictionary?

+1

Jim is right that you can model collections with enumerated classes, but I am not sure about stating the provenance of a collection defined by an enumerated class.

We could also define a much simpler prov:Collection class that does not force map/dictionary conventions to go along with prov:Dictionary.

--Stephan

> 
> -Tim
> 
> On Apr 18, 2012, at 2:12 PM, Jim McCusker wrote:
> 
>> I think a set of key-value pairs is what's known as a map or dictionary. A collection is a set of things with a defined membership. In OWL it would probably be represented as an enumerated class.
>> 
>> Jim
>> 
>> On Wed, Apr 18, 2012 at 1:20 PM, Jun Zhao <jun.zhao@zoo.ox.ac.uk> wrote:
>> 
>> Dear all,
>> 
>> I concur with what Satya wrote. And the example I had in mind is collection type of entities on the blog sphere of the Web.
>> 
>> As we all know SIOC is a widely used vocabulary to describe entities in the online community sites, like blogs, wikis, etc. It has the concept of sioc:Container, which is defined as "a high-level concept used to group content Items together". The relationships between a sioc:Container and the sioc:Items or sioc:Posts that belong to it are described using sioc:container_of and sioc:has_container properties.
>> 
>> The provenance of a sioc:Container could be who is/are responsible for the container, who created this container, and when.
>> 
>> The provenance of a sioc:Post could include when the posted was published, when it was modified, by whom, based on which other posts, document or data.
>> 
>> As you see, I am struggling to see how the key-value pair kind of structure could play in the above simple scenario. But please correct me if I am wrong.
>> 
>> HTH,
>> 
>> Jun
>> 
>> 
>> 
>> 
>> On 18/04/2012 18: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>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<https://www.w3.org/2011/prov/track/actions/76>
>> [2] https://www.w3.org/2011/prov/**track/actions/77<https://www.w3.org/2011/prov/track/actions/77>
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> -- 
>> Jim McCusker
>> Programmer Analyst
>> Krauthammer Lab, Pathology Informatics
>> Yale School of Medicine
>> james.mccusker@yale.edu | (203) 785-6330
>> http://krauthammerlab.med.yale.edu
>> 
>> PhD Student
>> Tetherless World Constellation
>> Rensselaer Polytechnic Institute
>> mccusj@cs.rpi.edu
>> http://tw.rpi.edu
>