Triannon should transform internal anno blank nodes

sul-dlss-deprecated / triannon

Rails engine for working with storage of OpenAnnotations stored in Fedora4

Other

13 stars 1 forks source link

Triannon should transform internal anno blank nodes #134

Open ndushay opened 9 years ago

ndushay commented 9 years ago

The outer node of an anno gets an id, but if there is an internal blank node on an incoming anno (e.g. ContentAsText body), the code currently serves out the internal node as blank. We don't want this.

@azaroth42 will provide a spec as to how these annos should look on output.

dazza-codes commented 9 years ago

For blank node inputs for 'hasBody', should they be rejected on POST and/or PUT?

ndushay commented 9 years ago

nope. blank node inputs for inner nodes ok.

azaroth42 commented 9 years ago

The behavior I would expect is:

Until we have provenance tracking, reject POSTs where the annotation has a URI. (As we can't create that URI)
When we've tackled provenance, the URI should be associated with the annotation using oa:equivalentTo, as per: http://www.openannotation.org/spec/core/publishing.html#Equivalence
Any non oa:Annotation blank node should be given a URI by Fedora4, and that URI should be returned within the annotation graph. In JSON-LD, that would be with "@id"
Any specific resource should also be rejected if it has a URI until we tackle provenance, for the same reasons (we can't serve the specific resource from its original URI)

ndushay commented 9 years ago

Rob, you gave us a spec for specific resource, which i implemented. I think we store them in Fedora as type externalReference https://github.com/sul-dlss/triannon/blob/master/lib/rdf/triannon_vocab.rb at least for now.

So we are currently

accepting blank nodes; letting Fedora do its thing, and returning them as blank nodes when annos are served back out.
accepting SpecificResource; changing them to externalReference thingies, and returning them as SpecificResource when the annos are served back out.