- From: Robert Sanderson <azaroth42@gmail.com>
- Date: Thu, 25 Jun 2015 07:52:10 -0700
- To: Paolo Ciccarese <paolo.ciccarese@gmail.com>
- Cc: Ivan Herman <ivan@w3.org>, 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: <CABevsUH=kXwSfbjDXM2vDdt0szYSGSW6OFB5S8H4UZoWPBjmyQ@mail.gmail.com>
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 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. 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. 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!
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
Received on Thursday, 25 June 2015 14:52:39 UTC