- From: Ivan Herman <ivan@w3.org>
- Date: Fri, 26 Jun 2015 11:14:14 +0200
- To: Robert Sanderson <azaroth42@gmail.com>
- Cc: Paolo Ciccarese <paolo.ciccarese@gmail.com>, Doug Schepers <schepers@w3.org>, Chris Birk <cmbirk@gmail.com>, Jacob Jett <jjett2@illinois.edu>, W3C Public Annotation List <public-annotation@w3.org>
- Message-Id: <A54309FC-FFA5-4E05-AB65-5B05A93D768F@w3.org>
> On 25 Jun 2015, at 16:52 , Robert Sanderson <azaroth42@gmail.com> wrote:
>
>
> I'll try to spell out my objections more clearly. Apologies for being fuzzy!
>
> Ignoring whether role and motivation are the same or not ...
>
> * If we allow role on EmbeddedContent, it ties the EmbeddedContent resource explicitly to the Annotation. That's a restriction that we have not had in the past, and I question the cost/value of doing so, as it is only needed in the multiple body scenario, which is the 1% case not the 99%. On the other hand that is the intent of the SpecificResource... A more specific, constrained version of the body or target resource, based on annotation specific requirements.
>
> * If a server mints a URI for the EmbeddedContent resource, which would be the best practice according to Linked Data [avoid blank nodes if possible, use HTTP URIs to name things], it would very much like the Resource Body pattern and we would be inconsistent after the initial client POST to the server.
>
If, in the multiple body scenario, the server mints two different URI-s for the resources referring to the same roles, then I do not see the problem, at least in the patterns outlined by Paolo in his previous mails.
Also… I do not want to start a religious war, but we should not be so religious (sic!) about the blank node issue. If the choice is that the server mints an otherwise cryptic URI or leaves it as a blank node, the choice of a blank node may be preferable. The question really is whether those resources (the EmbeddedContent ones) would ever be 'linked', by virtue of an identical URI, to another node in the RDF graph. If the answer is that this is unlikely, then I would bypass the LD best practice notice.
Note, however, that we should not require either way, except to say that if URI-s are minted by the client or the server, they should be kept distinct.
> * If a further annotator selects part of the text of an EmbeddedContent resource (eg to suggest an edit), then the body of one annotation is now the target of another. But would still carry the role from when it was the body, in a different annotation where that role is completely wrong. By trying to make it easier, we've prevented what I think should be a valid use case, because the embedded resource is tied exclusively to the annotation in which it is the body.
>
> * There would be at least *five* different ways to express the basic requirement of a role for a simple, embedded text body:
> 1. Annotation with a motivation and ...
> 1a. body as literal
> 1b. body as EmbeddedContent
> 2. Body as EmbeddedContent with role/motivation
> 3. Body as SpecificResource with ...
> 3a. source as EmbeddedContent with a role/motivation
> 3b. role on the SpecificResource, and source as EmbeddedContent without a role/motivation
>
> I seriously question whether this is *less* complex than having a single, clear requirement that everyone implements.
… which, I presume, is to remove the multiple body approach, right? Not taking sides here, jut trying to understand what you say.
> In the proposed solution, every client implementer will need to check all of those scenarios for every annotation. I strongly disagree that requiring such checks would be easier than always looking in the same place in a consistent structure.
That is indeed a compelling argument. Although (much as I do not like this, actually!) I have seen this pattern very often with JSON encoded data: the value of a property can be an array, an object, a string, and the client has to check that all the time:-( But that does not make it more attractive…
> So exactly who are we helping with this? Not the client developer, and not the server developer. Not the user, as they never see this level anyway.
>
> * The distinction between Tags and SemanticTags becomes even weirder. If we introduce some method for per-body roles we could do away with the unloved Tag/SemanticTag classes... but only if the role is associated with the SpecificResource, for the same reasons we removed the recommendation to add the SemanticTag class to arbitrary URIs [global assertions, and all that]. Again, consistency has a value of its own, far beyond theoretical purity.
>
> Hope that's clearer!
Yes. Which also means that this discussion should come to rest only when you are back from vacations from NZ:-) Have a nice time there!
Ivan
>
> Rob
>
>
>
> On Thu, Jun 25, 2015 at 4:50 AM, Paolo Ciccarese <paolo.ciccarese@gmail.com> wrote:
> Ivan,
> In my case the body was not twice into the equation, those were two different bodies belonging to two different Annotations:
>
> Annotation #1 (snippet): Literal body
> [NOT COMPLIANT WITH CURRENT VERSION OF THE MODEL]
> {"body" : [ {
> "role" : "edit",
> "content" : "literalcontent"
> }]}
>
>
> Annotation #2 (snippet): Resource body
> [NOT COMPLIANT WITH CURRENT VERSION OF THE MODEL]
> ..
> {"body" : [ {
> "role" : "edit",
> "content" : {
> "@id": "http://youtube.com/somevideo"
> }
> }]}
> ...
>
> Of course we can have an Annotation with both kinds of bodies:
> [NOT COMPLIANT WITH CURRENT VERSION OF THE MODEL]
> {"body" : [ {
> "role" : "edit",
> "content" : "literalcontent"
> }, {
> "role" : "edit",
> "content" : {
> "@id": "http://youtube.com/somevideo"
> }
> ]}
>
> Rob is referring to a specific construct already explained in the specs the oa:SpecificResource which we normally associate to targets but it is more general and can be applied to bodies.
> That construct allow to refer to a 'resource' through the oa:hasSource. And he referred also to oa:EmbeddedContent
> So my last snippet above would become, for example:
>
> {"body" : [ {
> "@type": "oa:EmbeddedContent",
> "role" : "edit",
> "value":"literalcontent"
> }, {
> "@type": "oa:SpecificResource",
> "role" : "edit",
> "source" : {
> "@id": "http://youtube.com/somevideo"
> }
> ]}
>
> Now, according to specs, the class oa:SpecificResource SHOULD be assigned, which means we could omit it as well to keep it simple.
> However oa:EmbeddedContent MUST be assigned so the above would become:
>
> {"body" : [ {
> "@type": "oa:EmbeddedContent",
> "role" : "edit",
> "value":"literalcontent"
> }, {
> "role" : "edit",
> "source" : {
> "@id": "http://youtube.com/somevideo"
> }
> ]}
>
> Question is, could we change the oa:EmbeddedContent to be 'inferred' so that we could write:
> {"body" : [ {
> "role" : "edit",
> "value":"literalcontent"
> }, {
> "role" : "edit",
> "source" : {
> "@id": "http://youtube.com/somevideo"
> }
> ]}
>
> Which is the closest we could get to what Doug was asking initially.
> Unfortunately that is not the pure JSON way as Chris was asking.
> But seems a decent compromise?
>
> Paolo
>
>
> On Thu, Jun 25, 2015 at 6:06 AM, Ivan Herman <ivan@w3.org> wrote:
> Well… I still find all this confusing, because we sort of agree, then we seem not to agree (and I am not sure why), then agree again…
>
> Rob, can you write down how you think we can have multiple bodies in an annotation with roles/motivations? Because, frankly, I am lost. (And yes, I did read the specifier section. But that is related in higher level concepts level, which I think I understand, and not addressing specifically the issue of multiple bodies…)
>
> Thanks
>
> Ivan
>
>
> > On 25 Jun 2015, at 02:26 , Robert Sanderson <azaroth42@gmail.com> wrote:
> >
> >
> > Call me devious or lazy, but if you read through:
> > http://www.w3.org/TR/annotation-model/#specifiers
> >
> > And at the end don't understand what the role of SpecificResource is, then we need to create some issues to fix the data model description :)
> >
> > Rob
> >
> >
> > On Wed, Jun 24, 2015 at 5:16 PM, Doug Schepers <schepers@w3.org> wrote:
> > Hey, Rob–
> >
> > Hmm... somehow, this is starting to get really hairy… Are you saying that to have a motivation/role on a body, it would have to have this additional type:SpecificResource key/value? Why is that?
> >
> > Can you explain to me what role 'SpecificResource' plays, and what the name means. It's not intuitive to me.
> >
> > (That nested body thing worries me.)
> >
> > Thanks–
> > –Doug
> >
> >
> > On 6/24/15 4:09 PM, Robert Sanderson wrote:
> >
> > I'm fine with that ... and to expand it slightly, it fits exactly into
> > the pattern of Fig 29+
> >
> > {
> > "@id": "http://example.org/anno1",
> > "@type": "oa:Annotation",
> > "body": {
> > "@type": "oa:SpecificResource",
> > "role": "commenting",
> > "source": {
> > "@id": "http://example.org/body1",
> > "@type": "dctypes:Sound"
> > },
> > "target" : "http://example.org/target1"
> > }
> >
> > The concern is about literals / embedded text, and following the same
> > pattern for consistency.
> >
> > {
> > "@id": "http://example.org/anno1",
> > "@type": "oa:Annotation",
> > "body": {
> > "@type": "oa:SpecificResource",
> > "role": "commenting",
> > "source": {
> > "@id": "http://example.org/body1",
> > "@type": "oa:EmbeddedContent",
> > "value": "I love this thing"
> > },
> > "target" : "http://example.org/target1"
> > }
> >
> >
> > Otherwise, if the role is NOT on the specific resource, and a specific
> > resource is needed, we would have an unnecessary node sitting between
> > the annotation and the specific resource just to hold the role.
> >
> > Also, for the literal case, currently the literal body is the object of
> > oa:hasBody ... meaning ....
> >
> > {
> > "@id": "http://example.org/anno1",
> > "@type": "oa:Annotation",
> > "body": {
> > "@type": "oa:SpecificResource",
> > "role": "commenting",
> > "body": "I love this thing"
> > }
> > }
> >
> > That seems extremely hacky and introduces ridiculous recursion
> > possibilities. Even bodyValue : literal would be better -- at least
> > that could easily be translated into body {value: literal} more cleanly.
> >
> > Rob
> >
> >
> > On Wed, Jun 24, 2015 at 12:52 PM, Paolo Ciccarese
> > <paolo.ciccarese@gmail.com <mailto:paolo.ciccarese@gmail.com>> wrote:
> >
> > In other words, this (figure 3 of the specs):
> >
> > "body": {
> > "@id":"http://example.org/body1",
> > "@type":"dctypes:Sound"
> > }
> >
> > Would become
> >
> > body" : [
> > {
> > "role" : "soundtrack",
> > "content" : {
> > "@id":"http://example.org/body1",
> > "@type":"dctypes:Sound"
> > }
> > }
> > …
> >
> >
> >
> >
> >
> > --
> > Rob Sanderson
> > Information Standards Advocate
> > Digital Library Systems and Services
> > Stanford, CA 94305
>
>
> ----
> Ivan Herman, W3C
> Digital Publishing Activity Lead
> Home: http://www.w3.org/People/Ivan/
> mobile: +31-641044153
> ORCID ID: http://orcid.org/0000-0003-0782-2704
>
>
>
>
>
>
>
> --
> Dr. Paolo Ciccarese
> Principal Knowledge and Software Engineer at PerkinElmer Innovation Lab
> Assistant Professor in Neurology at Harvard Medical School
> Assistant in Neuroscience at Mass General Hospital
> ORCID: http://orcid.org/0000-0002-5156-2703
>
>
>
> --
> Rob Sanderson
> Information Standards Advocate
> Digital Library Systems and Services
> Stanford, CA 94305
----
Ivan Herman, W3C
Digital Publishing Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
ORCID ID: http://orcid.org/0000-0003-0782-2704
Received on Friday, 26 June 2015 09:14:26 UTC