Talk:Sub-classing

Problem: Sub-classing presents two problems.

(1) Without both a strong set of Core sub-classes and well developed best practices, there is a strong risk of proliferation of annotation sub-types being created to fulfill domain specific use cases.

--Robert Morris 19:07, 4 September 2012 (UTC) says: Agreed. Probably even with a strong set. Also, there is a risk that the type hierarchy will be contentious, even if small.

--Jacob Jett 16:35, 5 September 2012 (UTC)A naive question, is proliferation such a bad thing? Won't it be impossible to plan for every contingency right now anyway?

(2) There seems to be some conflation between the intension(1) of an annotation and intention(2) of the agent creating the annotation.

--Hennie Brugman 09:04, 5 September 2012 (UTC)when an agent publishes an annotation with a subtype, this subtype communicates that the annotation is supposed to be considered/treated in a more specific way than a generic annotation. From the examples in the extension spec and the incubator, what is communicated is, amongst others: - motivation of the producer - response expected by the producer, from the consumer - constraints on body (presence, data type), target, selector, vocabulary to use, ... - superimposed semantics: transcription, translation, subject, actor, etc

This is all communicated only by means of class names, so subject to (mis)interpretation by the consumer, and likely to proliferate and be debated.

Potential Solutions

(1) An additional annotation property 'Motivation' could be introduced. Details on what this could look like can be seen in earlier drafts of the OA Core specification. This would not replace the annotation class but rather supplement it by providing a node to record and communicate annotator purpose.

--Robert Morris 19:07, 4 September 2012 (UTC) says: (1) is what we proposed for AO, and for the same reason given here. Motivation seems to be more about the annotator than the annotation.

(1a) Related to this, an expectation property could also be introduced. Details on what this could look like can also be seen in earlier drafts of the OA Core specification; however, this property does seem to overlap very heavily with Annotation typing.

• it was suggested at one point that some of specific data-typing functions of expectation could be carried out via hasStyle, with specific styles for machines, IIRC, this is probably no longer the case as XSL is not something that can be communicated via oa:hasStyle (JGJ)

