Frequently Asked Questions (FAQ)

1. Why do we create Annotation nodes?
2. Why shouldn’t I use a URI with a fragment identifier?
3. Why can’t I just have a literal for the body?
4. Wouldn’t it be easier to query if there was a link between Annotation and Source?

1. Why do we create Annotation nodes?

We see an Annotation as a sort of reification of the relationship between body and target – keeping in mind that the body is not always present and that there can be multiple targets. The provenance of the annotation can be different than the provenance of the body, thus the annotation deserves its own URI. For example, I can annotate an image of the ‘Mona Lisa’ painting with a video that explains it. The painting has a well defined provenance (created by Leonardo Da Vinci), the digital image has a creator as well and, most likely the creator of the video is different than the creator of the image. Defining an annotation node allows to nicely keeping track of all these provenance details.

The Annotation URI allows also to address each Annotation item independently. Therefore, we can properly identify and annotate annotations.

2. Why shouldn’t I use a URI with a fragment identifier?

Please see this explanation of the issues.

3. Why can’t I just have a literal for the body?

There are several reasons for this design choice:

• Literals have no identity, and thus cannot be referenced. If the body was a literal, it would be impossible to refer to it directly.
• It is inconsistent with the rest of the model which allows any resourceas a Body or Target, and would thus be a special case just for text in the body.
• Literals can have language associated with them in RDF using the @lang construction, and format using the explicit datatyping via ^^, however there are other aspects of a resource that are important for interpretation that cannot be associated with a literal. Examples would include directionality of the text and encoding, plus of course metadata such as authorship, date and so forth.
• If a server wished to extract the text and make it a resource with an HTTP URI, as per publishing resources, it would not be possible to assert equivalence or provenance.
• The cost of just following the specification is minimal, one additional triple over the literal case.

4. Wouldn’t it be easier to query if there was a link between Annotation and Source?

Currently there are two locations where the full URI of a resource being annotated can be: either the object of oa:hasTarget, or the object of oa:hasSource. For a single SPARQL query, it thus requires a UNION query between these two. An alternative pattern that has been suggested is to have a relationship from the Annotation directly to the Source, but this approach has been rejected for the following reasons.

To avoid a Union query, a developer would need to rely on the presence of a direct relationship between annotation and the full URI for the target. In the case of a Specific Target, it would be Annotation -> Source and in the case of a regular target it would be Annotation -> Target. Thus there would need to be two relationships between annotation and target in the simple case to have this query work, hasTarget and hasTargetSource. If the relationship was not present in the simple case you would still need a Union query.

Unless the relationship was mandatory in all cases, even though it’s redundant, you would still need to do the union query to be certain. And even if the specification did say it was mandatory, many developers would likely ignore it.

To spell it out, you would need to make the following mandatory for all simple annotations:

    _:Anno a oa:Annotation ;
        oa:hasTarget _:Target ;
        oa:hasTargetSource _:Target ;
        oa:hasBody _:Body .

Which is considered to outweigh the benefit in making a particular technology slightly simpler to use at the server side when building a repository of annotations. This link could be added at ingest time rather than at creation time for those systems that could profit from it. Other systems may not find this difficult, such as document rather than graph centric indexing.