Re: F2F Decision: Sub-classing

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


> 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 09:58:12 UTC