- From: Stian Soiland-Reyes <soiland-reyes@cs.manchester.ac.uk>
- Date: Fri, 16 Aug 2013 16:37:39 +0100
- To: Bob Morris <morris.bob@gmail.com>
- Cc: Antoine Isaac <aisaac@few.vu.nl>, Paolo Ciccarese <paolo.ciccarese@gmail.com>, public-openannotation <public-openannotation@w3.org>
That term might be more memorable than HTTP-Range-14 - although it seems to pick a side using 'fallacy' http://www.jenitennison.com/blog/node/168 On 16 August 2013 15:15, Bob Morris <morris.bob@gmail.com> wrote: > Antoine- > > I take no position on whether Paolo is indeed introducing a confusion > between an annotation and the digital representation of the > annotation. But my experience has been that such confusion is very > common and not just about annotations, but, as you point out, about > any kind of resource. The most typical case I find among natural > scientists is eagerness to assign the same identifier to a physical > object as to a digital description of it. Paolo himself tends to warn > about this in talks about annotation, using the Eiffel Tower as an > example. It's a natural thing for humans to do, because in human > dialogue, the context often makes clear which is under discussion. > But when the context doesn't, confusion ensues. One venue where > confusion is \likely/ is when informaticians are discussing a case in > which both require treatment. > > I think the phenomenon is so pervasive that we need a short, memorable > name for it, especially one I can use to bludgeon my natural science > colleagues who think it's \helpful/ to have a single identifier for a > physical thing and its digital description. > > I propose to call what you remark upon a "doppelgänger fallacy." > > I especially relish the prospect of hopping up in a talk and saying > "Paolo! You, of all people, have introduced a doppelgänger fallacy on > slide 23!" :-) > > Bob Morris > > > On Fri, Aug 16, 2013 at 8:42 AM, Antoine Isaac <aisaac@few.vu.nl> wrote: >> Hi Paolo, >> >> I agree that the decisions on scenario 1-2-3 are entirely up to you. And the >> more fundamental decisions on having one annotation or one annotation and >> something else (another annotation or a PROV entity) also. But as long as >> your short-cuts have a sound grounding! If others can't understand clearly >> what you've done then it's a big problem ;-) >> >> As for the mappings (pav:authoredBy is a sub-property of oa:annotatedBy, >> pav:curatedBy a sub-property of oa:annotatedBy) I agree with you. I used >> "sub-property" but I meant it in a "local" context. I.e for all triples in >> your annotation case, you should generate another triple of the more general >> property. I think what you suggest is ok. >> >> >> As for pav:createdBy, sentence like: >> >> "In pav:createdBy is used for the digital artifact only. While >> pav:authoredBy, pav:curatedBy and so on... are for the content of the >> artifact. So you can have both pav:createdBy (person that created the >> artifact) and pav:curatedBy (person that collected and curated its >> content)." >> and: >> >> "pav:createdBy is more specific than dct:creator as it refers only to the >> digital artifact." >> are really confusing. >> In RDF is one resource that is the object of the statements, and it denotes >> ONE entity. You can't have two properties applied to one resource, and >> sometimes the resource should be interpreted as the annotation, and some >> other times as the digital representation of the annotation. >> >> If you want to use createdBy as a shortcut, and still subject it to the >> oa:Annotation resource, then your definition should rather be : >> "pav:createdBy is used for the creator of digital artifact that represents >> the resource". And then the name should be changed because it doesn't >> reflect the short-cut at all. It should be something like >> pav:hasDigitalRepresentationCreatedBy... >> >> If you want to use createdBy on a resource that is a digital representation >> of the oa:Annotation (so not the oa:Annotation itself) then the wording is >> better. But in this case, well, you can't subject it to the resource you >> wanted to subject it on. And there's no point in minting a property that is >> not dc:creator... (or course dc:creator can be applied to any resource, be >> it a conceptual one of a representation). >> >> Cheers, >> >> Antoine >> >> >>> Hi Antoine, >>> >>> >>> On Fri, Aug 16, 2013 at 7:12 AM, Antoine Isaac <aisaac@few.vu.nl >>> <mailto:aisaac@few.vu.nl>> wrote: >>> >>> Hi, >>> >>> Wow, the return of a serious discussion, in an even more complex form, >>> awesome ;-) >>> >>> First a remark on Stian's comment: >>> >>> "and the conclusion seemed to have been that it is simpler to merge >>> the conceptual annotation with the formalized annotation as a >>> datastructure." >>> >>> Yes, and this was about the data structure only. The annotation is >>> really of conceptual nature. We just allow for attributes (e.g. >>> oa:serializedBy) that shortcut some provenance info. A full, correct >>> representation has the serialization appear as a fully-fledged (PROV) >>> entity, distinct from the oa:Annotation, as pictured at >>> >>> http://www.openannotation.org/__spec/core/appendices.html#__ProvMapping >>> <http://www.openannotation.org/spec/core/appendices.html#ProvMapping> >>> >>> >>> Based on this indeed pav:authoredBy is a sub-property of >>> oa:annotatedBy (or an equivalent, in the specific context). >>> >>> >>> I would say it is more an equivalent as pav:authoredBy is not only for >>> annotations. >>> >>> >>> The question next is how to handle the extra level of "digital >>> annotation" - the guy who captures the annotation in the system (I'll just >>> focus on the "creator" aspect, the discussion is long enough, let's ignore >>> "with" "at" and "on"). >>> >>> I like Jacco's and Stian's suggestions of double annotations (whether >>> one is the target or the body or the other...). It is complex, but it >>> represents the situation quite well. In this case both are annotators. >>> >>> >>> This would complicate the implementation though. In some sense, I see the >>> "extra level of "digital annotation"" more as extra level of provenance so I >>> can stay 'compact'. >>> We had a similar issue with Claims representation. You have the conceptual >>> Claim and then multiple embodiment of that claim in text. It is a tough >>> problem. >>> >>> But sure, you could think of both of them as annotators. Not sure Darwin >>> would like that but I cannot talk for him :) >>> >>> An alternative is to create one annotation (oa:annotatedBy Darwin) and >>> another non-annotation resource. Something similar to the PROV entity we >>> have for the serialization. It would represent the act of capturing a >>> annotation in the system, where the student plays the creator role. >>> >>> In any case, that's two resources. >>> >>> But as for the serialization case, you may want to have only one >>> resource in a 'core' solution. Two options here: >>> >>> 1. Consider that the oa:Annotation is the result of the intellectual >>> work of both Darwin and the student. In this case both are the object of an >>> oa:annotatedBy. I think this choice is borderline, but in a specific >>> application context, where students spend hard work deciphering/interpreting >>> an annotation, why not? >>> If you want to use pav:curatedBy still, then you would need to have it >>> a sub-property of oa:annotatedBy >>> >>> >>> We cannot really do that as pav:curatedBy is also used for objects that >>> are not annotations. >>> What I could think of doing now is: >>> >>> <ann1> >>> oa:annotatedBy <Darwin> >>> oa:annotatedBy <Student> >>> pav:authoredBy <Darwin> >>> pav:curatedBy <Student> >>> >>> It is redundant but that way the semantics is clear for both OA and PAV >>> and it allows OA clients to get to the provenance. >>> What do you think of it? >>> >>> >>> 2. Consider that the role of the student is minor. In this case, I >>> think a property with a name like pav:curatedBy still makes sense. But it >>> would be a specialization of something more general, maybe dc:contributor. >>> And its semantic would in fact be the one of "short-cut" for the more >>> complex situation where a second annotation (or a PROV entity) exist to >>> represent the situation at the right granularity. >>> >>> >>> In PAV most of the properties are short-cuts. The idea is to have a single >>> object rather than a series of them. It does not solve everything, but it >>> works for many use cases. >>> At the moment pav:curatedBy is sub-property of prov:wasAttributedTo and >>> also dct:contributor. So I think we are on the same page. >>> >>> >>> 3. Consider that the role of Darwin is minor (very borderline maybe). >>> In this case the student is the oa:annotatedBy, and Darwin a mere >>> dc:contributor. >>> >>> >>> Frankly I feel uncomfortable with this approach. But it is true, it >>> depends on how you intend the annotation. >>> >>> >>> In any case I don't think you can do anything practical with a >>> solution that would only have one resource of type oa:Annotation and a >>> short-cut property with a name like pav:createdBy. The name and intuitive >>> semantics are really too close to dc:creator and oa:annotatedBy (as the >>> creator of the Annotation)! In fact pav:curatedBy is much better, which is >>> why I think it could be defined as a short-cut in option 2 above. >>> >>> >>> In pav:createdBy is used for the digital artifact only. While >>> pav:authoredBy, pav:curatedBy and so on... are for the content of the >>> artifact. >>> So you can have both pav:createdBy (person that created the artifact) and >>> pav:curatedBy (person that collected and curated its content). >>> >>> >>> Note that PAV mentions dct:createdBy as the super-property of >>> pav:createdBy, which to my knowledge does not exist. In fact I really >>> believe PAV would benefit from removing pav:createdBy. If you need it, >>> re-introduce it with a better name, and clearer semantics! >>> >>> >>> That is just a typo in the description it is dct:creator. pav:createdBy is >>> more specific than dct:creator as it refers only to the digital artifact. >>> >>> Best, >>> Paolo >>> >> > -- Stian Soiland-Reyes, myGrid team School of Computer Science The University of Manchester http://soiland-reyes.com/stian/work/ http://orcid.org/0000-0001-9842-9718
Received on Friday, 16 August 2013 15:38:26 UTC