search

perseids-project / plokamos

RDF-based annotations for Perseids
MIT License
6 stars 2 forks source link

Think about annotation body architectures #72

Closed fbaumgardt closed 7 years ago

fbaumgardt commented 8 years ago

The main question is how we design the annotation body. Currently we have two separate architectures:

1) Annotations body in a named graph which is object of oa:hasBody relation. This allows for more than one annotations per annotation frame. Example: https://github.com/perseids-project/hypothesis-client/blob/64cf27b0659a886a3c819c0a34b24597ff64b6e6/spec/support/converted.json#L37
An example of multiple annotations in a single frame is urn:cite:perseus:pdljann.8cf78341ca9201328b610ada42b1fd09
2) Annotation bodies as a resource which is object of oa:hasBody relation. This restricts us to single annotations per frame but frees up the named graphs axis to segment the information space, e.g. by annotation type or target. Additionally, this would allow us to potentially specify (and validate against) a type hierarchy of annotation bodies. Examples: https://github.com/perseids-project/perseidsMapping/blob/master/triangleSci/htrsample.ttl#L17 & https://github.com/perseids-project/annotation-editor/blob/master/tests/data/pelagios-test.rdf#L34

What we want to figure out is whether there is need for both annotation body types and if one is preferable over the other, keeping in my envisioned future additions in terms of annotation types.

fbaumgardt commented 8 years ago

@balmas This is the issue discussing the layout of annotation bodies.

balmas commented 8 years ago

@fbaumgardt

Does option 2 necessarily rule out option 1? I.e. couldn't a named graph be a resource which is the object of the hasBody relation?

I do think we need to support both types of annotations, one way or another. We are going to have simple annotations which simply point at resources which are not graphs (this is the case with the characterizations and attestations, as well as places and persons) but for anything other than the simple cases, we want to be sure the annotation body itself can also be a complex typed resource, whether a graph, or a specific type defined such as that of the lawd:TextReuse class.

The choices made in https://github.com/perseids-project/perseidsMapping/blob/master/triangleSci/htrsample.ttl wrt to the use of lawd:TextReuse and lawd:ObserverRoleAssociation were deliberate and had two main goals, as I recall them:

  1. to make sure that the annotation body could stand on its own, and not be dependent upon the structure of the OA wrapper (i.e. we didn't want to rely upon convention to say this is what an annotation expressed in this way via OA means)
  2. to enable future semantic reasoning on the annotations themselves. this applies particularly to the way we structured the ObserverRoleAssociation.