Re: [model] Proposal: Allow motivatedBy on SpecificResource

Thanks Paolo,

comments below...

> On 25 Jun 2015, at 13:50 , 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"
>      }
> ]}
> 

O.k. This is as far as I got in one of my mail, which indeed seems perfectly fine to me.

Actually, if the only role of "content" is to refer to the URI of a video, then

"content" : "http://youtube.com/somevideo"

should also be fine, because the @context can be set in such a way that the value is considered to be an RDF resource, ie, a living URI rather than a string. Of course, if the idea is that, in the construction above, other properties would go alongside the '@id' then I believe that cannot be used.


> 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"
>      }
> ]}
> 

I believe that we could/should use inferred properties wherever we can. The RDFS vocabularies can be used to set domain and range, and if an application would really care about resource types, then this could be used.

It is not clear to me at this point whether EmbeddedContent as a type could be inferred, we should check. The snippet above may suggest that if we set the domain of "value" to EmbeddedContent then we might be o.k., but I should check the full vocabulary to see if this is indeed the case.

(Of course, if we used OWL for the vocabulary specification then we could do much more complex type inferences. I am not sure that would be acceptable, though we may want to think about it. The real question is: would application really care about type inferences?)


> 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?

It certainly looks fine to me. But, if @context helps in separating the URI-s from literal, there is an even simpler version:

{"body" : [ {
    "role" : "edit",
     "value":"literalcontent"
 }, {
     "role" : "edit",
    "source" : "http://youtube.com/somevideo"
]}

Ivan

> 
> 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


----
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