Re: F2F Decision: Sub-classing

Hi Antoine, Bob, all,

I think I understand Antoine's concerns but still would like to have some
common motivations in oax so it will be even clearer what the intention is.
As for oax:Motivation vs SKOS concepts, is not possible an hybrid approach?
ex:Comment can be a skos:Concept but also a oax:Motivation, cannot it?

In a similar vein, is it not possible at least to introduce the
oax:Expectation and leave the actual expectations to communities but just
making clear what the intention is? How would be the community-specific
stuff integrated to OA? Because even if it is community-specific, we want
to avoid different communities reinventing the wheel, right?

Leyla

On Fri, Nov 2, 2012 at 9: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
>>
>>
>
>