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

Re: Question on qualified linking between two resources

From: Robert Sanderson <azaroth42@gmail.com>
Date: Mon, 18 Jan 2016 11:32:04 -0800
Message-ID: <CABevsUEQernuSFgBCmGmM63eno2EiMBfK1sY3a_uRRAmL2kX2Q@mail.gmail.com>
To: Jacco van Ossenbruggen <Jacco.van.Ossenbruggen@cwi.nl>
Cc: Hugo Manguinhas <Hugo.Manguinhas@europeana.eu>, W3C Public Annotation List <public-annotation@w3.org>, public-openannotation <public-openannotation@w3.org>
The other option is to put it in the body... consider the following:

Alice wants to say that the two resources she can see on screen (item/1,
and item/2) are similar to each other.  She types into her client "These
two items are very similar to each other".

In shorthand:
  "body": {"text": "These two items are very similar to each other"},
  "target": ["item/1", "item/2"]

Beatrice wants to say the same thing, but in a machine readable way as well
as human readable.  She knows RDF and creates the appropriate triple.

  "body": {
    "type": "Choice",
    "items": [
          "text": "These two items are very similar to each other",
          "language": "en",
          "format": "text/plain"
          "text": "item/1 edm:similarTo item/2 .",
          "format": "text/turtle"
  "target": ["item/1", "item/2"]

The pushback against adding the link to the predicate is for the following

  *  We don't want to reinvent Named Graphs, RDF reification, or even just
RDF triples.  And adding an explicit predicate to use between them is very
close to that.  (Arguably it /is/ that)

  *  When there isn't exactly one body and exactly one target, things get
very confusing. Do all of the bodies have the same relationship to all of
the targets? What if there's no body, then there's no subject?

  * It's a specific technology choice to use RDF. It should also be open to
assertions in other languages, if we're going to tackle it, and thus the
body option above.

  * There are already ways to do it, just that they're not pretty:
     1.  Add the triple into the graph (need a @context, gets lost in the
     2.  Create new, explicit motivations (creates a complete parallel
     3.  Add/Use a body with the full triple/graph/data  (needs to be
parsed separately, repeats information)


On Mon, Jan 18, 2016 at 9:38 AM, Jacco van Ossenbruggen <
Jacco.van.Ossenbruggen@cwi.nl> wrote:

> > 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

Rob Sanderson
Information Standards Advocate
Digital Library Systems and Services
Stanford, CA 94305
Received on Monday, 18 January 2016 19:32:34 UTC

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