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

Re: Question on qualified linking between two resources

From: Ivan Herman <ivan@w3.org>
Date: Wed, 20 Jan 2016 09:08:05 +0100
Cc: W3C Public Annotation List <public-annotation@w3.org>, public-openannotation <public-openannotation@w3.org>
Message-Id: <41764F5F-BFA5-45BE-9CEA-26CAAE2EE842@w3.org>
To: Robert Sanderson <azaroth42@gmail.com>, Jacco van Osenbruggen <Jacco.van.Ossenbruggen@cwi.nl>, Hugo Manguinhas <Hugo.Manguinhas@europeana.eu>
Beyond the arguments Rob expressed below (which I agree with)... Jacco, you said:

"specific triple is missing while it should be there (e.g. <data.europeana.eu/item/1> edm:isSimilarTo <data.europeana.eu/item/2>.)"

Why "should be there"? The annotation vocabulary is not meant to cover all possible relationships among resources. If an (RDF aware) application wants to use and add such a triple the overall information set in its own namespace then it can do it without further ado. This can be done in Turtle; but for an RDF aware application the JSON encoding is in fact JSON-LD, ie, nothing else than RDF, ie, such triple can be added, too. I am not sure why such facilities should be built into the core beyond what RDF can already do. I guess I am missing something. Alternatively, defining a separate motivation that can be used for the Annotation as a whole seems to be perfectly adequate, too (sure, the client of the annotation would have to have its own logic to deduce that extra triple in that case).

As Rob said, a general solution would probably require the use of named graphs (I do not even want to mention that stuff whose name begins with 'rei…'). If you are an RDF aware application then you can do that, using either the built-in facilities of JSON-LD, or TriX instead of Turtle. But I do not think this should be added to the WA model, it would utterly complicate things.

Ivan

P.S. See also my comment on another issue[1], more exactly paragraph starting by "The underlying issue…". This is highly relevant for this question, too.


[1] https://github.com/w3c/web-annotation/issues/137#issuecomment-172872489



> On 18 Jan 2016, at 20:32, Robert Sanderson <azaroth42@gmail.com> wrote:
> 
> 
> 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 reasons:
> 
>   *  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 mix)
>      2.  Create new, explicit motivations (creates a complete parallel universe)
>      3.  Add/Use a body with the full triple/graph/data  (needs to be parsed separately, repeats information)
> 
> 
> Rob
> 
> 
> 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


----
Ivan Herman, W3C
Digital Publishing Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
ORCID ID: http://orcid.org/0000-0003-0782-2704





Received on Wednesday, 20 January 2016 08:08:19 UTC

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