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