The need for a "predicate" relationship (was Q: how to encode annotation "roles")

On 13-06-12 15:50, Rob Sanderson wrote:
> Hi Jacco,
>
> This is a tricky issue, as we don't want to re-invent RDF, encoded in RDF! :)

Well... I assumed you do want to support annotation practices that are 
now common practice outside the RDF world, but also those that are 
common practice within the RDF community, right?  For me, the first 
example in the RDF spec [1], stating that Dave Beckett is the editor of 
some webpage, is sort of the "Hello World" example of RDF, but it could 
also be a very good example of an annotation of a web page.  As it 
stands now, it remains unclear how to represent such a basic annotation 
in OA, because I do not know where to put the ex:editor URI.
> In an early version of the Open Annotation Collaboration schema, we did have a "predicate" relationship to make the relationship explicit.

Yes, that is exactly what I was looking for!

> This was seen as very strange by the people who reviewed it, as the object of the triple was a predicate. Nothing prevents this, but it's not a common pattern.

I agree it might not be a common pattern in simple tagging platforms.  
In such a context, the fact that the Body is somehow "about" [2] the 
Target is intentionally vague, as it should be: stronger claims on the 
aboutness relation is often a form of overcommitment in tagging 
contexts.  So OA should not encforce anything here.

But I would claim it is a very common pattern in many other annotation 
contexts, and that there should be an option to use the pattern for 
those who need it.  Here are a few example use cases I've came across:

In the art domain people are routinely using  annotation software for 
annotating artworks in their collection.  The data stored for each 
annotation in this domain looks a lot like the data in the OA model: 
Body, Target, Agent, Timestamp, etc. The UIs of the annotation software 
typically have multiple fields to allow users annotate different aspects 
of the artwork.  For example, in a self-portrait of Van Gogh, you want 
to record the fact Van Gogh is not only the painter of the work, but is 
also depicted on the work.  Roundtripping the OA data would require it 
contains sufficient information that the application can figure out to 
which UI field each annotation belongs.

In the news domain, many people use the IPTC header [3] annotation 
fields that are built into photo applications, including Adobe 
Photoshop.  It is  important to know, for each annotation, to which IPTC 
field it belongs.  Exporting by embedding these annotation in the TIFF 
or JPEG also requires having this information.

Finally, in the library domain, I think people would find it very 
strange to find out they will not be able to make "Dublin Core"-like 
annotations because there is no room in the specs for making even the 
basic 15 DC elements explicit.  So, a first question from this community 
could be: How do I indicate the difference between annotating a dc:title 
from a dc:creator in OA?

> At the moment, then, we would recommend using classes if it's necessary to explicitly model individual relationships, but with the caution that you might end up duplicating every single relationship in RDF into a subclass of annotation.

Yes, that would indeed be a problem in the examples above. Apart from 
the fact that for interoperability, you need to model the relationship 
between the OA class and the orginal predicate...

>
> Any further thoughts from the group on this issue are appreciated, especially from a Linked Data perspective?

I hope the examples above helped explaining the issue!  I would like to 
see an optional  oa:predicate on oa:Annotation instances.
In some sense this would also acknowledge that each annotation is in 
fact and extended and reified RDF triple...

Jacco

[1] 
http://www.w3.org/TR/REC-rdf-syntax/#section-Syntax-node-property-elements
[2] quotes used as in the first line of 
http://www.openannotation.org/spec/core/#AnnoBodyTarget
[3] http://en.wikipedia.org/wiki/IPTC_Information_Interchange_Model

Received on Thursday, 14 June 2012 09:20:17 UTC