Re: [model] Why Motivations cannot be on Bodies

To add my 2 cents, it is a very similar reason to the one that brought us
to model the SemanticTag with an intermediate node:
http://www.w3.org/TR/annotation-model/#semantic-tags
We don't want to qualify the (global) URI of Paris as oa:SemanticTag

Paolo

On Thu, Jun 18, 2015 at 5:07 PM, Robert Sanderson <azaroth42@gmail.com>
wrote:

>
> Hi Doug,
>
> On Thu, Jun 18, 2015 at 10:32 AM, Doug Schepers <schepers@w3.org> wrote:
>
>> In particular, I have difficulty justifying the assertion that the bodies
>> are by necessity global resources, not local to the annotation.
>
>
> Because that's one of the fundamental requirements of RDF and Linked
> Data.  Every triple is asserted with a global scope, regardless of the
> document or system that any client may have discovered it in.  Triple
> stores simply put all of their triples into one big pool, leading to some
> folk to refer to "the big triplestore in the sky" that theoretically (and
> implausibly) contains all triples asserted anywhere.
>
> The body of an annotation is a web resource, not an exclusive property [in
> either sense] of a single annotation. Thus the need for specific resources
> to express things are are only true of the annotation's use of the body
> resource.
>
>
>> Outside the context of the annotation, you lose all other context,
>> including the target and the provenance. So, how is a global body without
>> context a useful statement?
>
>
> A body can be used in many different situations and contexts. Some of
> which might be annotations, some might be elsewhere.  For example, a
> youtube video about something would be a very reasonable body of an
> annotation that formally linked it to the resource that it describes.
> You're saying that the youtube video is not useful without the little bit
> of JSON that links it to something else?
>
>
>> And even granting that it is theoretically useful, if the annotation data
>> model is made rather more complicated by including this concept, is that a
>> compromise worth making in the data model?
>>
>
> Yes, in my opinion. The alternative is to throw out all of the web
> architecture and the notion of linked data for something that can easily be
> solved in several different ways that would be completely compatible with
> existing work, and already exist within the model.
>
>
>> I also didn't understand your claim that you can't make an assertion
>> about a segment of an image, just because other assertions can be made
>> about it.
>>
>
> The segment is only relevant within the context of the annotation, not
> globally.
>
> Three annotations, each of which is about a different part of the same
> image would thus be:
>
> anno1 hasTarget image
> anno2 hasTarget image
> anno3 hasTarget image
> image hasSegment "100,100,640,480"
> image hasSegment "0,0,500,500"
> image hasSegment "100,0,400,200"
>
> Which segment goes with which annotation?  It's impossible to know, and
> that would be the situation without the Specific Resource.
>
> Similarly:
>
> anno1 hasBody video
> anno2 hasBody video
> anno3 hasBody video
> video motivatedBy commenting
> video motivatedBy commenting
> video motivatedBy replacing
>
> Which of the annotations are the two comments, and which is the one where
> it should replace the target?
> Same problem.
>
> Now consider ordering.  Because a resource can be in multiple lists at the
> same time, you need to have some intermediary similar to our specific
> resource.  This necessitated the rdf:List construction, for a simple three
> item list of [item1, item2, item3]:
>
> list first item1
> list rest list2
> list2 first item2
> list2 rest list3
> list3 first item3
> list3 rest nil
>
> Or Proxies in the ORE ontology, ListItems in Collections Ontology, Slots
> in the Ordered List Ontology, and so on.
> In comparison, the multipurpose specific resource construction is cheap
> and understandable :)
>
> Hope that better explains the situation.
>
> Rob
>
> --
> Rob Sanderson
> Information Standards Advocate
> Digital Library Systems and Services
> Stanford, CA 94305
>



-- 
Dr. Paolo Ciccarese
ORCID: http://orcid.org/0000-0002-5156-2703