Re: [web-annotation] Multiplicity and Collections

This may be TL;DR... however, regarding the differences between 
composites and lists. Conceptually, ontologically, there is a 
fundamental difference between these things. One is an aggregation and
 the other is a set. Because they are fundamentally different things 
we should (and indeed must) expect different kinds of behaviors from 
them. 

In the case of composite we are doing to two things:
1) We naming some new thing (a content object thing) that comprises 
multiple other things (themselves content objects)
2) We expect that a software agent will appropriately combine them 
into a single web resource which an end user encounters.

One example of a composite is an aggregation of 120 digitized pages. 
Notionally we might call it a book. My expectation is that the 
software agent that consumes this composite understands that it must 
string the pages together (perhaps through some page-turner 
application or perhaps by forging them into a single pdf or other epub
 format file) into some singular thing that the end user encounters. 

Another example is the digital emblematica one that emerged from the 
2nd round of OAC work - that of juxtaposing images. The expectation 
our end users had was that the thing they were annotating, the actual 
target of the annotation, was a collage comprising a pair of emblem 
icons arranged according to their wishes. The use case for the 
annotation model is to provide enough information so that the 
annotation's target can be faithfully reproduced in any arbitrary 
setting that has access to the underlying images from which the 
collage is formed. Again, something new and neither set- nor list-like
 is formed.

Using this information we can actually describe two kinds of 
Composites: Unordered Networks of Content Objects [UNCO] (e.g., 
collections, aggregations, etc.) and Ordered Hierarchies of Content 
Objects [OHCO] (aka Documents -- e.g., Books, Videos, Poems, etc.). 
The difference between them is the nature of the relationships that 
obtain among their parts. 

In the case of things like collections, there is always at least one 
feature which forms an axis along which all members of the collection 
are equivalent. Take for example the Charles W. Cushman Photograph 
Collection[1]. The following two equivalency relationships always 
obtain between any to members of the collection: they always have the 
same creator (Charles W. Cushman) and they are always of the same kind
 of thing (they are photographs). These relationships obtain 
regardless of the order of the individuals and no amount of 
reshuffling will affect them. 

The collection's existence as a Composite is completely independent of
 the order of its members and any such ordering or reordering of them 
is merely presentational in nature (and can be handled entirely on the
 application end). The aggregated members collectively form a 
contextual mass, the many, many relationships (besides the equivalency
 relationships) producing some additive content beyond that which the 
user experiences when encountering any one of the photographs 
individually. This additive content is recorded through the auspices 
of collection-level metadata and through the relationships that obtain
 among collection members by virtue of their inclusion in the 
collection. 

If this was the only kind of Composite that we needed to record 
information about then the Activity Streams model might be adequate 
even though it conflates UNCOs with Lists. Unfortunately there is a 
paucity of pertinent information that would let us determine when we 
are looking at one or the other. It lacks rather important things like
 motivations and expectations. I don't really know what I'm supposed 
to do with an as:Collection.

Of course, UNCOs like collections aren't the only kind of composites 
we annotate. There are also OHCOs. We might argue that we have 
existing container models for a lot of these but a great failing is 
that we don't really have one that lets us make OHCOs out of anything 
on the fly (like constructing impromptu collages from existing 
images). But this kind of behavioral expectation is wholly unsuited 
for as:Collection which "represents ordered or unordered sets of 
Object or Link instances." In no way would we be safe in assuming that
 we could successfully tell a software agent that it should take the 
things contained within the collection to forge some new entity from 
them. It (as:Collection/as:OrderedCollection) cannot communicate that 
the thing contained within is greater than the sum of its apparent 
parts.

Lists lack these kind of expectations. They do not represent some new 
singular content-bearing thing. Rather they are either some kind of 
ordered presentational framework (e.g., present these things in this 
arrangement) or an ordered execution framework (e.g., do these things 
in the following sequence). They are sets and not aggregations. 

What this implies to me, with regards to the annotation model is that 
as:Collection is not sufficient to meet the needs of the model. I'm 
not even certain that they actually meet the model's needs vis-a-vis 
ordered lists. As @tilgovi and @shepazu have noted a few times some 
normative work is needed. Unfortunately wrapping selectors or wrapping
 content objects inside of an as:Collection or as:OrderedCollection 
wrapper doesn't actually tell me what to do with them. We are not 
making any ontological commitments with regards to what they do or 
what they mean. This is a problem because composite both means 
something very different from list and behaves very differently from 
list.

The good news is, we probably don't need to do this work on our end. 
Like Specific Resources and Specifiers, the whole issue of kinds of 
containers and what kinds of behaviors they should instigate in 
software agents can be spun out to another working group (and why this
 wasn't one of the first semantic web working groups ever formed I do 
not understand but for some reason its 2015 and we have 0 agreements 
on containers... :(  ). As @tilgovi mentioned in a past post and as 
the workset example elsewhere demonstrates, we have a lot of uses for 
containers. We expect them to fulfill a lot of different roles and 
lend themselves to various specialized behaviors. These uses and 
expectations extend well beyond annotations (or activity streams for 
that matter).

-1 for using as:Collection or as:OrderedCollection in place of 
oa:Composite. They are both wholly inadequate mechanically and 
ontologically for fulfilling the role needed by composite use cases.

-0 for using as:Collection in place of oa:List (or even rdf:List). 
Poor label selection. :(   When things are lists or sets we should 
just call them that. Collections are aggregations which are an 
entirely different animal altogether.

My alternate suggestion for the multiplicity objects issue is 'do 
nothing, will not fix' until such a time as the W3C forms a working 
group that confronts containers directly.

Apologies for the wordiness and any lack of clarity in this post. 

[1] http://webapp1.dlib.indiana.edu/cushman/index.jsp


Regards,

Jacob


_____________________________________________________
Jacob Jett
Research Assistant
Center for Informatics Research in Science and Scholarship
The Graduate School of Library and Information Science
University of Illinois at Urbana-Champaign
501 E. Daniel Street, MC-493, Champaign, IL 61820-6211 USA
(217) 244-2164
jjett2@illinois.edu

-- 
GitHub Notification of comment by jjett
Please view or discuss this issue at 
https://github.com/w3c/web-annotation/issues/92#issuecomment-158520545
 using your GitHub account

Received on Friday, 20 November 2015 20:51:42 UTC