- From: Bob Morris <morris.bob@gmail.com>
- Date: Fri, 2 Nov 2012 08:05:15 -0400
- To: Antoine Isaac <aisaac@few.vu.nl>
- Cc: public-openannotation@w3.org
In annotating data, our experience has been that motivation is often---perhaps usually---described in the domain vocabulary. BUT, our conclusion is not that motivation has no place in OA. Rather, it means at most that particular motivation classes rarely, if at all, belong in OA any more than particular Body classes might. Therefore, what we think IS important is that there be a standard way to express where in an annotation the motivation behind the annotaton is found. In other words, we think that motivatedBy belongs in OA. It's just that it only sometimes corresponds to a type of annotation and sometimes does not. For a few kinds of motivations, it is conceivable that some belong in OAX, but this seems less important than being able to pull out motivation from an annotation in a standard way, just as it is easy to pull out a body in a standard way To follow your metaphor, we agree that it is not important for OA to say how to fill the can of worms, but we do think it should be possible to tell that it is a can of worms and not a can of something else. +1 for motivatedBy or something like it. -1 for not labeling a can of worms just because the stuff inside it is worms. Similarly for Expectation as Leyla argues elsewhere, although we think that for annotating mutable resources there are a few commonly needed Expectations. Bob Morris On Fri, Nov 2, 2012 at 5: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 > > > >> 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 >> > > -- Robert A. Morris Emeritus Professor of Computer Science UMASS-Boston 100 Morrissey Blvd Boston, MA 02125-3390 IT Staff Filtered Push Project Harvard University Herbaria Harvard University email: morris.bob@gmail.com web: http://efg.cs.umb.edu/ web: http://etaxonomy.org/mw/FilteredPush http://www.cs.umb.edu/~ram === The content of this communication is made entirely on my own behalf and in no way should be deemed to express official positions of The University of Massachusetts at Boston or Harvard University.
Received on Friday, 2 November 2012 12:05:43 UTC