Re: F2F Decision: Sub-classing

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
>