RE: My thoughts on the multi-body alternatives (as shown on Tim's wiki page)

Rob-

 

[Some of this may be moot given the thread Doug started, but I wanted to close the loop (and had some computer issues last night).]

 

Indeed, I had forgotten the non-body use of EmbeddedContent for the stylesheet and selector. (Would it be worthwhile creating a class and predicate name index for the model document?)  These additional uses of EmbeddedContent Class do make attaching hasRole less desirable (though not out of the question). I also take your point that allowing hasRole only on the SpecificResource class simplifies the filter pattern for including proper default type:value via framing (so they don't have to be explicit in the JSON). So assuming the following patterns are what you have in mind, I concur:

 

"body": {

   "role": "tagging" ,

   "source": "http://example.org/tagPlus1"

}

"body": {

   "role": "tagging" ,

   "source": { "value": "+1" }

}

Which look quite reasonable. The trade-off of not allowing hasRole on EmbeddedContent is that we'll need to explain / defend why the following, which will likely seem intuitive and natural to at least some JSON developers, is not considered equivalent:

 

"body": {

   "role": "tagging" ,

   "value": "+1" 

 }

And of course regardless we will still need to explain / defend why the following is not considered equivalent:

 

"body": {

   "role": "tagging" ,

   "id": "http://example.org/tagPlus1"

}

 

I think this can be done, but we should think about how best to do so.

 

Lastly, I wanted to confirm one edge case regarding use of SpecificResource, hasSource and dc:format. Is the following okay (assuming a community wanted to define an xPathSelector subclass of oa:Selector, details not defined here)?

 

"body": {

   "role": "commenting" ,

   "format": "text/plain" ,

   "source": {   "id": "http://example.org/tei.xml" ,

                            "format": "text/tei" } , 

  "selector": { ... an xPathSelector ... }

}

 Thanks,

 Tim Cole

 

From: Robert Sanderson [mailto:azaroth42@gmail.com] 
Sent: Monday, August 17, 2015 1:41 PM
To: t-cole3 <t-cole3@illinois.edu>
Cc: Ivan Herman <ivan@w3.org>; W3C Public Annotation List <public-annotation@w3.org>
Subject: Re: My thoughts on the multi-body alternatives (as shown on Tim's wiki page)

 

 

 

Thanks Tim :)

 

 

 

On Mon, Aug 17, 2015 at 10:13 AM, Timothy Cole <t-cole3@illinois.edu <mailto:t-cole3@illinois.edu> > wrote:

Rob-

Focusing on the +0 for role on EmbeddedContent class and +1 for role on oa:SpecificResource class ...

Now that EmbeddedContent is in our namespace (having replaced our prior reliance on the now defunct Representing Content in RDF effort), I'm not seeing that we have meaningful distinctions between these classes that would make one more suitable than the other when it comes to attaching role.  Personally I would be +1 for both of these patterns in JSON:

"body" :  {
        "type" : "Specific",
        "source" : "http://example.org/body1.html <https://urldefense.proofpoint.com/v2/url?u=http-3A__example.org_body1.html&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=zjI0r-H6xRs5fYf2_jJkju6US9ijk0nLw4ns2nuwU2k&m=NxNPP4T6CKQ_O-M5RDmx36w4R2eyrYJFM5J5U4wGWOE&s=TFaCfQ98GoCXcU-wWupYozVCo3eeFifkyNjVyzCztyc&e=> " ,
         "role" : "describing"
  }

"body" :  {
        "type" : "Embedded",
        "value" : "I would be +1 for this." ,
         "role" : "commenting"
  }

 

 

My concern is when the Embedded resource has a URI:

 

"body": {

  "id": "http://repo.org/bodies/1 <https://urldefense.proofpoint.com/v2/url?u=http-3A__repo.org_bodies_1&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=zjI0r-H6xRs5fYf2_jJkju6US9ijk0nLw4ns2nuwU2k&m=NxNPP4T6CKQ_O-M5RDmx36w4R2eyrYJFM5J5U4wGWOE&s=Gzzod42eZA8gwdViOqvB9gLicKZfHEegsqRrfvrwjWo&e=> ",

  "value": "+1",

  "role": "commenting"

}

 

And then someone else decides that id should be used as a tag:

 

"body": {

  "id" : "http://repo.org/bodies/1 <https://urldefense.proofpoint.com/v2/url?u=http-3A__repo.org_bodies_1&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=zjI0r-H6xRs5fYf2_jJkju6US9ijk0nLw4ns2nuwU2k&m=NxNPP4T6CKQ_O-M5RDmx36w4R2eyrYJFM5J5U4wGWOE&s=Gzzod42eZA8gwdViOqvB9gLicKZfHEegsqRrfvrwjWo&e=> ",

  "value": "+1",

  "role": "tagging"

}

 

Now that resource has two roles, tagging and commenting.

 

Rather than consistently using the Specific resource pattern:

 

"body": {

  "role": "tagging",

  "source": {

    "id": "http://repo.org/bodies/1 <https://urldefense.proofpoint.com/v2/url?u=http-3A__repo.org_bodies_1&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=zjI0r-H6xRs5fYf2_jJkju6US9ijk0nLw4ns2nuwU2k&m=NxNPP4T6CKQ_O-M5RDmx36w4R2eyrYJFM5J5U4wGWOE&s=Gzzod42eZA8gwdViOqvB9gLicKZfHEegsqRrfvrwjWo&e=> ",

    "value": "+1"

  }

}

 

Which will always work at the (IMO minimal) cost of slightly more structure.

It's also clearer without the explicit types, as role can only be on SpecificResource.

 

 

My rationale (FWIW): I see as the key characteristic of both classes the ability to create and give identity (as needed) to a resource required to create a specific annotation -- which is to my mind what makes them both suitable objects to which to attach properties specific to the annotation.

 

We don't ever say that you can't embed non-annotation-specific resources within the annotation, using EmbeddedContent.  

 

Note also that Embedded could be used to embed Stylesheets, per example 55 in the model:

    http://www.w3.org/TR/annotation-model/#css-style <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.w3.org_TR_annotation-2Dmodel_-23css-2Dstyle&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=zjI0r-H6xRs5fYf2_jJkju6US9ijk0nLw4ns2nuwU2k&m=NxNPP4T6CKQ_O-M5RDmx36w4R2eyrYJFM5J5U4wGWOE&s=avKklIhxqEif7y-oNgt1z3tIFVLqMj3JRvw-wYhUoqk&e=> 

And that stylesheet could have a URI.  (And wouldn't have a role, I expect)

 

It could also embed the SVG for a selector, as per:

   http://www.w3.org/TR/annotation-model/#svg-selector <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.w3.org_TR_annotation-2Dmodel_-23svg-2Dselector&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=zjI0r-H6xRs5fYf2_jJkju6US9ijk0nLw4ns2nuwU2k&m=NxNPP4T6CKQ_O-M5RDmx36w4R2eyrYJFM5J5U4wGWOE&s=Exyy_QkU7yNSaQ-_TvML7oURu1KqSYFF8ND1Bj6TilQ&e=> . 

And ditto, regarding URI and role.

 

So my concern comes from a different perspective on the use of EmbeddedContent. Yes, it solves the body issue, but it's not just solving that.  It's really a minimal-viable-product drop-in replacement for the defunct Content in RDF work. 

 

 

  The main substantive distinction is that one is limited to resources that can be expressed as strings (rdf:value) and the other is always derived from an existing resource (oa:hasSource). But though we introduce SpecificResource in the context of using only a segment or portion of a resource, SpecificResource can also be effectively used as a kind of proxy for resource in its entirety (as we are discussing in connection with Role). 

 

Right.  I would prefer one pattern rather than two.

 

And similarly though we introduce EmbeddedContent in connection with text/plain bodies, this class can also be used for embedding text/html, text/xml, application/xml,  image/svg+xml, etc. anything that can be expressed as a string -- e.g., use XML to create an SVG meme and it can serve as the body of your annotation.

 

Yup. Or, as above, in other non-body uses.

 

 

Both may appear as blank nodes in an Annotation, but both may also be assigned a URI (though I tend to think this would not be the norm), which does mean, as you point out for EmbeddedContent resources, that we would be allowing role to be assigned to a resource that could be reused. 

 

That is why I'm +0, rather than -1.  I can live with it if needed, but I think there's a better way that separates the two concerns: 

 

EmbeddedContent:  Transfer content of any type for any resource, URI or no, in the serialized annotation.  (Which is why we talked about it in the Serialization section in the CG docs)

SpecificResource:  Make annotation specific assertions about a Body or Target resource. (Until now, that has been selector, state, style and scope ... we're just adding another specifier of role)

 

 

But I think the same is true for SpecificResource, even more so given current language, "If the Specific Resource has an HTTP URI, then the exact segment of the Source resource that it identifies, and only the segment, must be returned when the URI is dereferenced." So if associating a role directly with an EmbeddedContent meme is wrong because it could be created with or subsequently given a de-referenceable URI, than I think the same is true for SpecificResource.

 

We would need to clarify that *all* of the properties of the SpecificResource are to be taken into account when considering re-use.  I don't think that's a fundamental change, just a clarification.

 

 

 

As an aside, if we do decide that SpecificResource and EmbeddedContent are together the right direction to go to resolve the role issue (and my main concern here is that I don't like the idea of implicit typing in JSON-LD -- I think we need to include type explicitly in this situation),

 

+1

 

I think we should consider introducing EmbeddedContent and SpecificResources together in the data model. This would mean first introducing SpecificResource prior to its use in Section 4.1 where we begin talking about Specifiers. I think it would also be a good idea not to make EmbeddedContent so much about Textual Bodies, but rather make clear that it can be used for just about any resource that can be expressed as a string.

 

I would prefer to create a new 4.2 that describes the role use case, but to leave the initial description where it is.  However, the structure might change dramatically with the changes we could make to tags using this approach. 

 

HTH,

 

Rob

 

 

 

-- 

Rob Sanderson

Information Standards Advocate

Digital Library Systems and Services

Stanford, CA 94305