Re: [model] Clarifying annotation architecture

Thanks Tim!

On Mon, Aug 3, 2015 at 1:45 PM, Timothy Cole <t-cole3@illinois.edu> wrote:

> I remain unconvinced that assigning a motivation or role to an Embedded
> Textual Body not being assigned a URI in the Annotation is bad RDF.
>
> In my mind, if you don't give an Embedded Textual Body a URI (i.e., if you
> let it default to a blank node) then that Embedded Textual Body will not be
> reused outside the current Annotation, and therefore the role assigned to
> Embedded Textual Body in the context of the current annotation is the only
> role which this particular instance of the string will ever have.
>

That's true if you're the server providing the Annotation with a blank node
body ... but on receipt of an Annotation, servers MUST assign a URI to the
annotation, and MAY assign them to all other nodes.  Suddenly your blank
node becomes a real resource and can be referenced from outside of the
annotation.

Relying on blank node anonymity is a dangerous route to follow, and cuts
off options such as annotating part of the body.  For that you'd need a
SpecificResource with a Source of the body URI, and a selector to say which
part of the text you're talking about. And now we're back into assigning
context-specific properties to URIs in the global space :(

 Rather than try to correct and augment these examples in this email
> thread, the way to go *if there's enough interest* is to create a wiki page
> or the like where people can argue the details, correct mistakes and
> augment with additional examples. Would this be worthwhile to do?



Yes I think so :)

Deleting the examples, and pulling out the questions:


The biggest drawback here is that I now have 2 separate annotations that
> were really created together by the agent. We've had discussions about
> Annotation Sets, and though not accommodated by our current model or
> protocol drafts, implementers are using Annotation Sets in practice.  LDP
> patterns offer a way to group or cluster annotations, albeit not all that
> efficiently and requiring knowledge of Direct Containers (or Indirect
> Containers), an LDP feature that not everyone is choosing to implement.
>

The issue here is that then the client needs to be able to create the
Container as well as the Annotations.  I think that's quite a step up in
terms of implementation requirements, as clients could then create
arbitrary structures.  If they can create Direct or Indirect Containers,
there would be a LOT of sanity checking required. (e.g. I create a Direct
Container that adds junk into _your_ Annotation Set :S )

As much as I'm a proponent of LDP, the structure seems less amenable to
client side manipulation compared to the management of resources within
existing structures.



> Each annotation (previously each body) can now be referenced on its own,
> which is good for many use cases. One glaring limitation -- LDP does not
> currently provide a way (that I know of) to post or get all of 3A, 3B, and
> 3C in a single HTTP request. Possibly we could define a best practice.
> There is also a 4th resource (the LDP Direct Container) involved which is
> not shown. This may be too much overhead. Still the annotation set concept
> is useful and is being used. There are other (non-LDP) ways to do
> Annotation Sets. Do we want to make any accommodation for Annotation Sets
> (e.g., add a class and predicate to our data model context)? If we did,
> this option might become more attractive. Note, that in an editing
> scenario, subsequent annotations, e.g., feedback from the author on the
> proposed edit, can be added to the set.
>

There would need to be a profile that inlined all of the Annotations into
the AnnotationSet as an additional requirement.  Whether the Container is
the AnnotationSet or not would be to be determined (e.g. a new Basic
Container, not a Direct/Indirect Container)

The cross-overs with search and paging are also interesting questions.  In
a search, do I get the Set or the individual Annotations? If there's 1000
Annotations in my set, do I have to do paging on it?  etc.



>  ***Option 2 - body-level motivations***
>
> Graph 1 can be rewritten with Embedded Textual Bodies or with
> SpecificResource Bodies, allowing implementers to express additional
> properties of the bodies, such as role or motivatedBy (illustrated below).
> Graph 4 below, using Embedded Textual Bodies, is inconsistent with the
> argument you have made that to express the role of a body you must always
> have a Specific Resource (see above).
>

Right, and see above for why I think even blank nodes here are a problem in
a distributed ecosystem rather than a single interaction.  Graph 5 is the
most verbose, but I believe the most correct.

 ***Option 3 - specializations of the hasBody predicate***
>
> This is probably the least extensible approach and creates problems for
> those not using RDF inferencing
>

Yes.

R

-- 
Rob Sanderson
Information Standards Advocate
Digital Library Systems and Services
Stanford, CA 94305