Re: Annotation protocol (creating a new annotation)

Replies inline...

On Mon, Feb 2, 2015 at 7:37 PM, Robert Sanderson <azaroth42@gmail.com>
wrote:

>
>
> On Mon, Feb 2, 2015 at 2:40 PM, Denenberg, Ray <rden@loc.gov> wrote:
>
>> on server   xyz.org     there is resource R:  http:/
>> www.xyz.org/resources/resourceR
>>
>> On MY server:   http://www.ray.org/
>>
>> I create a review of resource R:
>> http://www.ray.org/reviews/reviewOfResourceR
>>
>>
>>
>> I create an annotation:
>>
>> <http://www.ray.org/annotations/annotationForTheReviewOfResourceR>   a
>> oa:Annotation ;
>>
>>                 oa:hasBody                        <
>> http://www.ray.org/reviews/reviewOfResourceR>  ;
>>
>>                 oa:hasTarget                      < http:/
>> www.xyz.org/resources/resourceR> .
>>
>
> Yup all good so far!
>
>
>
>> http://w3c.github.io/web-annotation/protocol/wd/   says
>>
>> *“3.2.1 Create a New Annotation*
>>
>> New Annotations are created by posting the JSON-LD serialization to an
>> Annotation Container.”
>>
>> Annotation container where?  On  which server,  xyz or ray?   I assume
>> “ray” because that’s my server so I know where the annotation container is,
>> while I have no idea where the container is on xyz.
>>
>
> This is the note in 3.1.1 about discovery.
> http://w3c.github.io/web-annotation/protocol/wd/#containers-for-annotations
>

So...I'd missed this line in my earlier skim through the LDP-based protocol
draft:
"A conforming server *MUST* provide one or more LDP Containers within which
Annotations may be managed."

I find that sad.

I realize adding things to a "container" (or index or feed, etc) increases
the likelihood of finding the thing again.

However, HTML (and images and CSS...) don't have such a
"must-be-put-in-a-box-of-said-shape" in order to exist on the Web. Adding
that requirement to the publication of Annotations would be a decided step
backwards.

We should also include text (and certainly user stories...which I'll do
shortly) that handle "orphaned" or "one off" annotations.

If I were to publish an OA JSON document into any-old-JSON-storage-thing,
I'd hope that whatever awesome browser we use in the future (or extension
we'd use later this year) could take that URL and add that annotation onto
the page when I visit it (which may happen directly after I "give" it to my
browser).

The other side of the coin is an annotation that I make and want to
publishing into multiple containers (indexes, feeds, whatever). It should
be possible for me to signal (...a separate discussion...) that I want this
annotation added to that index/container/thing and to do that over and over
again. :)

Ideally. :)

In both of these scenarios, I MAY (at my option) publish a JSON-LD document
containing OA via a system like GitHub Pages, FTP, or whatever, and then
send that resulting URL to whatever OA-friendly container/index system I
happen to know about.

Like how the "blogosphere" used to work when RSS was a thing, and Atom was
just a little kid.


> LDP does not define any discovery mechanisms at all for containers, just
> the notion that if you GET a container, it will tell you that it is one.
> This leads to the "body" and "other" container URIs having to be at
> pre-defined locations, despite the intended opacity of URIs.
>

Did some more parsing of the LDP spec.
http://www.w3.org/TR/ldp/

It doesn't look like there's any encouragement (or requirement) that
resources include Link headers stating which container their within--which
would back up your statement. I suppose that COULD be done as a way to help
facilitate discovery.

Something like rel="collection" from RFC 6573:
http://tools.ietf.org/html/rfc6573#section-2.2


> There are various directions that we could take which would be good to
> discuss, including:
>
> * Link headers/elements, with a new rel type to point to annotation
> services such as in 3.1.1, there given the URI
> http://www.w3.org/ns/oa#annotation-service
>

Like rel="annotation" as proposed by in HTML 1.1? :)
http://tools.ietf.org/html/draft-ietf-iiir-html-00
...you'll have to search for "annotation" to find it...


>
> * .well-known URIs following RFC 5785
>

This one seems insufficient as it's *likely* that a single domain
("authority") would be home to multiple annotation collections and that not
all of them should be discoverable--and that spreading authentication /
access control across that much of the domain space (.well-know/...,
/annotations/, /user-id/annotations/) may be beyond the capabilities of the
deployment environment.


> * Adding triples to the annotation to reference the containers
>

Optionally. Sure.


> * Ruling it out of scope (which I would personally find sad)
>

I think we at least need to describe best practices / options for handling
these scenarios. At the very least.


> * Other suggestions?
>

Just one:
The less a developer has to deploy to use / benefit from annotation, the
better.

I'll be going through the uses cases some more to highlight some of the
protocol related bits soon.


>
>>  My question is, how is server xyz made aware of the existence of this
>> annotation?   Either I’m missing something, or the document hasn’t gotten
>> that far yet.  If it’s the latter, fine, I just want to be sure I’m not
>> missing something.
>>
>
> It hasn't gotten that far yet.  That would come under the activity streams
> section in 3.4, which I haven't written yet but have some long flights to
> work on it this week :)
>
> Hopefully we can avoid inventing anything here, and will take a closer
> look at the pingback system that Stian references.
>

Also...the PROV Pingback system is *far* better than the old RPC-driven
pingback...and should really get it's own name...fwiw. :)

I'd also love to explore using LINK and UNLINK methods as originally
defined in RFC 2068. It would be useful for the "signaling" system...at
least as an option. There some history links and exploratory code at
http://relify.com/

Thanks for listening. :)
Benjamin


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