Feature: web annotations #38
Conversation
|
One thing that we have to look at in further detail is how to handle relationships that can refer to either an item that already exists in the CE, or to an external item. |
|
|
||
| "http://www.w3.org/ns/oa#Annotation" | ||
| type Annotation { | ||
| # TODO: This should be a UUID or a URL, is there a type that can be used? |
There was a problem hiding this comment.
- I think this should be a relationship in the CE, which we can translate to a URL in the JSON-LD output. Otherwise, we can't search by target or show metadata from the target object. If it is an external resource, shouldn't it be added in the CE anyway?
- Are multiple targets allowed? e.g.
target: [URL]VStarget: URL
There was a problem hiding this comment.
Ideally it should support both (internal) CE identifiers and (external) URIs. If this cannot be implemented due to graphql or neo4j limitations, we could indeed build a service that generates thin wrappers (probably DigitalDocuments) corresponding to external resources. I suspect this could become part of the client-side annotation code...
Multiple targets must be supported. One option to simplify things is to always return a list of targets, even where there is only 1 member.
Empty lists (0 targets) are not allowed.
There was a problem hiding this comment.
I think that Christiaan makes a good point here - we don't have to follow the ontology definition in the graphql interface as tightly as I have here. We could have something like an interface to define an AnnotationTarget, which is a union that can be either a link to a thing in the CE, or an external URL (e.g. like a join table in sql). The jsonld generator can then take this and format it correctly. We can also use a similar technique in motivatedBy (a standard web annotations motivation, or a custom one that we create) and body (a link to a textualbody or a URL to an external body).
My original idea was to make as few changes as possible to the jsonld converter, but it seems likely that we'll need to have specific converter modules for specific data types. I'll re-think this architecture.
| # TODO: Motivation can also be defined by us, therefore should also be an ID/UUID | ||
| # TODO: in GraphQL, how do you allow this to be either an enum or a string? | ||
| # We want the output of this to be a URI of the motivation, so we just set it to | ||
| # a [URI] for now so that we output the URI instead of the enum name | ||
| "http://www.w3.org/ns/oa#Motivation" | ||
| motivation: [URL] |
There was a problem hiding this comment.
Motivation is the type, not the property of Annotation right?
There was a problem hiding this comment.
Indeed.
http://www.w3.org/ns/oa#Motivation is the type
http://www.w3.org/ns/oa#motivatedBy is the property (predicate)
alastair
force-pushed
the
feat/annotations
branch
from
7609dff
to
fc403cb
Compare
|
Hi @alastair, what is the current status of this pull request? |
|
This week I'm going to finish collecting additional requirements for other use-cases. I hope to have it mostly finished by the meeting on the 20th. |
|
Cool, we are going to make a few changes in the upcoming weeks. Although, I don't think this will collide with this pr. |
|
I'm happy to work around any of your changes if needed 👍 |
|
Replaced by #100 |
This is based on the work that @musicog and I did getting the annotations demo for the music scholars use-case.
The plan is to use this work to make a generic annotations storage system that can be used by all use-cases.
Work-in-progress for now