Re: [web-annotation] Multiplicity and Collections

@jjett, let me try to summarize your reasoning, just to be on the safe
 side...

* The (conceptual) aggregation of web resources, to be used as a 
single target or body in our model is complex, insofar as, at least in
 some cases, the real nature of the aggregation is difficult to 
express semantically and ontologically.
* The current AS structures are not rich enough to express that 
complexity
* Therefore why bother using the AS structures, they are inadequate 
anyway (I paraphrase:-)

I would agree with your first statement; the difference between lists 
and sets is a clear example. (Actually, as a side note, it is 
interesting to see that for a long time programming languages ignored 
the necessity of having sets in their palette of datatypes and they 
all relied on lists; they have then been added later to languages like
 Python or, finally, to ES6…).

I must admit I do not have a very clear view on whether using AS would
 lead to something really much better than what we have in the model 
document right now under the multiplicity constructs (most of the use 
cases for composite structures *in this working group* came from 
you:-).

I any case, I strongly agree with your conclusion that this Working 
Group should not even attempt to provide a generic model that covers 
all the complexity in this area. Whether this is done in another 
group, or whether the community at large comes up with some 
structures, I cannot say, but we should limit ourselves to our scope.

Oh and, of course, I am all in favour of choosing a "won't fix" action
 if it is reasonable. Call my lazy:-)

Ivan


> On 20 Nov 2015, at 21:51, Jacob <notifications@github.com> wrote:
> 
> 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 
<x-msg://8/e.g.,%20collections,%20aggregations,%20etc.> and Ordered 
Hierarchies of Content Objects OHCO 
<x-msg://8/aka%20Documents%20--%20e.g.,%20Books,%20Videos,%20Poems,%20etc.>.
 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 <https://github.com/tilgovi> and 
@shepazu <https://github.com/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 <https://github.com/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 
<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 <mailto:jjett2@illinois.edu>





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

Received on Saturday, 21 November 2015 16:50:43 UTC