W3C home > Mailing lists > Public > public-annotation@w3.org > January 2016

Re: Question on qualified linking between two resources

From: Jacco van Ossenbruggen <Jacco.van.Ossenbruggen@cwi.nl>
Date: Mon, 18 Jan 2016 18:38:31 +0100
Cc: Hugo Manguinhas <Hugo.Manguinhas@europeana.eu>, W3C Public Annotation List <public-annotation@w3.org>, public-openannotation <public-openannotation@w3.org>
Message-Id: <486C5B5A-B426-49CC-A720-12C923DCEF14@cwi.nl>
To: Robert Sanderson <azaroth42@gmail.com>

> On 18 Jan 2016, at 17:19, Robert Sanderson <azaroth42@gmail.com> wrote:
> 
> There isn't a specific slot in the model for putting a predicate that should be associated between body and target resources.

We’ve had this discussion year ago on the OA list, so I’m not going to repeat why I think the model deserves to have such a specific slot (e.g oa:hasPredicate or something similar to support existing applications that want to upgrade there triples that have been added using an annotation process to comply to our model). 

But I still think Hugo’s problem will be a frequent scenario: say Alice is a user familiar with RDF, and she knows that a specific triple is missing while it should be there (e.g. <data.europeana.eu/item/1> edm:isSimilarTo  <data.europeana.eu/item/2>.)
She sees an annotation API that allows adding annotations to body<data.europeana.eu/item/1>
She then quickly looks up in the model’s spec on how to express that single triple using the annotation model. It initially looks simple: subject is the body, object is the target, but … how to do the predicate? looking further ...
... surprise, surprise, she cannot find it in the spec (so Alice thinks she has to be missing something very basic)

So if adding the predicate slot to the model is not an option, I think we should at least help users facing this scenario by giving them some clear guidelines early in the specs on how to express annotations that have the same or similar intended semantics as a single simple RDF triple.

Cheers, Jacco
Received on Monday, 18 January 2016 17:39:10 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:43 UTC