[annotator-dev] Annotator / Open Annotation mapping

Thu Jun 19 00:26:38 UTC 2014

On Wed, Jun 18, 2014 at 2:40 PM, Robert Sanderson <azaroth42 at gmail.com>
wrote:

>
> Dear all,
>
> Below is the result of a discussion between Randall and I regarding my
> Open Annotation tickets.
>
> Simple translations:
>
> * "@context" and "@type" are added.
> * "id" becomes "@id", with a value of the base URL of the API (passed to
> the function) plus /annotations/ plus the current id value.
> * "annotator_schema_version" goes away.
> * if "updated" is present, it becomes "annotatedAt". If not, then
> "created" becomes "annotatedAt".
> * "text" becomes the construction:
>     "hasBody" : {"@type" : "cnt:ContentAsText", "chars" : "content-here"}
> * "user" becomes "annotatedBy" : {"foaf:nick" : "userid-here"}
>

As used in annotateit.org I think the user field might be anything,
consumer specific. Nick would know.

For annotator-store, maybe as a concurrent step to this we should make the
user class pluggable as we've done with the annotation class. Then we could
assume foaf:nick but also provide a hook method for the user class that
lets it be responsible for returning its own linked data.

```python

class User(object):

    def __jsonld__(self):
        return {'foaf:nick': self.id}
```

Or, as we'd do in Hypothes.is today:

```python

class User(BaseModel, Base):
    def __jsonld__(self):
        request = get_current_request()
        return "acct:{}@{}".format(self.username, request.hostname)
```

In the first, the user is an object with a foaf:nick property, in the
second it's an acct: URI.

Something like this.

```python

class Annotation(_Model):
    def __jsonld__(self):
        # ...
        user = g.auth.request_user()   # Off the top of my head, may be
incorrect, but close
        if hasattr(user, '__jsonld__'):
            result['annotatedBy'] = g.auth.request_user()
        else:
            result['annotatedBy'] = {'foaf:nick': user.id}
```

> Tag logic:
>
> The current annotator documentation doesn't say whether the tag is about
> the comment/body/text, the annotation resource, or the
> target/uri/selection.
>
> 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.
>
>
> Target logic:
>
> If there are no ranges or quote, then "uri" becomes "hasTarget".
> If there is quote, but no ranges:
>
> "hasTarget" : {
>   "@type" : "oa:SpecificResource",
>   "hasSource" : "uri-here",
>   "hasSelector" : {
>     "@type" : "oa:TextQuoteSelector",
>     "exact" : "quote-here"
>   }
> }
>
> If there is quote and ranges, it becomes longer and uses a custom selector
> (until we can standardize it in the W3C WG)
>

> "hasTarget" : {
>   "@type": "oa:SpecificResource",
>   "hasSource" : "uri-here",
>   "hasSelector" : {
>      "@type" : "oa:Choice",
>      "default" : {
>         "@context" : "http://annotatorjs.org/ns/oa-context.json",
>         "@type" : "anno:Range",
>         "start": "/p[69]/span/span",
>         "end": "/p[70]/span/span",
>         "startOffset": 0,
>         "endOffset": 120
>      },
>      "item" : {
>        "@type" : "oa:TextQuoteSelector",
>         "exact" : "quote-here"
>      }
>   }
> }
>

Was there every any discussion of making oa:Choice the implied default when
>1 hasSelector relationships exist?
Although, I see how that conflicts with having a "default".
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/annotator-dev/attachments/20140618/848213af/attachment-0004.html>