AOD Extension of AO for Data

From Filtered Push Wiki
Jump to: navigation, search

See also:
DataAnnotationHome Start here when looking for the landscape.
CurrentExampleList List of RDF examples of data Annotations
RDF_Coding_and_Documentation Proposed Filtered Push Coding Practices for RDF, especially Annotations. We propose to extend Annotation Ontology (AO) to annotate data. A few examples along with an extension aod.owl of the Annotation Ontology (AO) are here and illustrated below and at AOD_Multiplicity . The extension and the examples are liberally annotated.

The bleeding edge is in the ao directory of our svn repository along this path or in the ao subdirectory visible through in the FilteredPush in a path to the ao directory through our WebSVN. They are a moving target, but with lots of ontology annotations that hopefully say what the intent is. Note that the first access method may not show you the svn revision number unless you use a real svn client, not just a browser.

Discussion on this page will be appreciated, preferably citing the svn version you refer to. --Bob Morris 01:10, 4 March 2011 (EST)--

Key Concepts for Annotation of Data

Recasting the list in Historical Origins of AOD in AO (ao: including the provenance terms from pav:) and the small data extension of AO, aod:

  • The annotation itself: ao:Annotation
    • The annotator: pav:createdBy
    • The time/date of the annotation: pav:createdOn
    • The subject of the annotation: ao:annotatesResource, aod:annotatesData
    • The contentof the annotation: ao:hasTopic
    • The motivation or evidence for the annotation: aod:hasMotivation, aod:Motivation, aod:hasEvidence, aod:Evidence
    • The annotator's expectation of an outcome: aod:hasExpectation, aod:Expectation, and five punning singletons, aod:Expectation_Update, aod:Expectation_Insert, aod:Expectation_Delete, aod:Expectation_Group, and aod:Expectation_Solve_With_More_Data.

Among most detailed examples are those at AOD_Multiplicity

examples at svn rev 575

Discussed with Paolo Ciccerese on 3 March 2011. aod.owl rev 553; aodExample1.owl ref 575; aodExample2.owl rev 556. Agreed that dc:subject is the wrong thing to use and that typing the Annotation in the Annotation class hierarchy would be better. Anyone who wants to look at these examples would do well to use Protege 4.1 and start with the Individual named HUH_Errors in aodExample1 (as of rev 679 in aodExample1a), and that named IdentificationAssertionOfFlickrImageContent in aodExample2.

examples at svn rev 688

Have moved aodExample1 to aodExample1a, and made aodExample1 just a very simple case of one annotation with no multiplicity. aodExample1a uses an individual of AnnotationSet to group a pair of annotations. Question for Paolo: should createdBy and createdOn be properties of the AnnotationSet or duplicated on each Annotation (likewise for any other properties that might be shared by the set)? Example 4 has two annotations, but not grouped into a set. Example 5 handles multiplicity in an entirely different way by annotating a data set and using a selector to identify three records in the data set. Zhimin points out that it would be good to provide an example of a column based selector to illustrate, for example, that a data set has latitude and longitude transposed for the entire data set. Example 6 is now reasonably fleshed out. --Paul J. Morris 15:21, 6 July 2011 (EDT)


Some of these examples are in more detail at [Among most detailed examples are those at AOD_Multiplicity

aodExample1 An annotation correcting the country name found on a specimen record.
aodExample4 Two annotations, each asserting a new determination for a specimen. Here the two annotations are not grouped.
aodExample5 A annotation on a data set with a selector pointing out three records within that data set, and an expectation that the recipient of the annotation will research the problem and find more data to resolve the problem observed in the three records (in this case, salamander species being reported outside their geographic range).
aodExample6 A new determination of a specimen seen on morphbank with evidence for that determination in the form of a character state for an anatomical feature described with a Hymenoptera Anatomy Ontology term visible in a region of interest in the image of the specimen.

Historical Origins of AOD

Originally from the now obsolete Annotation Stake In The Ground presented at TDWG 2010. The notion there of "InterpretableObject" is unnecessary. It comes pretty much for free in RDF (I remain unconvinced that interpretable objects are unnecessary --Paul J. Morris 14:52, 6 July 2011 (EDT)). The key concepts are:

  • an Annotator, the agent making the annotation
  • the Annotation itself, and a few attributes:
    • a GlobalIdentifier
    • an Annotator
    • the subject of the Annotation, which is an object in a class named "InterpretableObject". It may be RDF or "opaque". In all uses of an InterpretableObject, a URI given by hasInterpretationURI serves as guidance for the interpretation object by the consuming application.
    • the date/time at which the annotation was made.
    • the content of the annotation, which is an InterpretableObject.
    • The motivation, an InterpretableObject representing the Annotator's motivation for making the observation.
    • The evidence, an InterpretableObject representing the nature of the evidence offered for the annotation. (Paolo has since convinced us that evidence is a subclass of motivation, and is the most common motivation for annotation in science).
    • The annotator's expectation of an outcome given by a small enumeration. Expectation is highly relevant to annotation of data in databases, as an annotator may assert something with an expectation that it replace values found in the existing database or supplement existing values.