Re: F2F Decision: Sub-classing

Content Negotiation for resolving the correct representation of a resource
is a fundamental aspect of the web architecture, and necessary for
meaningfully interpreting an annotation which has a negotiable resource as
either body or target.

On the other hand, the expectation that a particular consumer of an
annotation will take a particular action after consuming it is not required
information for any other consumer.  And if it was present, any such action
would be dependent on the implementation details of the consuming system.
As such it is not in scope for a general M<-->N interoperability
specification, whereas the standardized content negotiation is necessary
for all clients to correctly interpret and render the annotation.

Rob



On Thu, Nov 1, 2012 at 11:38 AM, 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.
>