--Robert Morris 19:07, 4 September 2012 (UTC) says: The way we use Expectation, I am not sure about overlap with typing. To us, an Expectation is kind of a contract between a producer and a consumer, and doesn't make much sense without one of each. If anything, it types the consumer in that (a) a producer may have different expectations depending on the consumer's control over the resource annotated. For example, Suppose an annotation is signifying that a published resource is incomplete and that the oa:Body conveys an assertion about what the completion should be. In our use case the annotator probably expects that the publisher will complete the resource. For some consumer without the authorization to do that, the Expectation may well be merely that such a consumer will behave as though the resource was amended. (This is a tall order in practice, and, we argue probably needs good distributed notification mechanisms so that if in this example the publisher responds that they are not going to meet the Expectation, then other interested parties can take action based on that refusal (provided it can be discovered).

--Jacob Jett 16:33, 5 September 2012 (UTC)Upon further reflection, am I correct in interpreting this use case as an example of adding some form of social contract to the data model? Isn't that outside the scope of data specifications?

--Jacob Jett 19:58, 4 September 2012 (UTC)So if I understand this correctly, Expectation is also completely unrelated to annotation type/sub-type. This differs substantially from what was suggested in early drafts of its use in the merged data model. Question, if expectation is a contract between producer and consumer (more like a disclaimer to the data consumer) wouldn't some kind of oax:hasAudience or oax:hasUseScope property communicate the information more clearly? Expectation seems pretty vague.

--Robert Morris 15:30, 6 September 2012 (UTC) In the FilteredPush project we have use cases where the Expectation could apply to many types of annotation. That said, we also tend to see Motivation as saying something about the annotator's relationship to the annotation more than the the relation of the target to the body. Consequentially we don't think we need to sub class Annotation at all. We come to all these ideas for this reason: our annotations are about mutable data and fragments thereof, particularly in a context of data quality control. We need to be able to express in an annotation that something about the Target deserves change, or at least skepticism, and that assertions to that effect are evidence-based. Because our domain is science data, specifically natural history specimen metadata, no assertions about data quality or fitness for use are part of a science domain unless evidence based. In our proposals for data extensions to Paolo's et al. AO, we subclassed Expectation to four types that most data store models support: Insert, Delete, Update, and Group. We also add a type to convey that the annotator is documenting some kind of problem with the Target resource, but doesn't express an opinion about what should be done.

--Robert Morris 15:30, 6 September 2012 (UTC) For documents, I think the closest use case analogy is the typical marginal annotation + change management as commonly implemented in modern word processors. I think a document thus edited likely could easily be expressed as an OA Annotation(s) on the first draft. Or, if you published any papers before, say 1980 or so, think "Galley Proofs."

--Jacob Jett 21:25, 7 September 2012 (UTC)I think I understand what Expectation is to be used for now. I wonder though, if both motivation and expectation are not more properly modeled as properties of the annotator rather than the annotation? I agree that we need to add both motivation and expectation to the extensions document as there are ample use cases that leverage it. The larger question is do we deprecate the use of annotation sub-classing? Both motivation and expectation and Hennie's suggestion of linking annotation types to an external vocabulary such as SKOS seem to be reasonable alternatives but are these alternatives sufficient to allow us to safely deprecate use of sub-classes? Please consider the following example from Tim Cole.

Given Resource B:

 Assume there is a Resouce A which agrees with the assertion of Resource B

Let me say that Resource A annotates Resource B, then

  Anno1 a oa:Annotation
     oa:hasBody Resource_A
     oa:hasTarget Resource_B

How do I further express that Resource A agrees with Resource B?

  Anno1 a oa:Annotation
     oa:hasBody Resource_A
     oa:hasTarget Resource_B.

  Resource_A a Resource
     cito:agrees_with Resource_B

where cito:agrees_with is defined as "The citing entity agrees with statements, ideas or conclusions presented in the cited entity"

OR

  Anno1 a oa:Annotation
     rdf:type ann:agreesWith
     oa:hasBody Resource_A
     oa:hasTarget Resource_B.

where ann:agreesWith is defined as "A class of annotations wherein the body expresses support for the target(s)." keeping in mind that the body maybe as simple as the URI for +1

Both have been used by others. Is one clearly wrong? Since when? On what authority?

--Hennie Brugman 11:29, 10 September 2012 (UTC) Expectation and motivation as properties of Annotator: an Annotator can have different Expections or Motivations for different Annotations. So I guess it is better to make them properties of Annotation.

Sub classing or not: Your first example expresses agreement completely outside of Open Annotation. The second example also does, unless you specify somewhere that ann:agreesWith is a subclass of oa:Annotation (and then it is consistent with the current specification). The examples both are not 'wrong', people who choose to use one or the other are free to do so. But the specification is free to put restrictions on how to use subclasses --of oa:Annotation-- , or give recommendations about it, or give a default interpretation of 'subclass-of'. My alternative representation of your second example would be

  Anno1 a oa:Annotation
     oa:hasBody Resource_A
     oa:hasTarget Resource_B
     oax:motivation Agreement

 Agreement a skos:Concept
     skos:inScheme Motivations

 Motivations a skos:ConceptScheme

In short, I do not see a new argument against deprecation of subclassing of oa:Annotation

--Jacob Jett 20:42, 10 September 2012 (UTC)I'm not certain I understand why an annotator having different motivations and expectations for different annotations would be sufficient for us to prefer to model motivations and expectations as properties of the annotation, but this might be a philosophical issue for me. I find the thought that an annotation might have a motivation or expectation as odd as a rock having a motivation or expectation. It feels like we are imbuing something inanimate with properties that only animate things can possess.

Regarding sub-classing, I like your alternative example, but many are already using sub-classes, so rather than failing at producing a new argument against deprecation of sub-classing, we have still failed to produce a argument sufficient to recommend deprecation of sub-classing. What I'd like to focus on is whether or not we can have sub-classes that refer to anything beyond motivation or expectation. I'll refer us back to the extensions document: http://www.openannotation.org/spec/extension/#Classes

If our understanding of what is allowed in the the extensions document and the RDF standard is such that we can intellectually produce sub-classes of oa:annotation that do not communicate motivations or expectations then we cannot safely deprecate sub-classing as others will have valid use cases that require it. If our understanding is the converse, then we should not allow any sub-classing of oa:annotation.

From the first sentence of 2.1: "In many cases it is important to understand the reasons why the Annotation was created." Can we have reasons beyond motivation and expectation?

IMO, we can say yes if we are providing a taxonomic model of the annotation's essential nature as a phenomenon, e.g., Anno1 a oax:Comment, Anno1 a oax:Highlight. In this case the sub-classes are observational and may be safely modeled with separate motivation and expectation. So we could have the example of:

  Anno1 a oa:Annotation
     a oax:Comment
     oa:hasBody Resource_A
     oa:hasTarget Resource_B
     oax:motivation Agreement

 Agreement a skos:Concept
     skos:inScheme Motivations

 Motivations a skos:ConceptScheme

Of course it isn't readily apparent what the presence of the triple "Anno1 a oax:Comment" buys us, but in a repository containing mixed types of annotations it allows for simple browsing and retrieval queries to be built that leverage its inherent taxonomic information. Does that make any sort of sense?

--Hennie Brugman 18:33, 11 September 2012 (UTC) About expectations and motivations: I did not mean anything philosophical at all, my observation was just about a data modelling issue. Suppose we had a provision for Annotator in OA (which we don't), then we would have to associate 'motivation-for-anno1, motivation-for-anno2, ...motivation-for-annox' with it. Your philosophical problem may disappear if we rename the properties to something like 'reasonForCreation' and 'expectedResponse'.

About sub classes: 1. I also use(d) sub classes purely to be able to retrieve subsets of Annotations. In fact, the current w3c spec "deprecated" my original use of subclasses by stating that they can only be used to express the 'motivation for creation'. 2. if OA wants to provide a way to express 'reason for creation' then I think it is better to do that in an explicit way than to re-define rdf:type 3. I feel uncomfortable with "taxonomic models of the annotation's essential nature as a phenomenon". That is not something I would like to see in a standard. Why does 'highlight' or 'question' meet this criterion and why does an expression of 'agreement' not? 4. if we have no good default usage of sub classes of oa:Annotation, maybe we should leave statements about it out of the spec and leave it with what RDF(S) states about it?

--Robert Morris 23:33, 7 September 2012 (UTC) Ah, funny you should offer this use case. It's a central use case for us in FilteredPush, where our primary interest at the moment is using annotations for data quality control. We are approaching this kind of thing with the marl Linked Opinion ontology and the DDIS Software Evolution Ontology ("bom") Here the conversation---for which Expectation is critical---has this intent:

"Your annotation (referenced here only by URI as theOther:Annotation) said that the taxonomic name is wrong in my data and that you expected me to fix it. But the name you offered is an older taxonomic name than is in my data, and so I decline to take any action. I expect that you will insert "won't fix" as the resolution of the issue that theOther:Annotation represents."

I think Tim's case fits this rubric, but maybe there's something more complicated it what he asks. We're open to other more generic vocabularies for issue modeling than one based on software evolution tracking, but it seems to do the trick for us. Next week maybe I can try to model Tim's case like the example below. "aod" is the stuff we proposed to Paolo as extensions to AO. I think the rest is properly coded in OA, though omitting some stuff. See the paragraph below the code. The idea to use a software issue system model and marl comes from Paul Morris.

this:Annotation a oa:Annotation;
        aod:hasEvidence this:Evidence;
	aod:hasExpectation this:Expectation;
	aod:hasMotivation this:Motivation;
	oa:annotated "2012-08-15T02:35:30EDT";
	oa:annotator this:Annotator;
	oa:hasBody this:Body;
	oa:hasTarget theOther:Annotation.

this:Annotator a foaf:Agent;
	foaf:mbox "bdim@oeb.harvard.edu";
	foaf:mbox_sha1sum "e8403a095a60b5b0e5d56c91f5586d76943def38";
	foaf:name "Paul J. Morris";
	foaf:phone "617-495-2823".

this:Body marl:describesObject theOther:Annotation;
	marl:hasPolarity this:Polarity;
	marl:opinionText "Older name";
	a marl:Opinion.

theOther:Annotation bom:hasResolution this:Resolution;
	a bom:Issue.

this:Expectation a aod:Expectation_Insert.
this:Motivation a aod:Motivation;
this:Polarity a marl:Negative.
this:Resolution a bom:WontFix.

--Robert Morris 23:33, 7 September 2012 (UTC) The above is incomplete in a few ways: (a)this:Motivation is empty and (b)it lacks this:Evidence, which probably in this case, essentially has to be the marl:opinionText objectized in some non-circular way. But either we convinced Paolo, or the other way around, that in science, presenting Evidence is the only kind of Motivation one ever has and in that model we made aod:Evidence be a subclass of aod:Motivation. I'm not so sure that point of view would support, say, annotations as religious discourse. For that, it might be that Faith as a subclass of Motivation is necessary. I'm moderately serious about this, since historically religious documents have often been cast as annotations of a predecessor corpus, and I hope there's not some group of theologians out there trying to do the same thing OA is.

--Jacob Jett 19:50, 10 September 2012 (UTC)So, I'm sold on supporting both Motivation and Expectation in the extensions document. What I don't feel like we've addressed is why we wouldn't need or want to use sub-classes. Unless the scope of annotations that we have in our system is very narrow then it seems like we would want an easy means to retrieve groups of annotations as sets. Nominally we could do some of this through queries that detect the presence or absence of certain features of the annotation graph, e.g. if the annotation has a CSSStyle node then it contains some highlight information, if it has a SemanticTag then we know it has one or more tags, but how can we retrieve a set of annotations that are, for example, just highlights or just tags, won't the queries be unnecessarily complex for what should ideally be simple retrievals?

--Hennie Brugman 09:04, 5 September 2012 (UTC)(2) Do not use or promote the use of subclasses at all. If desired, provide alternative ways to communicate additional information about an annotation to consumers by defining properties in the extensions spec (like oax:motivation, oax:intendedAudience, oax:hasUseScope, ...). We could consider developing and publishing a (SKOS?) vocabulary to be used with these properties. Class names like Bookmark, Comment, Link, Tag, etc could be defined as skos:Concepts in this vocabulary, along with their mutual relations, scopeNotes, etc.

--Jacob Jett 16:33, 5 September 2012 (UTC)Hennie, could you provide an example of how this would work? It seems like this might be a relatively heavy weight solution. I think that I would argue, under the normal circumstances that we want to use sub-classes as we never really care about the mechanics of how the consumer consumes the annotation. If the consumer sees that the annotation is ex:aAnno rdf:type oax:highlight then they need to be responsible for interpreting and reusing the data contained within the annotation and so we don't need to communicate to them an expectation that they interpret the annotation in any particular way (specifying how to interpret an annotation would be impossible to enforce anyway). It seems to me though that we sometimes may want to decouple an annotator's intent from type of annotation and so an optional oax:Motivation property should be provided for in the extensions document.

--Hennie Brugman 09:16, 6 September 2012 (UTC) Jacob, I meant to propose a more light weight solution than is currently in the spec. At most, one or more properties like oax:Motivation should be part of the extensions document. I propose not to use or promote subclassing of oa:Annotation at all, maybe even discourage it. And I would like to get rid of vocabulary items like Bookmark, Highlight, Tag, etc from the spec and even the extensions document. If the community nevertheless thinks it is important to have some 'standard' vocabulary for motivations, then I propose to provide that in the form of an --external-- SKOS vocabulary. Example: ex:aAnno oax:motivation motivations:highlight, where 'motivations:highlight' is the URI of a skos:Concept.

--Robert Morris and Paul Morris say at approximately UTC 17:13 Sep 13 2012: we would deprecate subclassing based on several of our experiences annotating data fragments:

1. Some classifications of an Annotation are more about the Target than the Body, some the other way, and some about the Annotation. In our use cases the latter rarely were really about the Annotation itself other than in a formal sense by virtue of subtyping the Annotation.
   1. For example, when originally working with AO, we introduced DataAnnotation as a subclass of ao:Annotation (which here was actually typing the Target), and then found out that we never needed to do anything based on that subtype. (As an aside, that lack of need sometimes arises from our antipathy toward premature assignment of rdfs:domain to predicates, which tend to have implications that surprise inexperienced users of applications using reasoners. But this is all a different issue.)
   2. Some of the proposed oax subclasses of oa:Annotation already show some of the trichotomy. As is observed in the spec, oax:Bookmark and oax:Highlight don't need a Body, and probably typically don't have one. This would seem to argue that they are fundamentally about the Target. On the other hand oax:Question would seem to be a characterization of the nature of the Body. But maybe not. Maybe we mean that the resource is posing a question, rather than that the annotator is posing a question in the Body. (This is an example of where an Expectation could save the day in that maybe the annotator could signify that a consumer should answer the question posed in the Body.)
2. We found that subclassing annotations quickly descended into concerns of the domain terminology in a way that prevented reuse. Our users are curators of natural history collections. Their community of practice already has a notion of annotation, though for several hundred years it meant handwriting on specimen jars or big sheets of paper to which dried plants are glued. In their minds, these users do subclass annotations, but the types are based on things that are very special to the practices of collecting, preserving biota and curating their annotation. But none of this can be easily represented without use of specialized vocabulary that only in the vaguest sense has anything to do with annotation.
3. We found that some "natural" subclassing of annotations was really about the expectation of the annotators, which is why we introduced Expectation. This has proved very important for the actionable annotations that form the principal ones of our resource quality control applications.
4. We are willing to, and do, address some of these behavioral classifications of annotation with the domain vocabulary. Also, both for our annotation generation and consumption we enforce them with SWRL rules and a SPARQL 1.1 endpoint in the infrastructure of our network of annotation producers and consumers; we have experimented some with "clustering" annotations with named graphs. Also, when SPARQL and rules are fundamentally classifying by domain-level concerns, we think the annotation ontology itself has to have a low profile. As has been remarked elsewhere, nothing in OA should require the kind of power we're using or even part of it. But in our limited experience, a lot of classification of annotations gets more complicated when something sticks its nose up for which it's difficult to tell whether its classifying based on Target or on Body resources, or worse, sometimes one and sometimes the other. We think that OA should be free of things which carry this risk.

--Jacob Jett 18:02, 14 September 2012 (UTC)I'll try to take these arguments point by point.

(1) We agree, some of the current sub-types are better expressed as typing the target or the body rather than the annotation. Under the proposal put forth above we would deprecate any sub-class that does not inform the consumer of qualifications to the specification. Among the ones that would be deprecated then would be: oax:Change, oax:Classification, oax:Comment, oax:Description, oax:Link, oax:Moderation, oax:Question, oax:Reference, and oax:Reply. All of these seem to more appropriately type either the body or the target more than the annotation as a whole and/or can be modeled in a more actionable way by means of oax:hasMotivation and/or oax:hasExpectation.

(1.1) I think this is the exact type of trial and error experimentation with sub-classing that we would like to retain in the specification. Since we already have use cases that require sub-classes (or are at least made much easier to implement using sub-classes) we would like to maintain a narrowly scoped set of sub-classes for oa:annotation that are based on qualifications to the data model as put forth in the proposal above. The larger community should have time to implement and use the specification. If we find at a later time that no one implements the specification in a way that actually uses some or all of the sub-classes, then we should be safe to deprecate some or all of them (as the case may be), exactly as you have done with aod:DataAnnotation.

(1.2) I think that all annotations are fundamentally 'about' the target but, I get your meaning. Currently there are some sub-classes that seem more appropriate for typing the body or the target rather than the annotation as a whole. The focus of the new proposal above (or below? or on the sub-classing page anyway) is to clearly scope sub-classes to those types of annotations that are qualified versions of the annotation as modeled in the core specification. (i.e. Annotations that are not allowed to have bodies, e.g., highlights; annotations that must have a oa:hasSemanticTag, e.g., tags, etc.).

(2) For this type of vocabulary role that typing things in RDF frequently plays, it probably makes the most sense to recommend mapping domain specific lexical terms to a SKOS concept schema as Hennie suggested. I'm not certain how I would word this to fit it into the proposal on this page though. It may be better to defer this portion of the conversation for a future OA Community Group teleconference?

(3) This is very sage advice, but I argue that at this stage we still need sufficient latitude to fiddle with things via implementations. Retaining sub-classes that are narrowly scoped should let us build implementations that meet our use case needs. Any sub-classes that emerge out of the proposal here can later be deprecated if it turns out that no-one actually implements them, much as was done with aod:DataAnnotation. As you note in (4), keeping sub-classes in any form presents a risk for misuse by implementers. I think that this is a known and informed risk and we still have some work, the kind of work that can only be informed by experience, to determine if sub-classes of oa:annotation truly serve no role, at all, in the specification.

(4) Reserving this space as I continue to digest how named graphs are being used.