W3C home > Mailing lists > Public > public-openannotation@w3.org > February 2016

RE: Question on qualified linking between two resources

From: Hugo Manguinhas <Hugo.Manguinhas@europeana.eu>
Date: Thu, 18 Feb 2016 15:04:07 +0000
To: Robert Sanderson <azaroth42@gmail.com>
CC: public-openannotation <public-openannotation@w3.org>, "W3C Public Annotation List" <public-annotation@w3.org>
Message-ID: <6D0598B03E7E9848A4287E110919B4BA011566AF@MBX-SRV-P200.wpakb.kb.nl>
Hi Rob, all,

Thanks again for your help and feedback!

Please see my answers below...

Best regards,
Hugo

Hugo Manguinhas
Technical R&D Coordinator

T: +31 (0)70 314 0967
M:
E: Hugo.Manguinhas@europeana.eu
Skype: hugo.manguinhas


Be part of Europe's online cultural movement - join the Europeana Network Association: http://bit.ly/NetworkAssociation

 #AllezCulture!
Disclaimer: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. If you are not the named addressee you should not disseminate, distribute or copy this email. Please notify the sender immediately by email if you have received this email by mistake and delete this email from your system.
________________________________
From: Robert Sanderson [azaroth42@gmail.com]
Sent: 08 February 2016 18:18
To: Hugo Manguinhas
Cc: public-openannotation; W3C Public Annotation List
Subject: Re: Question on qualified linking between two resources


I personally don't like the predicate-as-tag approach, as the predicate does not individually tag both bodies. It seems strange to say edm:similarTo is somehow about item/1

HM: well, tagging is quite a loose concept, it does not prescribe any formal meaning... but I agree that it can be confusing when compared to tagging with resources or concepts which is a more common use case.

I would avoid trig:Graph as technology specific and not well used.  In JSON-LD, there's the @graph construct that it would conflict with.

HM: I assume that "@graph" could then be an option?

As per my message in the thread above, my approach would be to serialize the statement to a body rather than including it as an extension point in the annotation.  That way you create a future proof pattern (as you could change what goes in the body to include more triples, or a different syntax, or something other than RDF entirely) that a regular annotation client can see and ignore, without requiring an additional context to add the edm namespace.  Though you would need to include @prefix in the turtle.

HM: It seems a smart solution, but this will bring a significant overhead for both clients and servers that need to support/handle that information, especially given that several serialization formats could be used and would need to be supported instead of just relying on only one, JSON-LD... I would rather have it modeled in some way even if it is not perfect than having these disparate formats/representations which just introduce another level of complexity... btw, a regular annotation client can always discard the body if it does not support it.

HTH,

Rob


On Mon, Feb 8, 2016 at 5:53 AM, Hugo Manguinhas <Hugo.Manguinhas@europeana.eu<mailto:Hugo.Manguinhas@europeana.eu>> wrote:
Hi all,

I am reviving this thread as I am still not completely confident with the proposal…

.. .what do you think of the whole proposal?
... will it be alright to have as targets the two objects and the body(ies) conveying the relation (whether as a semantic tag, as an RDF statement or even as a text informally explaining the relation)?

@Rob, all, what is you take on trig:Graph for the RDF statement? do you feel that it is necessary so that the "suggested" statement (relation) remains semantically decoupled from the Annotation, or do you feel that it should be part of it, like in your example/suggestion...
... btw, the issue that I see with the example below is the body is referencing the Resource and not the statement, so even if a trig:Graph is not used, the body would still need to be an rdf:Statement.

I really appreciate all your feedback!

Kind regards,
Hugo

________________________________________
From: Hugo Manguinhas
Sent: 22 January 2016 13:41
To: Ivan Herman; Robert Sanderson; Jacco van Osenbruggen
Cc: W3C Public Annotation List; public-openannotation
Subject: RE: Question on qualified linking between two resources

Hi Rob, Jacco, Ivan, and all,

Thank you all for your help!

I must say I like @Jacco’s point on having a property (oa:hasPredicate or even rdf:property) to state the type of relation specially if this would allow client applications to search using it as a search criteria... however, I agree with Rob that it would better fit the web annotation principles to model it somehow within the body as it is where all information that the user wishes to convey about the target(s) is placed.

about Rob’s first suggestion, I believe that pattern seems sufficient (@Rob, should the body btw be a trig:Graph as defined in OA?), however, I am concerned that non-RDF engines will not easily consume such data... and also it will require some effort to support a search scenario using both the predicate and the actual “domain” of the statement. Regarding the one that uses the turtle representation, It would again create an overhead for machines to interpret the data and it would make it even more difficult to search. I saw in Rob’s suggestion (last email) that the domain and range of the statement are both referred as targets which I found really interesting as it makes complete sense from the conceptual point of view and from a search perspective it allows for client applications to pull in and display annotations for both forward and backward links... great!

… so first, i would propose to expand Rob’s first suggestion (without “@graph”) to add another target:
{
  "motivation": "linking",
  "body": {
    "@id": "http://data.europeana.eu/item/1",
    "edm:isSimilarTo" : "http://data.europeana.eu/item/2"
  },
  "target": [ "http://data.europeana.eu/item/1", "http://data.europeana.eu/item/2" ]
}

… if it is relevant to promote the property and make it more explicit and thus easily searchable, I would propose to add an additional body with the property as a tag... allowing for basic client applications to process the data without understanding the RDF semantics:
{
  "motivation": "linking",
  "body": [
    {
      "@id": "http://data.europeana.eu/item/1",
      "edm:isSimilarTo" : "http://data.europeana.eu/item/2"
    },
    {
      "@type": "SpecificResource",
      "source": "http://www.europeana.eu/schemas/edm/isSimilarTo",
      "role": "tagging"
   }
  ],
  "target": [ "http://data.europeana.eu/item/1", "http://data.europeana.eu/item/2" ]
}

This last proposal would also allow to add yet another body with a possible comment from the user, expressing in a human readable form the relation between the two items.

Would both proposals be alright? what do you think?

Finally, one last question for @Rob, is it really important to state the bodies within a oa:Choice? couldn’t they just coexist together as separate bodies? or is it assumed that they would be interpret as a whole?

Thanks again for all your comments and looking forward for your feedback!

Best regards,
Hugo

________________________________________
From: Ivan Herman [ivan@w3.org<mailto:ivan@w3.org>]
Sent: 20 January 2016 09:08
To: Robert Sanderson; Jacco van Osenbruggen; Hugo Manguinhas
Cc: W3C Public Annotation List; public-openannotation
Subject: Re: Question on qualified linking between two resources

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<http://data.europeana.eu/item/1>> edm:isSimilarTo <data.europeana.eu/item/2<http://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<mailto: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<mailto:Jacco.van.Ossenbruggen@cwi.nl>> wrote:
>
> > On 18 Jan 2016, at 17:19, Robert Sanderson <azaroth42@gmail.com<mailto: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<http://data.europeana.eu/item/1>> edm:isSimilarTo  <data.europeana.eu/item/2<http://data.europeana.eu/item/2>>.)
> She sees an annotation API that allows adding annotations to body<data.europeana.eu/item/1<http://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<tel:%2B31-641044153>
ORCID ID: http://orcid.org/0000-0003-0782-2704






--
Rob Sanderson
Information Standards Advocate
Digital Library Systems and Services
Stanford, CA 94305
Received on Thursday, 18 February 2016 15:04:44 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:38:28 UTC