...
(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.
(Paolo) that is a fair point but the description is not accurate, the approach has been described in the paper, here it is:
...
<x> a ore:Aggregation ;
ore:aggregates <a> ; // should be repeated at the end
ore:aggregates <b> ;
ore:aggregates <c> .
<p1> a ore:Proxy ;
ore:proxyFor <a> ;
ore:proxyIn <x> ;
iana:next <p2> .
<p2> a ore:Proxy ;
ore:proxyFor <b> ;
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.
Example 4-ore: A Virtual Collection as an unordered collection of items using ORE Ontology's Aggregation with multiple unordered items
...