[annotator-dev] Annotator / Open Annotation mapping

[Robert Sanderson]

Hi Nick, Randall,

On Tue, Jun 24, 2014 at 2:15 AM, Nick Stenning <nick at whiteink.com> wrote:
>
> On Wed, Jun 18, 2014, at 23:40, Robert Sanderson wrote:
> >     "hasBody" : {"@type" : "cnt:ContentAsText", "chars" : "content-here"}
> Am I right in thinking that this property can be an array of objects,
> too?
>

Yes, any property can be an array of objects or literals, as appropriate,
in JSON-LD.  The array is then cast as either an rdf:List or multiple
predicates via the Context document.  So hasBody, hasTarget, hasSelector
(etc) can all be arrays of objects.



> > * "user" becomes "annotatedBy" : {"foaf:nick" : "userid-here"}
> Careful. This is currently used as user identifier, not a human-readable
> representation of the user's name. Can I add arbitrary id properties to
> the object on the RHS?
>

Yes, that's the implication of foaf:nick which explicitly includes "login
name".



> > Making a stand that they're actually about the target (despite the
> > "review"
> > example), then they become additional bodies:
> > "hasBody" : [ {...as above ...}, {"@type" : ["cnt:ContentAsText",
> > "oa:Tag"], "chars" : "tag-here"}]
> > And if they're not about the target, then they get dropped.
>
> So in terms of exposing existing data in this serialisation, we have no
> idea of the motivations for tagging. So we either keep them all as
> bodies, keep them all as properties (perhaps non-semantic ones) of the
> annotation, or we drop them all. There's no way to partition them.
>

Can the annotator documentation/ui be more explicit about what the tags
apply to?  They seem less useful than they could be at the moment, due to
this ambiguity.


> * Consumer and Permissions are dropped, as authorization isn't part of
> > the OA model.
>
> Do we drop things that aren't in the OA model? Can't we just have
> arbitrary fields? Not having this information makes appropriate
> client-side rendering and authz difficult. (Do I have to make a call to
> another endpoint to retrieve this information for a given @id?)
>

That's a good question.

Technically in JSON-LD you can include any additional properties that
aren't mapped in the context and a JSON-LD processor will ignore them.  So
yes, things can be added in arbitrary fields, but they won't survive any
round trip through an RDF rather than JSON based processor.

Alternatively, you can add additional contexts, such as the one in for the
Selector, that map the information into RDF.  New contexts should come at
the beginning of a block (yes I know keys are unordered) and apply only to
that block ... so we could do something like:

"permissions" : {
  "@context" : "annotator-permissions-context.json",
  "read" : [],
  "admin" : [],
  ...
}

And the json document would describe how to interpret read, admin, update
and delete.

Rob

-- 
Rob Sanderson
Technology Collaboration Facilitator
Digital Library Systems and Services
Stanford, CA 94305
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/annotator-dev/attachments/20140624/36e527db/attachment-0004.html>