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

Hi, Ivan–

On 8/19/15 1:14 AM, Ivan Herman wrote:
> Doug,
>
> need some clarification/comment…
>
>> On 19 Aug 2015, at 01:26 , Doug Schepers wrote:
...
>> 3) We make the nested "source" object a SHOULD, while the
>> empty-node construct is only a MAY, and only allowed for
>> text-literal resources, and (maybe?) only in a non-Linked Data
>> context; we define a clear equivalence mapping.
>>
>> For example, these statements would be equivalent:
>>
>> "body" : { "role" : "tagging", "source" : { "value" : "+1" } }
>>
>> "body" : { "role" : "tagging", "value" : "+1" }
>>
>> But these would not:
>>
>> "body" : { "role" : "linking", "source" : { "type": "Image", "id":
>> "http://example.com/image.png" } }
>>
>> "body" : { "role" : "linking", "type": "Image", "id":
>> "http://example.com/image.png" }
>>
>
> When you say 'would not', you mean these two are not equivalent, I
> guess.

Right.


> I was actually wondering whether we may want to go one step further.
> Namely that the object associated with "body" MUST have a "source"
> (or maybe an alternative "value" for textual content), and that is
> what identifies the 'real' annotation body. In other words, the
> second construction would become a bug. If so, the value of "source"
> may be a simple URI, too, ie, these two would be equivalent:
>
> "body" : { "role"   : "linking", "source" :
> "http://example.com/image.png" }
>
> "body" : { "role"  : "linking", "source" : { "id" :
> "http://example.com/image.png" } }

I think I'd be happy with this, if we can get away with it, but I 
expected that Rob would not be, so I didn't propose it.

I think that much, perhaps most, of the content in mainstream 
annotations will be text, with images being the second most common 
format (for example, Microsoft's Edge annotations are currently an SVG 
image, I think… but they will probably convert handwriting to text, and 
store/send that as well as the original handwriting).

I think other types of body content will be much less used, so I was 
optimizing and simplifying for the most common case, text.


> I guess what I am heading at is that (also in the model) the object
> assigned to body may either be a pure simple literal to handle the
> simple cases, or, essentially, a Specific Resource.
>
> As you said, the body itself may or may not have its own ID, but that
> ID is disjoint of the ID of, say, the image in this case.
>
> That also mean that the idiom we use in the current model:
>
> "body" : { "id" :  "http://example.com/image.png" }
>
> becomes moot and the correct way is
>
> "body" : { "source" :  "http://example.com/image.png" }
>
> and this makes the corresponding RDF a little bit more complex. But I
> would prefer to push the complexity on the RDF side (which can easily
> cope with this) if it makes it simpler to the non-RDF user
> community.

Well, if you think so. Rob seems to differ on this point. If he agrees, 
then that would probably satisfy me, though I think I'm missing some of 
the subtleties.


> (As an aside: if we go down that line, and reflecting on one of Rob's
> remarks in another mail, maybe we indeed want to come back to our
> decision and use "@id" instead of "id". It would emphasize its very
> particular role and usage.)

I'd prefer we didn't; I'm not sure that would help draw the right kind 
of attention to it.

What remark of Rob's made you think of this?

Regards–
–Doug

Received on Wednesday, 19 August 2015 05:40:56 UTC