Re: F2F Decision: Sub-classing

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