- From: Luc Moreau <L.Moreau@ecs.soton.ac.uk>
- Date: Wed, 18 Apr 2012 21:19:01 +0100
- To: public-prov-wg@w3.org
- Message-ID: <EMEW3|c41afaf767c7b394736092a521267b0eo3HLJQ08L.Moreau|ecs.soton.ac.uk|4F8F21B5>
Dear all,
I just wanted to throw a few ideas/questions to defend collections as
they currently are.
1. prov:Collection is similar to rdfs:Container [1] :
the properties rdf:_1, rdf:_2, ...[2] map naturally to keys in
prov:Collection.
2. RDF collections [3] can also be described by prov:Collection, using
rdf:first and rdf:rest
as keys for a collection of two elements, and allowing nesting of
collections.
So a few questions:
1. Is it being suggested that rdfs:Container and rdf:List are not
appropriate, and we
should look at other forms of "collections"?
2. Has the prov-o ontology encoded prov-dm collections in a way that is
lightweight enough?
Could we for instance restrict the keys to be mapped to properties
such as rdf:_1, rdf:_2?
I however acknowledge that prov:Collection is not "natural" to model a
set. I suppose that
like "rdf:Bag class is used conventionally to indicate to a human
reader that the container is intended to be unordered",
we would need a similar notion for expressing sets with prov:Collection.
Cheers,
Luc
[1] http://www.w3.org/TR/rdf-schema/#ch_container
[2] http://www.w3.org/TR/rdf-schema/#ch_containermembershipproperty
[3] http://www.w3.org/TR/rdf-schema/#ch_collectionvocab
On 18/04/12 19:39, Stephan Zednik wrote:
>
> 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
>>> <mailto: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
>>> <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<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 <mailto:james.mccusker@yale.edu> | (203)
>>> 785-6330
>>> http://krauthammerlab.med.yale.edu <http://krauthammerlab.med.yale.edu/>
>>>
>>> PhD Student
>>> Tetherless World Constellation
>>> Rensselaer Polytechnic Institute
>>> mccusj@cs.rpi.edu <mailto:mccusj@cs.rpi.edu>
>>> http://tw.rpi.edu <http://tw.rpi.edu/>
>>
>
Received on Wednesday, 18 April 2012 20:19:56 UTC