W3C home > Mailing lists > Public > public-annotation@w3.org > July 2015

RE: [model] Clarifying annotation architecture

From: Timothy Cole <t-cole3@illinois.edu>
Date: Fri, 24 Jul 2015 10:15:19 -0500
To: "'Frederick Hirsch'" <w3c@fjhirsch.com>, "'Robert Sanderson'" <azaroth42@gmail.com>
CC: "'W3C Public Annotation List'" <public-annotation@w3.org>
Message-ID: <019301d0c623$8e6e4250$ab4ac6f0$@illinois.edu>
Fredrick-

So this tension you describe between the plain-JSON implementer point of view and JSON-LD implementer point of view affects the trade-offs we make in the model between expressivity and omission.  This has come up before, but as you suggest, it is well illustrated in the current discussion about whether to provide a means in the model to differentiate the motivation (i.e., role) of each body in a multi-body annotation. 

 If we wish to do so and at the same time wish to stay aligned with RDF, then we create a feature in the annotation data model that may seem counter-intuitive to plain-JSON implementers not familiar with RDF. Or we create a feature that is not RDF-compatible. Either way there is some price to pay.

But the annotation data model is not meant to express every facet of all possible annotation use cases. We would  never finish if this was our goal. There are any number of features supporting greater expressivity/efficiency that have been left out of the annotation data model (cf. [1, 2, 3, ...]). So, as the CG did, we could decide to leave out the ability express (using OA semantics) the different motivations/roles of each body in a multi-body annotation.  

No confusion between plain-JSON and JSON-LD ensues. Arguably we'll be hurt less by leaving out generic support for this particular class of use cases out than by including a construct that confuses plain-JSON implementers (or violates the RDF model).   Implementers may (in existing or their own, community-specific namespaces) introduce means for expressing the distinctions they need. (This could have implications for how annotations are validated, but given other features omitted from the annotation data model, these challenges are present whether we add in a body-level motivation feature or not.) Or implementers who find they need this level of expressivity may decide they can do what they need for their specific use cases using specialized ontologies and existing RDF-compatible semantics (e.g., @type) or may decide it's worth it to simply mint more annotations and use the annotation-level motivatedBy predicate as already available in the model. 

Now that Rob and you have helped to clarify how adding a way to express individual body-level motivations/roles to our model is likely to highlight differences between plain-JSON and JSON-LD viewpoints, perhaps the WG should reconsider whether adding to our core annotation data model at this time the expressivity to describe the role of each body in a multi-body annotation is really worth it?  One advantage of not doing so at this time is that we would be able to see how often implementers find they need this expressivity, understand better the use cases that require it, and learn from them how they actually want to implement it. Subsequent work on updates of the annotation data model would be informed by what we learn from implementers -- generally a good thing.

Thanks,

Tim Cole

[1] http://www.w3.org/community/openannotation/wiki/Open_Issues 
[2] http://www.w3.org/community/openannotation/wiki/Challenges 
[3] http://www.w3.org/community/openannotation/wiki/Incubator 

-----Original Message-----
From: Frederick Hirsch [mailto:w3c@fjhirsch.com] 
Sent: Thursday, July 23, 2015 12:28 PM
To: Robert Sanderson <azaroth42@gmail.com>
Cc: Denenberg, Ray <rden@loc.gov>; W3C Public Annotation List <public-annotation@w3.org>
Subject: Re: [model] Clarifying annotation architecture

Rob

I understand and value the benefits of JSON-LD, linked data etc, very enthusiastic about it in fact.

Simply trying to understand the plain JSON implementer point of view and whether it is possible to further simplify to avoid confusion.  Unfortunately the answer appears to be no.

Between us I think we correctly summarized the source of possible confusion.

Thanks

regards, Frederick

Frederick Hirsch


www.fjhirsch.com
@fjhirsch



