On Tue, Jun 24, 2014 at 9:03 AM, Robert Sanderson <[email protected]> wrote:
> > Hi Nick, Randall, > > On Tue, Jun 24, 2014 at 2:15 AM, Nick Stenning <[email protected]> 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.
_______________________________________________ annotator-dev mailing list [email protected] https://lists.okfn.org/mailman/listinfo/annotator-dev Unsubscribe: https://lists.okfn.org/mailman/options/annotator-dev
