RE: [model] Clarifying annotation architecture

Rob – still trying to grasp this.  Could you show how this would look done the “right” way, I.e. as a specific resource,

AND   please write both (the bad example and the good)  in turtle, not json-ld.

Thanks.

Ray


From: Robert Sanderson [mailto:azaroth42@gmail.com]
Sent: Thursday, July 23, 2015 10:30 AM
To: Denenberg, Ray
Cc: Jacob Jett; Frederick Hirsch; W3C Public Annotation List
Subject: Re: [model] Clarifying annotation architecture


We shouldn't (must not) do this:

{
  "@type": "Annotation",
  "target" : "some-uri.html",
  "body": {
    "@id": "meme-image.jpg",
    "role": "commenting"
  }
}

As meme-image.jpg might have another role in a different annotation (replacing, in Doug's example)

Rob


On Thu, Jul 23, 2015 at 6:37 AM, Denenberg, Ray <rden@loc.gov<mailto:rden@loc.gov>> wrote:
Hi Jacob – No, I’m afraid I don’t see that the “sky colored red” example applies to my question, however, if you (or someone) could write, in RDF syntax, an example annotation, which does specifically what it is we are saying we shouldn’t do …  specifically: attach a motivation to a body  (and more specifically, where the body is an image or some other non-rdf resource) ... that would help.
Thanks.

Ray

From: jgjett@gmail.com<mailto:jgjett@gmail.com> [mailto:jgjett@gmail.com<mailto:jgjett@gmail.com>] On Behalf Of Jacob Jett
Sent: Wednesday, July 22, 2015 5:16 PM
To: Denenberg, Ray
Cc: Robert Sanderson; Frederick Hirsch; W3C Public Annotation List

Subject: Re: [model] Clarifying annotation architecture

Hi Ray,

This is a distinctly RDF thing. Essentially the triples are all distinct assertions.

Imagine that I told you, "the sky is red". In ttl we might write the assertion this way --
     Sky colored Red .

This statement is true at certain points in time. Unfortunately RDF does not have a way to scope the assertion to certain points in time (or in the roles example, specific contexts). So from the SemWeb perspective "Sky colored Red ." and "Sky colored Blue ." are both true at all times and in all places. Using the specific resource allows us to scope the assertions, e.g., Sky@time@place colored Red .

Is that example helpful at all?

I think Rob's suggestion is a reasonable work around for this role issue. It should be invisible to those who don't care about SemWeb issues and makes the data reasonably actionable for those who do.

Regards,

Jacob


_____________________________________________________
Jacob Jett
Research Assistant
Center for Informatics Research in Science and Scholarship
The Graduate School of Library and Information Science
University of Illinois at Urbana-Champaign
501 E. Daniel Street, MC-493, Champaign, IL 61820-6211 USA
(217) 244-2164<tel:%28217%29%20244-2164>
jjett2@illinois.edu<mailto:jjett2@illinois.edu>

On Wed, Jul 22, 2015 at 4:00 PM, Denenberg, Ray <rden@loc.gov<mailto:rden@loc.gov>> wrote:
There is a fundamental piece of this that I’m missing.
{
  "@type": "Annotation",
  "target": "some-uri.html",
  "body": {
    "@type": "SpecificResource",
    "motivation" : "editing",
    "source": "meme-image.jpg"
  }

You create a new resource (specific resource) in order to associate a motivation (editing) with the original resource (source).

And you do this to avoid  “directly assigning a role to the original resource”.

I understand the reason why.  What I don’t understand is how it is proposed to do the latter in the first place.  In the example, the original resource is an image. Not like it’s an RDF description that you can stick an RDF  triple into.

What am I missing here?

Ray


From: Robert Sanderson [mailto:azaroth42@gmail.com<mailto:azaroth42@gmail.com>]
Sent: Wednesday, July 22, 2015 2:45 PM
To: Frederick Hirsch
Cc: W3C Public Annotation List
Subject: Re: [model] Clarifying annotation architecture




> * Associate the role with the body directly.  Fails because it makes the body un-reusable, which for the image/video or similar case is not acceptable.


This statement is a key issue and I think Doug was asking about this as well during the call.
The failure scenario is not clear. Un-resuable  : re-used by whom and for what?

Reused anywhere by anyone for anything, but most importantly reused as a body in a different annotation with a different role.
As per Doug's example, you could not use the meme image as a comment in one annotation and a replacement in another annotation.


If I forget the semantic web (for a moment) I can have an object, say a body, that has properties, including hasSegment or role and two bodies could have different values for the properties.

Sure. If I forget that I need to close my tags and put quotes around my single token attributes, I end up with SGML ... but that sure isn't XML.  Or if we conveniently forget about HTTP requirements, we could not worry about all those pesky headers. We could just stuff everything in the URL ... that would be much simpler, no? Then you would only ever need to do a GET, and could type it into your browser bar.


The only re-use issue would be an implementation optimization (e.g. I don't want to duplicate an embedded image/video to save space)

In semantic web terms:
annotation1 has body1.
annotation1 has body2.
body1 hasRole A.
body2 hasRole B.

annotation2 has body1
body1 hasRole B.

Now body1 has both A and B roles.


so where is the problem, and where is the re-use?

There was no problem until someone else (annotation2) also assigned a different role to the body, and now it has both of them at once.


> * Associate the role (motivation) with a specific resource. Works as expected without changing the semantics, breaking linked data, or introducing any new classes or properties.

isn't a body a resource? If it isn't a resource, what is it?

Well... the preferred answer would be yes, it's a resource.  But it's also a literal string :P
However snark aside, I'm not sure as to what's prompting the question?

Perhaps to clarify the bullet:  ... with a oa:SpecificResource.

{
  "@type": "Annotation",
  "target": "some-uri.html",
  "body": {
    "@type": "SpecificResource",
    "motivation" : "editing",
    "source": "meme-image.jpg"
  }
}

R


--
Rob Sanderson
Information Standards Advocate
Digital Library Systems and Services
Stanford, CA 94305




--
Rob Sanderson
Information Standards Advocate
Digital Library Systems and Services
Stanford, CA 94305