Re: F2F Decision: Sub-classing

Hi Jacob,

The issue with typing the body is that it's the role of the body within the
particular annotation, rather than something universal.  Motivation, and
previously subclassing, to me is a stand in for:

_:x a CommentingRole ;
  hasResource Body ;
  hasAnnotation Annotation .

It could be thought of as the relationship between Bodies and Targets, that
is in essence being reified by the Annotation. Eg:
(every) Body CommentsOn (every) Target.

But we want to say more about the CommentsOn, and thus it must be a
resource rather than a relationship. (Plus the possibility of no body,
multiple bodies and targets, etc)

Which isn't to say that I want to go back to subclassing the Annotation,
just that we need to be careful with both motivating (ha!) the choice for
oa:Motivation over subclassing, and we need to be explicit as to different
options to ensure some degree of interoperability.

Rob

(A thought:  Open World = OW.  Maybe: Open Universe as Context Hypothesis =
OUCH)



On Fri, Nov 2, 2012 at 9:58 AM, Jacob Jett <jgjett@gmail.com> wrote:

> Hi Rob,
>
> As I recall it says somewhere in our documentation it says that Open
> Annotation is a specification and ontology. Perhaps we should begin
> developing some formal ontological documentation, like an OWL to establish
> the vocabulary the OA community uses to define motivations? I think, if I
> remember how OWLs are used, this will both formalize our vocabulary for
> Motivation and provide other communities methods to integrate their own
> motivational vocabularies.
>
> Going back to sub-classing oa:Annotation. While this method has been used
> in the past it makes me uncomfortable. Ultimately it conflates different
> activities that are distinct and not specializations of one another, e.g.,
> I can comment on something without annotating it. If we had to use
> sub-classing rather than motivation then we should probably be sub-classing
> the body because, I think, what we are trying to communicate is that the
> content of some annotation's body is a comment, tag, etc. Sub-classing this
> way at least preserves that two distinct activities are occuring; the body
> is commenting and the annotation is annotating.
>
> Motivation is an elegant solution because, not only does it allow us to
> provide information about the content (in the Body) that is distinct and
> separate from the annotation as an activity but the annotation becomes the
> method by (or perhaps the medium through) which the activity is
> accomplished. So, for example, commenting is the activity that the content
> of an annotation's body is doing and annotating is the method by which we
> link the comment to the thing being commented on. Does that make any kind
> of sense? I feel like this is a confusing example and may not be helping
> make the case.
>
> Ultimately we also need to provide some common means of distinguishing the
> content of annotations' bodies from one another sufficiently to facilitate
> query building for and/or across annotation stores.
>
> Regards,
>
> Jacob
>
>
>
> On Fri, Nov 2, 2012 at 10:06 AM, Robert Sanderson <azaroth42@gmail.com>wrote:
>
>>
>> Something to keep in mind for this discussion:
>>
>> The aim of the work is to create interoperability between systems and
>> communities.  If a feature is system or community specific, then it
>> probably doesn't belong in OA or OAX.  If a feature doesn't provide any
>> useful or usable information to a majority of systems, then it should be
>> very carefully considered before being included.
>>
>>
>> I believe that Motivations are important for interoperability. A system
>> could treat a Commenting on an annotation and Answering an annotation
>> differently ("this is a great question" versus "here is the answer to your
>> question").  Tagging is important to understand as different from a short
>> Describing or Classifying annotation.  The current list is very broad; so
>> much so that we already have Citing, Referencing, Updating, Deleting, as
>> additional more specific motivations.  To me that says we have the correct
>> location (OAX) and the correct level of definition (communities represented
>> here are engaging with it to provide more specific semantics).
>> As a sanity check, we could go through the list and determine first if
>> all of the current Motivations provide useful information to a consuming
>> system over just 'Annotating' and then if there are further ones that
>> should be added, using the same criteria.
>>
>> I don't mind Leyla's hybrid, or simply make oa:Motivation a subClass of
>> skos:Concept.
>>
>> However I strongly feel that if we don't provide at least a basic list
>> and guidance for how to create further more specific Motivations, then
>> people will simply subclass oa:Annotation, which is exactly what we don't
>> want, as this is the way that practically all previous annotation systems
>> have worked in the past.  Sub-classing is more intuitive and familiar, and
>> we're breaking away from that established pattern.
>>
>> The mapping I provided was informational for the group, the spec would
>> not list the mapping, just the new Motivations.  The mapping could go into
>> a document on the web site, but I'm even not sure that's essential at this
>> stage in the process.
>>
>>
>> Regarding Expectation, I feel that it doesn't pass the first test.  The
>> two examples provided so far are specific to individual systems; the one
>> that controls the content to be updated, and the first system to create the
>> annotation.  It doesn't create interoperability between communities and
>> isn't useful to the majority of consuming systems.  Arguably it creates
>> interop between the client and server, but it seems more appropriate as a
>> bilateral or community specific extension to the base model.
>>
>> Rob
>>
>>
>>
>> On Fri, Nov 2, 2012 at 3:57 AM, Antoine Isaac <aisaac@few.vu.nl> wrote:
>>
>>> Hi Rob, all
>>>
>>> I support the first two points points below.
>>>
>>> But I of course agree with Jacob's reminding that we had discussed that
>>> SKOS could be used as an ontology to describe the resources used with
>>> oa:motivatedBy.
>>> I know I may be biased on this. But I still think it could be a useful
>>> piece of guidance for readers.
>>>
>>> For info here's how a couple of motivations could look like in SKOS
>>> (based on a subset of your list in [1])
>>>
>>> ex:Comment a skos:Concept ;
>>>    skos:prefLabel "Comment"@en ;
>>>    skos:prefLabel "Commentaire"@fr ;
>>>    skos:broader ex:Information .
>>>
>>> ex:Information a skos:Concept ;
>>>    skos:prefLabel "Information"@en ;
>>>    skos:prefLabel "Information"@fr ;
>>>    skos:scopeNote "This motivation denotes informing motivations such as
>>> commenting, classifying, linking or tagging"@en .
>>>
>>>
>>> Note that I've use Edition not Editing. I don't see the point in mapping
>>> anything here. Just deprecate the existing classes, if you're still at the
>>> draft spec stage! Keeping the old classes visible and providing a mapping
>>> will just clutter the landscape considerably. (Worst case, if you want to
>>> keep them, you could just update their typing and not add extra resources)
>>>
>>>
>>> I'm also using a fake ex: prefix and not oax: . I strongly agree that we
>>> should *not* have motivations even in OAX, whether as classes or instances
>>> (of SKOS concept or anything else).
>>> Trying to capture all types out there is a real can of worms. You don't
>>> want to have this standing in the path of more basic stuff. I mean,
>>> knowing/representing motivations is important, it's just that I don't think
>>> trying to fit a reference list in the spec makes sense right now, if ever.
>>>
>>> If you want, you may introduce a top-level motivation, e.g.,
>>> oax:Motivation. Specific communities could use it as an anchor for
>>> attaching their specializations.
>>> But the risk then is that you make the guidance stronger on how to
>>> represent motivations. Giving users a starting point already committed to
>>> some representation approach (e.g., SKOS) sends the message that the same
>>> approach should be used across the board.
>>>
>>> Cheers,
>>>
>>> Antoine
>>>
>>> [1] http://lists.w3.org/Archives/**Public/public-openannotation/**
>>> 2012Oct/0045.html<http://lists.w3.org/Archives/Public/public-openannotation/2012Oct/0045.html>
>>>
>>>
>>>
>>>  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
>>>>
>>>>
>>>
>>>
>>
>