Re: F2F Decision: Sub-classing

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
>>
>
>