W3C home > Mailing lists > Public > public-openannotation@w3.org > November 2012

Re: F2F Decision: Sub-classing

From: Robert Sanderson <azaroth42@gmail.com>
Date: Fri, 2 Nov 2012 11:11:34 -0600
Message-ID: <CABevsUEx=1qrag7r2fdLX6TGoHDnFwS4ak3LZpJCcyeCHGk-8w@mail.gmail.com>
To: Jacob Jett <jgjett@gmail.com>
Cc: Antoine Isaac <aisaac@few.vu.nl>, public-openannotation <public-openannotation@w3.org>
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.


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

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
Received on Friday, 2 November 2012 17:11:57 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:38:20 UTC