Re: Streamlining the OA Model

On Tue, Jul 31, 2012 at 1:01 PM, James Smith <jgsmith@gmail.com> wrote:

>
> On Jul 31, 2012, at 12:02 PM, Bernhard Haslhofer <
> bernhard.haslhofer@cornell.edu> wrote:
>
> > Hi,
> >
> > I spent the past couple of weeks implementing the Maphub API (
> http://maphub.github.com/api/) using the Open Annotation model and found
> that the model is expressive enough for our use cases. However, I believe
> that some tweaks in the OA specifications could streamline the model and
> make the developer's life (= the "users" of the specification) easier, both
> on the server- and the client-side.
> >
> > Here the summary my thoughts:
> >
> > 1.) Direct Relationship between Annotation and the Source
> >
> > "Give me all annotations for resource X", is probably one of the most
> important queries that needs to be answered. X could be an image URI, the
> URI of a video, whatever. Since the the Target of an annotation may be a
> resource with its own dereferencable URI OR a Specific Target with a UUID
> node, you need to consider this when formulating a query and end up with a
> SPARQL UNION query or some conditional node traversal code when using an
> RDF API.
> >
> > Technically, it is of course possible to do that, but given the
> importance of that query, I would argue that the solution is not very
> intuitive and maybe also not very efficient. I believe that this can easily
> be be fixed by introducing a direct relationship property (e.g.,
> oa:annotates, oa:hasTargetSource) between the Annotation and the Source
> resource.
> >
>
> I don't see a problem with an oa:annotates or similar linking the
> oa:hasSource with the oa:Annotation node if it makes reasoning simpler in
> most cases. The other option for reasoners is to go through the RDF store
> and create this linking in a single pass (where it doesn't exist) and then
> using it later as needed. Adding this is an optimization. It doesn't enable
> or break anything that wasn't already enabled or broken.
>


I believe  oa:annotates is a possibility to evaluate. In general we tried
to limit naming relationships with terms that were already 'popular' in
annotation representation. However, in this case I am in favor of
considering something like oa:annotates as the use of it is in line with
the previous use of that property in other ontologies such as Annotea.

In any case, I would probably suggest the option 2: to perform the
optimization when importing in the store.

I am also wondering if this topic is related somehow to 'annotating an
image within a HTML document', in other words annotating an image keeping
track of the fact that annotation is valid when the image is displayed in a
specific document. In such case, what ao:annotates would point to? The
image - knowing that the annotation is validfor the image in a specific
context - or the HTML page - that contains the image?




>
> > 2.) Fragment URIs as Targets
> >
> > In our API (the GeoReference part) we followed the OA recommendation and
> used a Specific Resource and a Fragment Selector to express that a URI
> annotates an XY point on a raster image. We could express the same
> information by using W3C Media Fragments and thereby reduce the verbosity
> and complexity of the resulting serialization. API consumers then don't
> even need to know about OA-specific "Specific Resources", "Fragment
> Selectors", etc.
> >
> > The Open Annotation model currently does NOT RECOMMEND the use of
> fragment URIs for identifying segments of Targets or Bodies for three
> reasons (see 5.2.1):
> >
> > - "cannot query the source directly": I think this could and should be
> solved by considering (1.)
> > - "they are not compatible with State and Style Specifiers; many
> annotations may have the same segment of interest, but have different
> States and Styles": from previous emails and discussions I understood that
> Styles should be directly attached to the Annotation, which also means that
> that they are contextualized and not an argument against fragment URIs
> anymore. I think that sth. similar can be done with "State" and would also
> result in a more consistent model and allow for fragment URIs
> > - "Fragment URIs conflate the identity and the description of the
> segment of interest by including the description inline within the
> identity": I am not sure if I get the point of this argument right;
> however, I believe that for very practical reasons the OA model should
> reuse what other specifications (Web Architecture, Media Fragment RFCs)
> already define; this brings modularity and flexibility and avoids the risk
> of re-designing what others already did elsewhere.
> >
> > I think the benefits of reusing (Media) Fragment URIs in OA prevail the
> arguments of not using them and therefore I propose to RECOMMEND the use of
> Fragment URIs and only fall-back on OA-specific Selectors if Fragment URIs
> are not expressive enough.
>
> -1 from me for this. URIs are opaque. They have no semantics in the
> context of RDF. Clients should only have to use them as part of a protocol
> request (e.g., an HTTP GET).
>
> What OA does is break the URI+Fragment into two pieces: the URI, which can
> be dereferenced, and the Fragment, which the client can parse and use. The
> target is broken into a server component and a client component, since the
> server should never see a fragment identifier, and the client should never
> parse the URI. Putting the two together requires the client to parse the
> URI and the server to know that it has to ignore anything in the URI that
> follows the hash (#). This could break some servers (testing required, but
> servers don't see a hash+Fragment from browsers, so they might be designed
> not to expect it).


+1 for James


>
> > 3.) Simple Literal Body Shortcut
> >
> > I understand that an OA annotation is a relationship between resources
> (the body and the target) and that inline bodies are represented using the
> Content in RDF specification (see 6.1.). However, our own demonstrator and
> also the majority of use cases demonstrated in the OAC meeting last week
> showed that many annotation bodies are simply strings, which could be
> represented as literals.
> >
> > Therefore I am proposing to introduce a "shortcut" property between the
> Annotation and the "content" Literal (e.g., hasLiteralBody). This allows
> people to express simple annotations in a, in my opinion, more
> straightforward way and doesn't contradict the current oa:hasBody approach.
> >
>
> -1 from me. I don't see how this isn't a premature optimization. The
> examples at the OAC meeting used the simplest possible body, so I don't
> expect them to be representative of usage "in the wild." With more data
> from live, publicly available projects where the optimization represents a
> significant gain, I might be persuaded otherwise.
>
> In my own experience, refactoring should make literals easy regardless of
> how many triples are needed in the RDF. Same for retrieving literals from
> the RDF. OA is an exchange format. I expect application writers to create
> libraries that wrap the RDF nature of the model so they can easily get/set
> the information they are interested in.
>

+1 for James


>
> > 4.) Style Attached directly to the Annotation
> >
> > We don't express style information in our serializations because I
> believe that styling information and data representation should be
> separated. However, I understand that there are use cases that require this
> feature and I prefer the approach of optionally attaching style directly to
> the annotation over attaching it to the Specific Target.
> >
>
> +1 from me. I think it makes more sense for the style to affect the
> annotation than the target.
>

See related proposal/thread:
http://lists.w3.org/Archives/Public/public-openannotation/2012Jul/0066.html


>
> > 5.) JSON (-LD) Serialization Recommendation
> >
> > At the moment the spec recommends that RDF/XML is used as default
> serialization language. We haven't implemented it yet, but I'd consider
> JSON (-LD) at least as alternate "default" serialization format to open the
> door for JS clients.
>
> I'm on the fence with this. I definitely think JSON is outgrowing XML as a
> serialization standard on the web. JSON is designed for data structures.
> XML is designed for documents. RDF is more a data structure than a
> document. Any JavaScript libraries I produce will work with RDF/JSON and
> let the user add in any RDF/XML support they might need. My server
> implementations will produce RDF/JSON and probably RDF/XML (one is easy
> once you have the other). In my own shared canvas work recently, I'm
> producing RDF as JSON, XML, and Turtle, as well as a HATEOAS-oriented JSON.
> In the world of linked data and REST, the important thing for OA is the
> data model, not the serialization format.
>
> -- Jim
>
>
>
Paolo