...
(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.
<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> .
Example 4-ore: A Virtual Collection as an unordered collection of items using ORE Ontology's Aggregation with multiple unordered items
...