Re: [web-annotation] Model should allow multiple Selectors per SpecificResource

It is deja vu all over again.

The model and vocabulary documents define the class oa:Choice (json 
key Choice) as "a subClass of as:OrderedCollection that conveys to a 
consuming application that it should select one of the resources in 
the as:items list to use, rather than all of them."  

In closing issues #92, #145, etc. I thought we had concluded that 
as:OrderedCollection (or a subclass of it) would be appropriate to 
replace both oa:List and oa:Composite (from previous iterations of the
 model). This would provide a means to differentiate target as array, 
'Body is considered to be equally related to each Target 
individually,' from Paolo's use case of multiple resources grouped 
together as a collection to serve as annotation target. In closing 
#92, I do not recall agreeing to drop this use case altogether (but 
this could be faulty memory - pointer?). 

Since then we have defined the json key 'AnnotationCollection' to be 
the alias for 'as:OrderedCollection' which means we don't have a key 
that we can use for the equivalent of the old oa:Composite / oa:List 
classes when it comes to grouping resources used collectively as a 
target or body.  Personally I still see a need a json key for this, 
and as mentioned I thought this is what we agreed to collectively in 
closing the various multiplicity issues previously discussed. 

I appreciate that some folks will not will not be interested in the 
distinction between a json array and any 'Collection' class or 
subclass, but we've already found it necessary for Choice and for sets
 of Annotations, so why not for Collections formerly known as 
Composite / List?  

BTW, I note the old oa:List class is still to be found in Appendix A 
of our latest model Working Draft 
( I assume 
this is just an editorial oversight, but I choose to take it as a sign
 that we need something like oa:List (json key List) as another 
sub-class of as:OrderedCollection to handle the use case Paolo is 
raising.  Personally I find List a straightforward complement to 
Choice (no more nor less complex), it is consistent with at least what
 some of us understood when issues #92, #145, etc. were closed, and I 
do not agree that Paolo's use case fails by the 80/20 rule. 

GitHub Notification of comment by tcole3
Please view or discuss this issue at
 using your GitHub account

Received on Wednesday, 4 May 2016 18:13:06 UTC