Re: Structured Body: help

On Tue, Jul 17, 2012 at 6:02 PM, Robert Sanderson <azaroth42@gmail.com>wrote:

> On Tue, Jul 17, 2012 at 5:45 PM, Christian Morbidoni
> <christian.morbidoni@gmail.com> wrote:
> > I'm vary happy that Named Graphs has been included in the specification
> as I
> > think they are very useful.
> > I'm in the process of modeling the Pundit (http://thepund.it)
> triplestore to
> > conform to the relatively new specs.
>
> Fantastic, that's great news Christian.  If there's anything that we
> can help with, please feel free to ask!
>

I'll do. It will take some time to implement but the idea is to make Pundit
server an implementation of OA with REST API.
BTW, the API that we currently support are documented here:
http://thepund.it/server.php
In these days we are adding support for filtering annotations and for
sharing notebooks (collections of annotations)
Any comment is more than welcome.


>
>
> > I have a couple of questions/doubts:
> > "It is RECOMMENDED to have a dereferencable resource that contains the
> > serialization of the graph, rather than to use Named Graphs."
> > Does it means that Named Graphs, when used as body of an annotations
> should
> > have URL and that this URL should be dereferenced to the triples
> contained
> > in the named graph? If it is so I think it is a very good approach.
>
> Yes, that's it exactly.  The issue with Named Graphs is that they have
> their own serialization (eg Trig/Trix) which a regular RDF system may
> not be expecting.
> Thus, by removing the triples from the annotation graph, both
> documents may be a regular RDF serialization.
>
>
Ok, agreed. We are currently addressing this issue by having an API
/annotations/{annotation-id}/metadata that returns the annotation graph
(author, date, etc.) and an other one /annotations/{annotation-id}/content
that returns the triples contained in the corresponding named graph body.
The two are RDF/XML compliant.


>
> > Regarding the Structured Body
> > (http://www.openannotation.org/spec/extension/#StructuredBody): it
> seems a
> > very strange approach to me.
> > If there has already been a discussion about it please point me to
> it....I
> > cannot find anything in the ML archive.
>
> There hasn't been an online discussion about it, though it was
> discussed at a face to face meeting in Boston in March.
>
> > I'm referring to the example that uses X, Y, Z, etc. The question is:
> how do
> > I distinguish triples that belongs to the structured body from other
> triples
> > that state something about Y, Z or X?
>
> Yes, if you store all of your annotations in a triplestore you can't
> necessarily reconstruct what was originally part of the individual
> annotations if you use this approach.  For example if someone were to
> assert a relationship between Y and W, then this would get picked up
> by the example annotation.  Hence the recommendation to keep the
> triples as content of a separate document with a URI.
>


I see.


>
>
> > May be the answer is in this sentence "Implementations that expect a
> > resource with a serialization separate from the Annotation graph may not
> be
> > able to store structured resources"?
>
> Basically, as above, that systems built around the open world, single
> graph model will not be able to reconstruct the individual annotations
> unless they have some other means of storing the annotations (eg as
> documents rather than triples)
>

I understand, however it seems a bit risky as an approach. Or may be the
issue should be better explained in the specs. It means that reusing such
annotations in a "open world" context would be impossible, and it seems to
me that this is one of the stronger points of OA.


>
>
> > Does it mean that resource X, Y and Z
> > should not be involved in triples other than the ones included in the
> > structured body? Does it also mean that two different annotations cannot
> > have structured bodies that talks about the same resource (e.g. Y)?
> Isn't it
> > a bit too restrictive :-) ?
>
> Indeed, very restrictive and impossible to enforce.  It's why we don't
> recommend doing this unless without thinking long and hard about the
> consequences or have a constrained system in which this isn't an issue
> :)
>
> Hope that helps,
>

Thank you for the clarifications.

best

Christian


>
> Rob
>
> PS. Are you around DH2012, I saw your name on the program?  I'll be
> there tomorrow only if you'd like to meet in person to discuss. Email
> me off-list if you'd like
>