F2F Decision: Semantic and Data Annotations

This part of the discussion covered the topics in the section on
Semantic and Data Annotations in the extension document.
Please see:  http://www.openannotation.org/spec/extension/#Semantic

The proposals were:

(1)  Remove the section about Structured Resources, as there is no
reasonable way to reproduce them from a triple store (although from a
Quad store is possible)

This was accepted, and the section will be removed.

If there is semantic information that should be conveyed as the body
of an Annotation, then it should follow the regular pattern of a
resource with a URI.  That resource can be either dereferenced to
provide a machine readable representation, in any format, or embedded
inline within the annotation using the Content in RDF specification,
as per human readable embedded resources.
Alternatively, the section on Named Graphs will remain as is, and the
method described there can be used.


(2)  Remove oax:hasSemanticTag, as now there are multiple bodies, it
is unnecessary and confusing.

This was accepted in general, with ongoing discussion:

oax:hasSemanticTag was a compromise in the original specification
designed to allow a single annotation to contain 0-1 bodies and 0-*
tags without having to mint entirely new annotations for each tag.
Now that a single annotation may have multiple bodies, that
requirement no longer exists, and hasSemanticTag can be removed in
place of simply multiple bodies (either sets or individuals).

The discussion turned to how to know whether or not a URI was a
semantic tag or not without the predicate, and hence whether the
resource should be dereferenced or not.  The proposal was that typing
could be used: a real world object should not be dereferenced, and a
statement to such effect is globally true.  A counter argument was
that some resources are used as both real world objects and documents,
and different annotations should treat those two uses of the same URI
differently.
Thus oax:hasConceptualBody and oax:hasConceptualTarget were proposed
in order to cover this situation.

However, this proposal is not consistent with the multiple resources
consensus, as it would also require hasConceptualDefault and
hasConceptualItem in order to link conceptual resources in a set, list
or choice.  A counter-counter-proposal was to mint new URIs for the
conceptual use of a URI that is dereferencable and link them to the
URI of the document.


Thanks!

Rob & Paolo

Received on Monday, 1 October 2012 20:50:06 UTC