Page History

...

  Planning | Description | Requirements | UI Mockup |  Triples Examples | Queries Examples

...

Table of Contents

...

rdf

http://www.w3.org/1999/02/22-rdf-syntax-ns#

http://www.w3.org/2000/01/rdf-schema#

http://purl.org/dc/elements/1.1/

http://purl.org/dc/terms

http://purl.org/dc/dcmitype

http://www.w3.org/2011/content#

http://www.openarchives.org/ore/

terms/

http://www.iana.org/assignments/relation/

http://purl.org/co

http://www.w3.org/ns/oa

http://xmlns.com/foaf/0.1

...

• Should dc:creator be used for ownership role?
  • ANSWER:  NO - per Paolo
  • REASON:  Muddy concept.  Did the user create the resource or add the resource to the collection?
  • ALTERNATIVE:  Under exploration.  Paolo recommends looking at...
    • PROV ontology - provenance
    • PAV ontology - provenance, authoring, and versioning

...

(Paolo) I apologize that should have been a co:Set to be clearer. For Bags you need to have an instance of Item to support for repeated elements. Once you flatten down to co:element the repeated items become one. The idea of the co:element (defined as chain) in general is to provide a shortcut to the elements. In that case we are interested in finding the existence (one of them), the repetitions are irrelevant at that level.

(Rebecca) I see on the description of the Collections Ontology that "the Collections Ontology (CO) defines unordered collections (Set and Bag) and ordered collections (or List)." It seems awkward to select an ontology in which the type of the collection has to change if ordering is added to an originally unordered collection, or vice versa. That seems to me an advantage of the ORE ontology.

(Rob) The repeating items case makes ORE very strange, as it means creating two proxies for the same resource such that it can be in the chain twice.Paolo) that is a fair point but the description is not accurate, the approach has been described in the paper, here it is:

The relationships between the mathematical entities and those defined by Collections Ontology - and detailed in the following sections of the paper - can be defined as follow:

    co:Set ⊂ Set

    co:Bag ⊂ Bag

    co:Set ∩ co:Bag = ∅

    co:List = co:Bag ∩ Sequence

There are precise pragmatic reasons motivating this design choice. First of all, we chose not to model the mathematical identity function in CO for a specific reason: to allow one to use CO even when modelling scenarios that describe “collections in terms of the constructive boundaries of those plural entities that form themselves a whole". Therefore, it is possible to consider two sets of people, composed exactly by the same people, as two different research groups without contradictions. .... Second, from an implementation standpoint, the data structures managing co:Set and co:Bag are very different.

In other words, if you define a Bag and you add ordering you get a List. See axioms here: http://www.essepuntato.it/lode/owlapi/http://purl.org/co/#d4e499

Set is all another story though. That is correct.

(Rob) The repeating items case makes ORE very strange, as it means creating two proxies for the same resource such that it can be in the chain twice.

<x> a <x> a ore:Aggregation ;
  ore:aggregates <a> ;  // should be repeated at the endend
  ore:aggregates <b> ;
  ore:aggregates <c> .
 
<p1> a ore:Proxy ;
  ore:proxyFor <a> ;
  ore:proxyIn <x> ;
  iana:next <p2> .
<p2> a ore:Proxy ;
  ore:aggregates proxyFor <b> ;
  ore:aggregates <c> .proxyIn <x> ;
  iana:next <p3> .
<p1> <p3> a ore:Proxy ;
  ore:proxyFor <a> <c> ;
  ore:proxyIn <x> ;
  iana:next <p2> <p4> .
<p2> <p4> a ore:Proxy ;
  ore:proxyFor <b> <a> ;
  ore:proxyIn <x> ;
  iana:next <p3> .
<p3> a ore:Proxy ;
  ore:proxyFor <c> ;
  ore:proxyIn <x> ;
  iana:next <p4> .
<p4> a ore:Proxy ;
  ore:proxyFor <a> ;
  ore:proxyIn <x> . 

. 

  (Rebecca) I don't actually find this so strange. If proxies are the means to specify relationships, such as sequencing, among the aggregated resources, then if an aggregated resource has more than one relationship to other resources, as in occurring at multiple positions in a sequence, it seems natural that it would have a proxy for each.

 (Paolo) I do find it strange but not 'that strange'. In CO you can infer the top part so the co:element will have only three objects (with no repetition). But the actual declarative structure will list all of them.

Example 4-ore:  A Virtual Collection as an unordered collection of items using ORE Ontology's Aggregation with multiple unordered items

...

NOTE: This doesn't really come into play until Use Case 1.2, but I want to think about the other access issues with this in mindmin