Re: F2F Decision: Sub-classing

Jacob, Leyla,

I guess that's the question ... do we want to explore further refinement of
some of the broader motivations or do we leave that for either future work
or different communities?

* Is there a general, cross-community utility to the more specific
motivations?
* Are we the right people to decide on them?

Regarding expectation vs motivation, the decision at the face to face
meeting was that all of the examples of Expectations were properties of a
particular network transaction and not the annotation itself.

For example, the expectation that an annotation will result in a change to
a resource (hence the motivation behind it is editing or correcting or
improving the target resource) is only able to be put into effect by the
system that controls the resource to be changed.  All other N-1 systems
that see the annotation will not be able to fulfill that expectation, but
may find it useful to know the motivation behind the creation of the
annotation.  Similarly, the expectation that an Annotation will generate an
announcement should only be actioned by the first system in which it is
created, not every system to consume the annotation, otherwise it would
produce a huge amount of noisy repeated announcements.

Rob



On Thu, Nov 1, 2012 at 9: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
>>>>
>>>
>>>
>>
>