> On Jul 23, 2015, at 12:19 PM, Robert Sanderson <azaroth42@gmail.com> wrote:
> 
> 
> Hi Frederick,
> 
> Yes, I totally understand the desire to use plain JSON, and why the additional objects look unnecessary.  Your JSON looks very good, in that context.
> 
> But that's not what we're doing, and if we were we would have a very different model that didn't need to have things like SpecificResource at all.  Again, if people care enough to understand the reasons, then that's great.  If they don't, that's great, but arguing about whether something is correct or not without understanding the requirements results in 100s of emails across multiple threads.  Whether it's valuable of not ... it has advantages and disadvantages. (see at the bottom if you care).
> 
> The context mapping in JSON-LD only the keys and values, it can't change the structure. So it can't introduce new nodes/objects, move existing ones around, or delete them.  There's one additional restriction, it can't do lists of lists, because the processing to disambiguate what is meant at the RDF level is significant.
> 
> So similarly, we can't map from a literal body directly to a body with a resource/object in the context.  Either of those could be done with a little bit of code in both the client and server ... but that would defeat the purpose.
> 
> Rob
> 
> An overview of the ups and downs of RDF, especially slides 3-18:
>   
> http://www.slideshare.net/azaroth42/rdf-resource-description-failures
> 
> Disadvantages:  
> * This situation where you need to create new resources to (essentially) reify relationships. 
> 
> Advantages: 
> * There's a global graph that everyone contributes knowledge to, rather than a bunch of documents that are all stand-alone.  
> * There's rich data that you can use, without transforming it on a 
> case by case basis, as everything has a unique URI in a standardized 
> framework
> * Others can incrementally add information about your resources in a 
> global crowd-sourcing kind of way
> 
> 
> 
> On Thu, Jul 23, 2015 at 8:34 AM, Frederick Hirsch <w3c@fjhirsch.com> wrote:
> (not as chair)
> 
> Rob
> 
> yes that helps quite a bit.
> 
> I still see a problem explaining to JSON (non-turtle, non-RDF, non-JSON-LD) people why what looks like straightforward JSON is wrong, since they don't care about SpecificResources and triples..
> 
> if there were no JSON-LD and no linked data, the following *would be fine* JSON, right?
> 
> {
>   "kind": "Annotation",
>   "target" : "some-uri.html",
>   "body": {
>     "source: "meme-image.jpg",
>     "role": "commenting"
>   }
> }
> 
> This is why the problem is "non-obvious".
> 
> Is there a way to transform this via implementation to using SpecificResource by default? Did this come up in the JSON-LD discussions?
> 
> Does this make the issue clear from the JSON implementer point of view?
> 
> regards, Frederick
> 
> Frederick Hirsch
> 
> fjhirsch.com
> @fjhirsch
> 
> 
> > On Jul 23, 2015, at 11:02 AM, Robert Sanderson <azaroth42@gmail.com> wrote:
> >
> >
> > Sure!
> >
> > Good:
> >
> > _:anno a oa:Annotation ;
> >   oa:hasTarget <some-uri.html> ;
> >   oa:hasBody _:specres .
> >
> > _:specres a oa:SpecificResource ;
> >   oa:motivatedBy oa:commenting ;
> >   oa:hasSource <meme-image.jpg> .
> >
> >
> > Bad:
> >
> > _:anno a oa:Annotation ;
> >   oa:hasTarget <some-uri.html> ;
> >   oa:hasBody <meme-image.jpg> .
> >
> > <meme-image.jpg> oa:motivatedBy oa:commenting .
> >
> >
> > (Or substitute some new predicate like oa:role or whatever, per Tim 
> > Cole's comment that specific resources aren't really motivated in 
> > the same way that annotations are)
> >
> > Hope that helps :)
> >
> > Rob
> >
> >
> > On Thu, Jul 23, 2015 at 7:58 AM, Denenberg, Ray <rden@loc.gov> wrote:
> > 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> 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] 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
> > jjett2@illinois.edu
> >
> >
> >
> > On Wed, Jul 22, 2015 at 4:00 PM, Denenberg, Ray <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]
> > 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
> >
> >
> >
> >
> > --
> > 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
Received on Friday, 24 July 2015 15:16:34 UTC

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