Re: [model] Proposal: Allow motivatedBy on SpecificResource

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