- From: Ivan Herman via GitHub <sysbot+gh@w3.org>
- Date: Sat, 21 Nov 2015 16:50:40 +0000
- To: public-annotation@w3.org
@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