- From: Bob Morris <morris.bob@gmail.com>
- Date: Thu, 1 Nov 2012 13:48:08 -0400
- To: Leyla Jael García Castro <leylajael@gmail.com>
- Cc: Jacob Jett <jgjett@gmail.com>, Robert Sanderson <azaroth42@gmail.com>, public-openannotation <public-openannotation@w3.org>
While at it: A second, seemingly different, argument against Expectations given in Rob's email of Oct 1 at 12:48 was > * The expectation that the server will generate an alert based on the > social network of the annotator. This is only desirable for the > initial creation of the annotation, not any subsequent harvesting and > reuse. So this also is only a valid expectation of the initial > transaction between a client and server, rather than a persistent > property of the annotation. To which I observe: I find the argument unconvincing, because OA is hardly wanting for non-persistent properties of an annotation. At least oa:generated seems to be one. Possibly so is much of the stuff related to Serialization. On Thu, Nov 1, 2012 at 1:38 PM, Bob Morris <morris.bob@gmail.com> wrote: > Ah, the debate is back on. :-) > > On Mon, Oct 1, 2012 at 12:48 PM, Robert Sanderson <azaroth42@gmail.com> wrote: >> >>[...] >> - We will not introduce oa:Expectation (the producers expectation of >> what a consumer of the annotation will do), as all of the examples >> were specific to individual network transactions. >> Two examples were discussed: >> * A change request, where the expectation is that the consumer will >> act upon it. This is only a valid expectation for transactions >> between a client and an agent capable of performing the change. As >> such it does not belong in an interoperability specification, but can >> be added in by systems capable of accepting/creating the change. >>[...] > > Whatever one believes about the importance of Expectation for > annotations aimed at resource publishers, I find this \reason/ > inconsistent with the one that says that things about the http > network protocol, such as Content Negotiation, belong in an > interoperability specification. Perhaps someone can explain why > things such as predicates tied to http request headers are not > "valid expectations between a client and an agent capable of > performing" <something>. > > > Bob Morris > > On Thu, Nov 1, 2012 at 11:24 AM, Leyla Jael García Castro > <leylajael@gmail.com> wrote: >> Hi Rob, >> >> I liked your motivation list; it help me to understand how oa:Expectations >> were left out but still expectations "can >> >> be added in by systems capable of accepting/creating the change". >> >> I am not sure whether oax:Editing is enough, what if the user wants to >> specify that the editing should lead to an addition or deletion? I think we >> need some more expectations in this group. And, why are they motivations >> rather than expectations? I would say that the motivation is to produce a >> change but the expectation describes what that change is about (edit, >> delete, add). I think Bob has some use cases for expectations so maybe he >> can give us some examples in order to understand better how they fit as >> motivations. >> >> As for the oax:Reference, indeed it sounds more like some kind of citation. >> About the semantics of linking and citing, if a document cites another one, >> they are in some how linked to each other so citing could be seen as a >> specialization of linking. But still I will check some of the examples in AO >> as Jacob suggests. >> >> Leyla >> >> >> >> On Thu, Nov 1, 2012 at 2:22 PM, Jacob Jett <jgjett@gmail.com> wrote: >>> >>> Hi Rob, >>> >>> I somehow was imagining that oax:Reference would be used for citations. I >>> suppose my question is, are the semantics of linking the same as citing? The >>> latter may be a specialization of the former, i.e., citing is a form of >>> linking. I wonder if it is possible for Bob or Paolo to give us some >>> examples of how Motivation was used in AO. Do we want to delve into >>> sub-typing of motivations? >>> >>> Regards, >>> >>> Jacob >>> >>> >>> On Wed, Oct 31, 2012 at 5:35 PM, Robert Sanderson <azaroth42@gmail.com> >>> wrote: >>>> >>>> >>>> Do we need oa:Motivation to provide a parent class, or should it be a >>>> vanilla motivation such as oa:Annotating which would be assumed if not made >>>> explicit? >>>> >>>> My proposed mapping, with the current class in []s is: >>>> >>>> Informing motivations: >>>> oax:Commenting [oax:Comment] >>>> oax:Classifying [oax:Classification] >>>> oax:Describing [oax:Description] >>>> oax:Linking [oax:Link] >>>> oax:Tagging [oax:Tag] >>>> >>>> Personal motivations: >>>> oax:Bookmarking [oax:Bookmark] >>>> oax:Highlighting [oax:Highlight] >>>> >>>> Inter-personal motivations: >>>> oax:Asking [oax:Question] >>>> oax:Moderating [oax:Moderation] >>>> oax:Replying [oax:Reply] >>>> >>>> Action based motivations: >>>> oax:Editing [oax:Change] >>>> >>>> This leaves the current oax:Reference, which seems to be just a special >>>> sort of Link or Tag. >>>> >>>> Given these or similar Motivations, I don't believe that we need to >>>> instantiate them directly. >>>> >>>> Thus: >>>> >>>> >>>> _:x a oa:Annotation ; >>>> oa:motivatedBy oax:Highlighting ; >>>> oa:hasTarget <resource> . >>>> >>>> Rather than being motivated by _:y a oax:Highlighting. >>>> >>>> Thanks for your input, >>>> >>>> Rob >>>> >>>> >>>> >>>> >>>> On Mon, Oct 1, 2012 at 10:48 AM, Robert Sanderson <azaroth42@gmail.com> >>>> wrote: >>>>> >>>>> The current document says that subclasses of oa:Annotation express the >>>>> "reasons why the annotation was created". It was expressed that this >>>>> is not actually possible, as we are introducing additional semantics >>>>> to the meaning of rdf:type. >>>>> >>>>> The consensus was as follows: >>>>> >>>>> - Every annotation MUST have an explicit class of oa:Annotation, >>>>> regardless of any other classes >>>>> This is in order to make sure that the annotations are recognized as >>>>> oa:Annotations to ensure interoperability. >>>>> >>>>> - SubClasses of oa:Annotation should be introduced primarily to >>>>> further restrict the data model, and may be introduced by any one. >>>>> For example a xxx:Highlight subClass might restrict the model that >>>>> there should be exactly one target and no body. >>>>> >>>>> - Existing subclasses will be mapped to a new type of resource, an >>>>> oa:Motivation, and referenced by a new predicate from the Annotation: >>>>> oa:motivatedBy >>>>> For example, instead of an oax:Hightlight, one would have: >>>>> >>>>> _:x a oa:Annotation ; >>>>> oa:motivatedBy oax:Highlighting ; >>>>> oa:hasBody <body1> ; >>>>> oa:hasTarget <target1> . >>>>> >>>>> (Mapping to be provided) >>>>> >>>>> - We will not introduce oa:Expectation (the producers expectation of >>>>> what a consumer of the annotation will do), as all of the examples >>>>> were specific to individual network transactions. >>>>> Two examples were discussed: >>>>> * A change request, where the expectation is that the consumer will >>>>> act upon it. This is only a valid expectation for transactions >>>>> between a client and an agent capable of performing the change. As >>>>> such it does not belong in an interoperability specification, but can >>>>> be added in by systems capable of accepting/creating the change. >>>>> * The expectation that the server will generate an alert based on the >>>>> social network of the annotator. This is only desirable for the >>>>> initial creation of the annotation, not any subsequent harvesting and >>>>> reuse. So this also is only a valid expectation of the initial >>>>> transaction between a client and server, rather than a persistent >>>>> property of the annotation. >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Rob & Paolo >>>> >>>> >>> >> > > > > -- > Robert A. Morris > > Emeritus Professor of Computer Science > UMASS-Boston > 100 Morrissey Blvd > Boston, MA 02125-3390 > > IT Staff > Filtered Push Project > Harvard University Herbaria > Harvard University > > email: morris.bob@gmail.com > web: http://efg.cs.umb.edu/ > web: http://etaxonomy.org/mw/FilteredPush > http://www.cs.umb.edu/~ram > === > The content of this communication is made entirely on my > own behalf and in no way should be deemed to express > official positions of The University of Massachusetts at Boston or > Harvard University. -- Robert A. Morris Emeritus Professor of Computer Science UMASS-Boston 100 Morrissey Blvd Boston, MA 02125-3390 IT Staff Filtered Push Project Harvard University Herbaria Harvard University email: morris.bob@gmail.com web: http://efg.cs.umb.edu/ web: http://etaxonomy.org/mw/FilteredPush http://www.cs.umb.edu/~ram === The content of this communication is made entirely on my own behalf and in no way should be deemed to express official positions of The University of Massachusetts at Boston or Harvard University.
Received on Thursday, 1 November 2012 17:48:35 UTC