[annotator-dev] Annotator / Open Annotation mapping

Tue Jun 24 16:12:01 UTC 2014

On Tue, Jun 24, 2014 at 9:03 AM, Robert Sanderson <azaroth42 at gmail.com>
wrote:

>
> 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".
>

But I don't believe this field is used, at least in annotateit, as login
name. It's actually totally opaque to our backend what this is. It's a
string that identifies the user to the consumer, rather than to the
annotation store.

It might be a primary key into a user table, for instance, and not the
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.
>

+1

I think we all seem to be in agreement: decide on a meaning, document it,
and stick to it.

I favor tags as bodies of their current annotations simply because it means
not creating a new annotation for every annotation with tags.

>
>
> > * 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.
>
>
No preference from me. Happy to just have extra properties that wouldn't
survive an RDF round trip and come up with a context or different plan in
the next iteration.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/annotator-dev/attachments/20140624/900b4fbd/attachment-0004.html>