W3C home > Mailing lists > Public > public-openannotation@w3.org > September 2012

Re: Connecting multiple fragment selectors with individual bodies

From: Bob Morris <morris.bob@gmail.com>
Date: Fri, 7 Sep 2012 11:43:45 -0400
Message-ID: <CADUi7O6tH9aO4Vz+LCOG3BbbhR9Stovk0Kjwd+VfdR=8=R56iA@mail.gmail.com>
To: Robert Sanderson <azaroth42@gmail.com>
Cc: Lutz Suhrbier <l.suhrbier@bgbm.org>, public-openannotation@w3.org
(Under some NSF deadlines on two proposals due Monday...so this is
brief.) In my opinion:

1. This is an important topic for which there may be no one-size fits
all solution.
2. The problem is wider than just OA...it's about any scenarios where
there are multiple objects that are (formally or informally)
semantically associated with other multiple objects. To me this
implies that there might arise circumstances in which we find
solutions that are of utility,  but are inconsistent with the current
OA model and which nevertheless deserve discussion. Addressing the
inconsistencies need not always prohibit current OA usage---it could
sometimes be as simple as relaxing constraints in OA.
3. This is such a cross-cutting issue, that I have (too quietly)
begun leaving "See also" breadcrumb links in places in the wiki that I
feel are related (As an example, look at
I've also begun embedding [[Category:Multiple Resources]] wherever I
think a page is germane to the problem.   I'll stop doing all this as
"minor edit" so that people who set a watch will notice that a ---dare
I say annotation---was made.  Ironically, the issues portion of the
wiki is itself an instance of this issue.

hoping to make more contribution next week...
OMG, the week after next is the Chicago meeting! Can't somebody please
insert another week in between :-)

On Fri, Sep 7, 2012 at 11:00 AM, Robert Sanderson <azaroth42@gmail.com> wrote:
> Hi Lutz,
> On Fri, Sep 7, 2012 at 8:32 AM, Lutz Suhrbier <l.suhrbier@bgbm.org> wrote:
>> 1) Using CompositeAnnotation
>> The advantage is, that it clearly composes what I want to compose, a set of
>> sub annotations under the ceiling of one annotation.
>> Disadvantage: A lot of oa:annotations will have to be created in the model,
>> which are some kind of "unwanted" and waisting somewhat the model.
> While this idea hasn't been discussed fully, I can say that the model
> won't support linking bodies directly to targets as the means of
> distinguishing body from target, or which body is associated with
> which target.
> In RDF, every statement is at a global scope. So B1 annotates T1 is
> true everywhere, even "in" annotations where (for example) both B1 and
> T1 are Targets. Or another annotation where B1 is the Body, but T1 is
> not the target.
> This is solved by having the Annotation node to provide identity for
> the statement, which is why we sometimes talk about an Annotation as a
> reification of the relationship.
> Other advantages to the composite approach:
> * Doesn't introduce ambiguity for the general case where additional
> relationships are not provided or not needed
> * Individual annotations are annotations that are simply grouped
> together, and hence they can be referenced directly. For example one
> might want to annotate only one of the grouped annotations.
> * Is an easy overlay on top of the existing model, rather than a
> change to the model. Thus people who do not need this do not need to
> worry about it
> And a couple of design considerations that play in:
> * We have considered creating new nodes with UUIDs to be relatively
> cheap.  For example if there is a choice between creating a new node
> or creating ambiguity or making use cases impossible, we put in a new
> node.
> * The number of triples is not a factor in the design of the model --
> we are not trying to keep things as small as possible, but of course
> this has to be balanced with having the model be understandable.
>> 2) A combination of multiple bodies and the hasContext property
> Multiple bodies have yet to be discussed thoroughly, but ...
>> If I understood right, hasContext is thought to be used in any Specific
>> Resource. Thus, I could create a Specific Body Resource and use the
>> hasContext property to assign that body to a Specific Target Resource
>> (Saying, the body makes only sense if regarded within the scope of the given
>> target resource).
> That would only make sense (to me at least!) if the body was somehow
> within the specific target resource.  For example if you had an image
> within a web page, that's fine.  But a video on one server is not
> within an image on a different server, for example.
>> If, furthermore oa:annotation may incorporate multiple bodies, I could
>> create one Specific Body as described above, and connect them with the
>> dedicated Specific Target Resource. I think, that would perfectly match my
>> requirements and would also avoid to create a bunch of unnessary
>> oa:annotation instances within the model :-)
> But at the expense of creating the specific resource nodes, or do you
> need these anyway?
>> What I did not really get from the discussions, if hasContext's use in
>> SpecificResource is intended as an addition or an alternative to the other
>> concepts (e.g. Selector) within a Specific Resource. If it is thought as an
>> addition, hasContext could also be used within the Specific Target resource,
>> to relate a specific body resource with that specific target including
>> fragment selector. That would also be an adequate solution to my use case
>> too!
> It is definitely an addition, but not intended for linking body to
> target (or vice versa)
> Hope that helps,
> Rob

Robert A. Morris

Emeritus Professor  of Computer Science
100 Morrissey Blvd
Boston, MA 02125-3390

IT Staff
Filtered Push Project
Harvard University Herbaria
Harvard University

email: morris.bob@gmail.com
web: http://efg.cs.umb.edu/
web: http://etaxonomy.org/mw/FilteredPush
The content of this communication is made entirely on my
own behalf and in no way should be deemed to express
official positions of The University of Massachusetts at Boston or
Harvard University.
Received on Friday, 7 September 2012 15:44:13 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:22:01 UTC