AOD Extension of AO for Data
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)--
Contents |
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)
Examples
Some of these examples are in more detail at [Among most detailed examples are those at AOD_Multiplicity http://filteredpush.svn.sourceforge.net/viewvc/filteredpush/FP-Network/trunk/design/ontologies/ao/
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.