1msi-ontology.sourceforge.net/metadata_annotation_v1.doc · web viewof cause here ones has to avoid...

Metadata Annotations for Ontology Engineering Draft v2 MSI Ontology, PSI Ontology and OBI WGs

08.11.2006

Metadata Annotations for Representational Units and Representational Artifacts

MSI Ontology WG: http://msi-ontology.sourceforge.net/

PSI Ontology WGs: http://psidev.sourceforge.net/

OBI Ontology WG: http://obi.sourceforge.net/

An example owl-implementation of these recommendations can be found at:https://svn.sourceforge.net/svnroot/msi-workgroups/ontology/RU_metadata.owl

https://svn.sourceforge.net/svnroot/msi-workgroups/ontology/RA_metadata.owl

Contents

1 Rationale for this document..........................................................................................3

2 (Meta-) Reference Terminology....................................................................................4

3 What are Metadata........................................................................................................5

3.1 Metadata Definitions (derived from Wiki)...............................................................5

3.2 Metadata categorisations (this chapter is DRAFT)................................................6

4 Why annotating with Metadata....................................................................................12

5 Where and how to store Metadata..............................................................................14

6 General recommendations..........................................................................................15

7 Sources of metadata...................................................................................................16

7.1 Using established metadata standards................................................................16

7.1.1 RDFS / OWL Comments...............................................................................16

7.1.2 Protégé Metadata ontology...........................................................................16

7.1.3 SKOS (Simple Knowledge Organization System)........................................17

7.1.4 Dublin Core (recommended for re-use!).......................................................19

7.1.5 ISO Standards..............................................................................................21

7.1.6 Friend of a friend (FOAF)..............................................................................22

7.1.6.1 What's FOAF for?..................................................................................23

7.1.7 Willpecker Glossary......................................................................................24

7.1.8 OntoClean: Metadata for ontology evaluation...............................................24

7.1.9 Annotea........................................................................................................24

7.1.10 Atom.............................................................................................................24

Working draft by: Daniel Schober MSI Ontology, PSI Ontology and OBI WGs members

https://svn.sourceforge.net/svnroot/msi-workgroups/ontology/RU_metadata.owl

http://obi.sourceforge.net/

http://msi-ontology.sourceforge.net/


08.11.2006

7.1.11 RSS..............................................................................................................25

7.2 Self-made metadata annotation properties..........................................................25

7.2.1 Creating own owl:AnnotationProperties (recommended!).............................25

7.2.2 Creating metaclasses with new properties...................................................26

7.2.3 Search flags within the rdfs:comment field (intermediate solution !).............26

7.2.4 Administrative Information within class names (here rdf:label).....................27

7.2.5 Proposed format independent metadata recommendation...........................28

7.2.5.1 Metadata for representational units (RUs).............................................29

7.2.5.2 Metadata for representational artifacts (RA)..........................................46

7.2.5.2.1 OMV (Ontology Metadata Vocabulary) and DEMO...........................49

7.2.5.2.2 Administrative Information within the ontology file name....................52

7.2.5.3 Owl Implementation of this metadata recommendation.........................54

8 Using Annotation Metadata Properties........................................................................58

8.1 Using the Protégé QueryTab...............................................................................58

8.2 On term obsoletions (taken from the psi recommendations by Luisa…)..............58

9 Annotating Instantiations (Annotation of Annotations)................................................61

9.1 GO evidence codes.............................................................................................61

9.2 Evidenve codes within GOA................................................................................63

9.3 An ‘evidence code’ classification within DAS-BioSapiens....................................64

10 Contributions...........................................................................................................66

11 References..............................................................................................................67



08.11.2006

1 Rationale for this documentThis document defines a set of metadata elements used for the formal annotation of CVs,

ontologies and their representational units (RU). Naming conventions are not covered here, but

addressed in the <<Naming Conventions for Controlled Vocabularies (CVs) and Ontologies>>

recommendation [1].

These recommendations have been developed to guide the work of the Metabolomics

Standards Initiative (MSI) [2] Ontology Working Group (OWG), the Proteomics Standard

Initiative (PSI) Ontology WG [3] and the Ontology for Biomedical Investigation (OBI, previously

‘FuGO’) WG, a larger, multi-domain collaborative effort [4].

Both MSI OWG and OBI WG adheres to strict ontology engineering ‘best practices’ as outlined

by the OBO consortium [5].

Sections in brackets […] are notes for the editor only. Please ignore these.



08.11.2006

2 (Meta-) Reference TerminologyKnowledge representations (KR, also called representational models) are referred to with the

term ‘representational artifact’, RA). A representational artifact is made of related

‘representational units’ (RU, also known as KR-idioms) - in most cases classes and

properties. We recommend using the term ‘class’ to refer to the representational unit that

models a ‘universal’ in an ontological representational artifact. Each class has a ‘class name’, a term (string) to designate the class. An ‘Instance’ is the representation of a ‘particular’ in

reality. A particular instantiates a universal and an instance (called an individual in owl)

instantiates a class. Properties of universals are represented through representational units

called ‘properties’. Properties which have fillers of simple datatypes (e.g. integer, string,

boolean, ...) are called ‘attributes’ or ‘datatype properties’. Properties which have classes or

instances as their fillers (also called ‘range’) are called ‘relations’ or ‘object properties’. Confusingly other formats use the word "property" for restrictions. The word ‘domain’ can mean

a group of classes that a property is asserted to (in owl), but also describes the area of interest

of a representational artifact.

For a detailed recommendation have a look at the full paper:

http://ontology.buffalo.edu/bfo/Terminology_for_Ontologies.pdf

The following key words “MUST,” “MUST NOT,” “REQUIRED,” “SHALL,” “SHALL NOT,”

“SHOULD,” “SHOULD NOT,” “RECOMMENDED,” “MAY,” and “OPTIONAL” are to be

interpreted as described in RFC-2119 document [6].


http://ontology.buffalo.edu/bfo/Terminology_for_Ontologies.pdf


08.11.2006

3 What are Metadata

3.1 Metadata Definitions (derived from Wiki)

The term Metadata (Greek meta "after" and Latin data "information") was introduced intuitively,

i.e. without exact definition. Because of that today there is a whole variety of definitions.

Metadata is often defined as data that describes other data or any class of objects whose

descriptions are required for some purpose. In this sense the word 'metadata' describes a role

that certain data could play with respect to other data. A term, which is often used as a synonym of metadata, is annotation.RDF for example has been introduced as a simple KR language for the assignment of semantic

descriptions to information resources on the web. Therefore an RDF description of a web page

represents metadata. However, an RDF description of a person, independent from any

particular documents (e.g., as a part of an RDF(S)-encoded dataset), is not metadata – this is

data about a person, not about other data. In the latter case, RDF(S) is used a regular KR

language.

Example: 12345 is data, and with no additional context is meaningless. With the additional

"metadata" of giving 12345 a meaningful name of "Zip Code".

Metadata are data themselves, and data become metadata when they are used in this way.

This happens under particular circumstances, for particular purposes, and with certain

perspectives, as no data are always metadata. The set of circumstances, purposes, or

perspectives for which some data are used as metadata is called the context. So, metadata are

data about a resource in some context. Since metadata are data they are stored and managed

as data themself. So metadata can be organised as models in some representation language

creating a RA.

Other definitions: "Metadata is information about data"

"Metadata is information about information"

"Metadata is structured, encoded data that describe characteristics of information-bearing

entities to aid in the identification, discovery, assessment, and management of the described


http://en.wikipedia.org/wiki/Data

http://en.wikipedia.org/wiki/Latin

http://en.wikipedia.org/wiki/Meta-

http://en.wikipedia.org/wiki/Greek_language


08.11.2006

entities." [ from William R. Durrell, Data Administration: A Practical Guide to Data

Administration, McGraw-Hill, 1985]

"[Metadata is a set of] optional structured descriptions that are publicly available to explicitly

assist in locating objects." [ from Ralph Kimball, The Data Warehouse Lifecycle Toolkit, Wiley,

1998, ISBN 0-471-25547-5]

As, according to the common definition, metadata themselves are data, it is possible to create metadata about metadata, metadata about metadata about metadata and so on. This can be essential to archive metadata about metadata, e. g. to keep track of where the metadata came from when merging two documents. Of cause here ones has to avoid to fall into ‚analysis-paralysis’ and has to stop capturing metadata on a senseful (meta-)level.

3.2 Metadata categorisations (this chapter is DRAFT)

Metadata Annotation properties can be structured/classified/sorted/grouped according to many different principles.

The following categorisation refers to metadata on RA and was introduced by the National

Information Stadards Organization [Understanding metadata. NISO Press, 2004]:

– Structural metadata relates to statistical measures on the graph structure underlying a

RA , e.g. the number of specific representational units e.g. number of classes and

individuals. Its availability influences the usability of a RA in a concrete application

scenario, as size and structure parameters constraint the type and performance of tools

and methods which are applied to aid the reuse process. Structural metadata are

provided by most OE tools, i.e. ‘metrics’ in Protégé.

– Descriptive metadata relates to the domain modelled in the ontology in form of class

definitions or examples.

– Administrative metadata provides information for ontology engineering to help manage

ontologies, such as when and how it was created, rights management, file format and

other technical information.

An other way would be the following ‚mutated’ from Wiki (http://en.wikipedia.org/wiki/Metadata):

Content: Metadata can either describe the resource itself, e. g. name and scope of a whole

ontology, or the content of ontology, e. g. class names and Class definitions. (This corresponds

to our distinction on Metadata for RA and RU.


http://en.wikipedia.org/wiki/Metadata


08.11.2006

Mutability: With respect to the whole resource, metadata can be either immutable, e. g. the title

of an ontology does usually not change, no matter what part of the ontology is being

considered, or mutable, e. g. the size and granularity of an ontology.

Logical function: There are three layers of logical function lying on top of each other: the

bottom is the subsymbolic layer that contains the raw data themselves, on the symbolic layer are metadata describing the content of the raw data and the topmost logical layer contains

metadata that allow logical reasoning using the symbolic layer. (same as first...)

I would add:

Storage position: Internal storage allows transferring metadata together with their data; thus

they are always at hand and can be manipulated easily. External storage allows bundling

metadata, e. g. in a database, for more efficient searching. The Protégé editor allows the

selection of different import positions/methods: From a URL, from a local repository or from a

relative path.

Others:Metadata on data (instances): RAs and RUsmetadata on RU’s

administrative metadata

security , audit and accessability (privileges, censorship)

authoring issues

status

provenance data

curation edit and maintenance

intferred extensions

versioning

semantics metadata

content specific metadata

e.g. formal definitions, axioms

lexical metadata

e.g. synonyms

metadata on RA’s

maintance

extension



08.11.2006

administrative metadata, email contact

versioning

date

provenance

collaborators

licensing

structured data (A box, imstances, Knowledge base)

audit (proof/check sequence tracking)

Checking and refinement

Design, implementation, documentation, debugging,

testing

support

Metadata elements can be categorized according to their targetted agents, i.e. Human

users, Application Software, Search-engines or OE developer-roles.

Some OE developer roles are the following:

Content PublisherRU Publisher,, RA Publisher

Content Curator, Content Editor

Content collaborator

OE-Tool Developer

Analyser

Application tool developer

Content Contributor,

Content Committer

Content Evaluator

Content User

Mapper

Others possible, as taken from: http://www.loc.gov/marc/sourcecode/relator/relatorlist.htmlAdaptor

Annotator



08.11.2006

Arranger

Author

Bibliographic

Censor

Client

Commentator

Compiler

Conductor

Consultant

Contractor

Corrector

Correspondent

Depositor

Director

Distributor

Expert

Funder

Interviewer

Licensee

Licensor

Moderator

Monitor

Observer

Originator

Owner

Patent holder

Principle Investigator

Producer

Programmer

Proofreader

Research Team Head

Respondent

Reviewer



08.11.2006

Sponsor

Standard Boby

Transcriber

[refine, add].

The NCI Thesaurus, NCIT (http://www.mindswap.org/2003/CancerOntology/) uses the

following metadata categorisation:

For complex properties,e.g. FULL_SYN, NCIT uses xml syntax within OWL (as long annotation

on annotation is not provided by owl).

3.3 Separation between Knowledge and Implementation Levels

The description of any metadata standard should distinguish between the ontology conceptualization and the ontology implementation level as concrete realization of an ontology in a particular representation language (in various languages, syntaxes, versions etc.). This separation should be based on the observation that any ontology is based

on a language-independent conceptual model. The conceptualization represents the view of the

engineering team upon the application domain, which then is implemented using an ontology

editor and stored in a specific format. The same conceptualisation might result in several

implementations, with various classes, properties and axioms, depending on the concrete


http://www.mindswap.org/2003/CancerOntology/


08.11.2006

representation paradigm, language and syntax. An Ontology Conceptualization (OC) represents the abstract or core idea of an ontology. It describes the core properties of an

ontology, independent from any implementation details. An Ontology Implementation (OI) represents a specific implementation of a conceptualization. Therefore, it describes

implementation specific properties of an ontology.



08.11.2006

4 Why annotating with MetadataMetadata is used to speed up and enrich searching for resources. In general, search queries

using metadata can save users from performing more complex filter operations manually.

In general formalisation of metadata increases data quality:

FROM: Developing High Quality Data Models 2-Sep-03

Some important properties of data for which requirements need to be met are:

definition related properties

relevance: the usefulness of the data in the context of your business.

clarity: the availability of a clear and shared definition for the data.

consistency: the compatibility of the same type of data from different sources.

content related properties

timeliness: the availability of data at the time required and how up to date that data is.

accuracy: how close to the truth the data is.

finally related to both are:

completeness: how much of the required data is available.

accessibility: where, how, and to whom the data is available or not available (e.g. security).

cost: the cost incurred in obtaining the data, and making it available for use.

The advantages of using metadata for annotating RA’s and RU’s are different, but overlapping

ones:

The availability of metadata on RA’s is a fundamental dimension of RA access, i.e. ontology

reusability (see also „DEMO - Design Environment for Metadata Ontologies“, Jens Hartmann,

Elena Paslaru Bontas, Raul Palma, Asuncion Gomez-Perez) This facilitates sharing and

reusing existing ontologies, which in turn increases their quality, as they are continuously



08.11.2006

accessed, used and revised, and the quality of their applications, since these applications

become (more) interoperable and are provided with a deeper, machine-processable

understanding of the underlying domain. Reusing existing ontologies reduces the cost of

ontology development, since it avoids the re-implementation.

Consistent Metadata help unifying the divergent and isolated efforts in OE under one coherent

OE process.

The availability of metadata on RU’s is a fundamental dimension for RU access, i.e. ontology

engineering as well as maintenance and versioning. RU-metadata provide a consistent basis for

ontology comparison, evaluation, alignment and mapping, i.e. will enable a more robust

application of the PROMPT tools. Metadata ease the evaluation and adaption of existing

ontologies in new application settings. The usage of standardised Metadata on RA’s enables for

the creation of standardised ontology search engines like swoogle. Applying metadata can as

well ease an integrated access e.g. to the OBO ontologies through Meta-tools, like LexGrid.

APIs for terminological services that describe the basic functionality needed by Applications to

access and query terminological content like the OMG Terminology query service or the HL7s

Common Terminology service (CTS) and of course they also ease access for further tools

developed currently by the NCBO BioPortal.

Anotherone: Data, Information, and Process Integration with Semantic Web Services (DIP),

http://dip.semanticweb.org and https://bscw.dip.deri.ie/bscw/bscw.cgi/0/3016

Daniele Rizzi, A framework for representing ontologies consisting of several thousand concepts, An Ontology Representation and Data Integration (ORDI) Framework . A specification for an ontology representation and data integration framework

Metadata here can provide mechanisms to provide proof and trust in automated and semantic

web systems. The advantages of metadata on RU’s are roughly the same as the ones listed in

the Naming Convention document.


http://dip.semanticweb.org/


08.11.2006

5 Where and how to store MetadataMetadata can be stored either internally, i.e. in the same file as the data, or externally, i.e. in a

separate file. Both possibilities have advantages and disadvantages. Internal storage allows

transferring metadata together with their data; thus they are always at hand and can be

manipulated easily. External storage allows bundling metadata, e. g. in a database, for more

efficient searching. There is no redundancy and metadata can be transferred simultaneously

when using streaming. However, as most formats use URIs for that purpose, the method of how

the metadata are linked to their data must be treated with care: What if a resource does not

have an URI, e. g. resources on a local hard disk or web pages that are created on-the-fly using

a content management system? What if metadata can only be evaluated if there is a connection

to the WWW, especially when using RDF/OWL? How to realize that a resource is replaced by

another with the same name but different content?

Analoguously the Protégé editor allows the selection of different import positions/methods: From

a URL, from a local repository or from a relative path.

An other question is the one for the level on which Metadata is asserted and on which level to

import a metadata ontology, i.e. let BFO import it and all obo ontologies will profit from the inherited metadata. This would ensure at least OBO wide interoperability and eases

comparison and mappings.



08.11.2006

6 General recommendations Semantics metadata (e.g. formal and non-formal definitions, non-formal axioms, synonyms,

synonym types, …) and administrative metadata on RU’s (e.g. editorial and authoring issues,

status and versioning, provenance data, rights, …) should be captured separately in a sufficiently granular and formal way to be tractable and to allow for querying these in a structured way. Metadata formalized as owl annotation properties should not distort description logics based reasoning. At least not reasoning about the actual ontology content.

Documenting RUs and RAs does not come for free. It takes about one man month to document 50 RUs to a sufficient standard.



08.11.2006

7 Sources of metadataFor a general overview on standardisation resources, look at

http://www.taxonomywarehouse.com/twstandards_inc.asp

7.1 Using established metadata standards

Unfortunately valuable metadata elements are dispersed over different metadata standard bodies, not one standard providing integrated acceptable access to all possible desired metadata elements. Further more the standards available are not orthogonal. Unforfunately

more and more standard initiatives want to make profit from their standards, so they are access

restricted.

The most important resources for metadata elements in our context are described briefly in this

section.

7.1.1 RDFS / OWL CommentsRDF and OWL provide a few elements suitable for capturing annotation metadata. These are

mostly being used for auditing and editorial information. Some predefined annotation properties

are owl:versionInfo, owl:equivalentClass, owl:sameAs, owl:differentFrom, rdfs:label, rdfs:comment, rdfs:seeAlso and rdfs:isDefinedBy the latter four referring to instances. We

currently use the rdfs:comment field to capture metadata through Search Flags described

below.

7.1.2 Protégé Metadata ontologyThe Protégé metadata ontology (http://protege.stanford.edu/plugins/owl/protégé) is an OWL-Full

ontology, with annotation properties that have range and domain restrictions. However, the

"official" online release of this file is OWL-DL, so that ontologies that use Protégé metadata

annotations can still be shared as OWL-DL. It provides the following metadata annotations:

Protégé:isCommentedOut: This property can be used in the Protégé-OWL UI to comment out

restrictions. The Protege-OWL reasoning API does not send restrictions that have this

annotation to the reasoner.

Protégé:todoPrefix: The prefix that is used to determine whether a property value is a "todo"

item.


http://protege.stanford.edu/plugins/owl/prot%C3%A9g%C3%A9

http://www.taxonomywarehouse.com/twstandards_inc.asp


08.11.2006

Protégé:todoProperty: A reference to the property that shall be used for “todo” annotations.

The default value of this is owl:versionInfo.

[refine, add].

7.1.3 SKOS (Simple Knowledge Organization System)W3C recommendation track

RDF representation of controlled structured vocabularies used for indexing.

Applications: Search/Retrieval exploiting metadata. Structure of CVs

Has OWL interoperability in mind: Skos+OWL (swed.org.uk) and Skosowl

SKOS (see also section on different sorts of synonyms) stands for Simple Knowledge

Organisation System (http://www.w3.org/2004/02/skos/). The W3C standard SKOS provides a

simple yet powerful framework for expressing knowledge structures in a machine-

understandable way, for use on the semantic web. The SKOS Core Vocabulary is an RDF

(Resource Description Framework) application. Using RDF allows data to be linked and merged

with other RDF data by Semantic Web applications. SKOS Core provides a model for

expressing the basic structure and content of thesauri style classification schemes, subject

heading lists, taxonomies, terminologies, glossaries, and other types of controlled vocabulary.

The name SKOS emphasises that: The scope of SKOS can be extended beyond thesauri to other types of representational artifacts, such as

classification schemes, subject heading systems, taxonomies, glossaries, controlled vocabularies etc...

The semantic web is not just about interchange of data, but also about the organisation of data in a

distributed, decentralised way.

RDF is not a file format, but a data formalism designed to support distributed data management in a web

environment.

The properties skos:prefLabel and skos:altLabel allow the assignment of preferred and

alternative lexical labels to a concept. The property skos:scopeNote is one of a family of

'documentation properties' that also includes skos:definition (seen in the glossary example).

The property skos:related is a semantic relation property that allows the assertion of

associative semantic relationships between two concepts. Using these properties and RDF

graph expressing the above extract can be generated.


http://www.w3.org/2004/02/skos/


08.11.2006

In the image above, each blue circle represents a resource of type skos:Concept (the rdf:type

assertions are left out for readability of the image). Also, as will be seen below, each of these

concepts has an assigned URI, however these have been left out of the image also to improve

readability of the image. Below is the RDF/XML serialisation of the RDF description of the

above 'economic co-operation' class:<rdf:RDF

xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"

xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"

xmlns:skos="http://www.w3.org/2004/02/skos/core#">

<skos:Concept rdf:about="http://www.ukat.org.uk/thesaurus/concept/1750">

<skos:prefLabel>Economic cooperation</skos:prefLabel>

<skos:altLabel>Economic co-operation</skos:altLabel>

<skos:scopeNote> Includes cooperative measures in banking, trade, industry etc.,

between and among countries.



08.11.2006

</skos:scopeNote>

<skos:inScheme rdf:resource="http://www.ukat.org.uk/thesaurus"/>

<skos:broader rdf:resource="http://www.ukat.org.uk/thesaurus/concept/4382"/>

<skos:narrower rdf:resource="http://www.ukat.org.uk/thesaurus/concept/2108"/>




<skos:related rdf:resource="http://www.ukat.org.uk/thesaurus/concept/3250"/>

</skos:Concept>

</rdf:RDF>

7.1.4 Dublin Core (recommended for re-use!)The Dublin Core namespace allows for defined metadata being formally associated with contents in our representational artifact (annotation) without getting into OWL-Full. We

have imported an OWL-DL version of the Dublin Core ontology (http://dublincore.org) and use

the Dublin Core annotation properties to annotate our ontology with various context

information’s such as ‘creator’, ‘date’, ‘language’, ‘publisher’, ‘title’ etc. Dublin Core elements

could also be used to annotate single RUs within our ontology. For a detailed description refer

to the website http://dublincore.org/documents/dcmi-terms/ or browse the annotation properties

within the Protégé properties tab, where you’ll find their definitions. If the Dublin Core

expressivity seems insufficient to us, we can request or propose own Annotation requirements

to the Dublin Core Usage Board (http://dublincore.org/usage/), which ensures the orderly

evolution of the metadata terms maintained by the Dublin Core Metadata Initiative. This board

evaluates proposals for new terms (or changes to existing terms) in light of grammatical

principle, semantic clarity, usefulness, and overlap with existing terms. DC includes two levels:

Simple (with fifteen elements) and Qualified, including an additional element as well as a group

of element refinements (or qualifiers) that adapt the semantics of the elements for resource

discovery purposes.

Imported Dublin Core annotation properties which we could use and which would be a more

formal alternative than capturing metadata in the comment field as FuGO does now (see

“Search Flags”, below) are the following:

DC element set as defined in http://purl.org/dc/elements/1.1/

A mapping to the search flags used by FuGO is provided after the defs.Dc:contributor: The name of a person, an organisation, or a service. defprov ?Dc:coverage: The extent or scope of the content of the resource. A spatial location (a place name or geographic coordinates), temporal period (a period label, date, or date range) or jurisdiction (such as a named administrative


http://purl.org/dc/elements/1.1/

http://dublincore.org/usage/

http://dublincore.org/documents/dcmi-terms/


08.11.2006

entity). When possible select a value from a controlled. Named places or time periods should be used in preference to numeric identifiers such as sets of coordinates or date ranges. def ?Dc:creator: A person, an organisation, or a service responsible for making the content. Dc:date: A date of creation or availability of the resource. The date value follows ISO 8601 [W3CDTF] e.g.: YYYY-MM-DDDc:content: An abstract, table of contents, reference to a graphical representation of content or a free-text account of the content. Dc:format: The physical or digital manifestation of the resource. The media-type or dimensions of the resource to determine the software, hardware or other equipment needed to display or operate the resource. Dimensions include size and duration. Select a value from a controlled vocabulary (i.e. MIME defining computer media formats). Dc:identifier: Unambiguously identify the resource in a context by means of a string or number conforming to a formal identification system. Example formal identification systems include URI, URL, DOI and ISBN. clsprov ?Dc:language: Best practice is to use RFC 3066 [RFC3066], which, in conjunction with ISO 639 [ISO639], defines two- and three-letter primary language tags with optional subtags. Examples include "en" for English. Dc:publisher: An person, an organisation, or a service responsible for making the resource available. clsprov ?Dc:relation: To reference the resource by means of a string or number conforming to a related resource in an other formal identification system. clsprov, defprov ?Dc:rights: A rights management statement for the resource, or reference to a service providing such information. Rights information often encompasses intellectual property Rights (IPR), Copyright, and various Property Rights. If the Rights element is absent, no assumptions can be made about the status of these and other rights with respect to the resource. Dc:source: The present resource may be derived from the Source resource in whole or in part. Reference this by means of a string or number conforming to a formal identification system. clsprov, defprov ?Dc:subject: Keywords, key phrases or classification codes that describe a topic/content of the resource. Select a value from a controlled vocabulary or formal classification scheme. altsprcls, synonyms ?Dc:title: A name by which the resource is formally known. (Human readable) synonym ?Dc:type: The nature or genre of the content of the resource, describing general categories, functions, genres, or aggregation levels for content. Select a value from a controlled vocabulary (e.g. [DCMITYPE]). altsprcls, synonyms ?

Other DC elements and element refinements as taken from http://purl.org/dc/terms/:<dc:abstract> Summary of the content in the resource.<dc:accessRights> Permissions related to who can access the resource and its security status.<dc:accrualMethod> How items are added to the resource.<dc:accrualPeriodicity> How often items are added to the resource.<dc:accrualPolicy> Guidelines governing the addition of items to the resource.<dc:alternative> Alternative title.<dc:audience> Information related to the audience that the resource is designed for.<dc:available> Date that the resource will or is available.<dc:bibliograhicCitation> A bibliographic reference related to the resource. <dc:conformsTo> Standards by which the content in the resource conforms.<dc:created> Date of initial creation.<dc:dateAccepted> Date resource is accepted.<dc:Copyrighted> Copyright statement date.<dc:dateSubmitted> Date resource is submitted.<dc:educationLevel> Targeted audience education level. <dc:extent> The size and duration of the resource.<dc:hasFormat> The resource that preexisted reference resource.<dc:hasPart> The resource from which a portion is referenced. <dc:hasVersion> The described resource version information.<dc:instructionalMethod> The process through which the resource is designed to instruct.<dc:isFormatOf> The described resource format presented in another format.<dc:isPartOf> The described resource is part of another referenced resource.<dc:isReferencedBy> The described resource is cited or pointed to by other resources.<dc:isReplacedBy> The resources content has been replaced with<dc:isRequiredBy> The content is required by a referenced resource.<dc:issued> Date resource is issued.



08.11.2006

<dc:isVersionedOf> The resource is an adaptation of a previous work or resource.<dc:license> The permissions associated with a given resource.<dc:meditator> The group or entity responsible for mediating the content in the resource.<dc:medium> The carrier of the resource.<dc:modified> Date on which the resource was changed.<dc:provenance> The details related to an ownership change.<dc:references> The references that the resource is based on.<dc:replaces> The described resource replaces the referenced resource. <dc:requires> The described requires the referenced resource.<dc:rightsHolder> The entity owning the rights of the resource.<dc:spatial> Spatial characteristics of the content in the resource.<dc:tableOfContents> Directory of content in the resource.<dc:temporal> Temporal characteristics of the content in the resource.<dc:valid> Date(s) through which the resource is valid.<dc:Box> The DCMI Box identifies a region of space using its geographic limits.<dc:DCMIType> List of types used to categorize the content.<dc:DDC> Dewey decimal classification.<dc:IMT> Internet media type.<dc:ISO3166> Country codes as per ISO 3166.<dc:ISO639-2> Codes for language representation as per ISO 639-2<dc:LLC> Library of Congress Classification.<dc:LCSH> Library of Congress Subject Headings.<dc:MESH> Medical Subject Headings<dc:NLM> National Library of Medicine Classification.<dc:Period> Specification of the limits of a time interval.<dc:Point> DCMI point.<dc:RFC1766> Internet RFC 1766 (ISO 639 two letter code combined with ISO 3166 country code)<dc:RFC3066> Internet RFC 3066 <dc:TGN> The Getty Thesaurus of Geographic Names.<dc:UDC> Universal Decimal Classification.<dc:URI> Uniform Resource Identifier.<dc:W3CDTF> W3C Encoding rules for date and time.

A Dublin Core annotated owl-class looks like this:<owl:Class rdf:ID="FuGO_77">

<rdfs:subClassOf rdf:resource="#FuGO_17"/>

<dc:creator rdf:datatype="http://www.w3.org/2001/XMLSchema#string"

>D. Schober</dc:creator>

<owl:versionInfo rdf:datatype="http://www.w3.org/2001/XMLSchema#string"

>togo: add definition</owl:versionInfo>

<rdfs:label rdf:datatype="http://www.w3.org/2001/XMLSchema#string"

>cardinal_part_of_qualitative_value</rdfs:label>

<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string"

>note: this should go to deleted classes but for now kept here as a reminder until we have identified a

mechanism to reference out to external ontologies</rdfs:comment>

<dc:description rdf:datatype="http://www.w3.org/2001/XMLSchema#string"

> defneed</dc:description>

<dc:source rdf:datatype="http://www.w3.org/2001/XMLSchema#string"

>own</dc:source>

7.1.5 ISO Standards



08.11.2006

The International Standard „ISO/IEC 24707 - Metadata for technical standards and specification

documents“ address the metadata needed to describe standards and other technical

documents.

ISO/IEC 24706 recommends relevant data elements for describing standards and other

specification documents and specifies data elements that include the scope, normative

references, terms and definitions in technical documents. The data elements are divided into

those needed to describe the contents of a standard or document and those needed to register

a standard or document in a Standards Registry. The data elements are described

implementation independant via provisions rather than in some Information Technology

modeling paradigm.

There are some other ISO standards (http://www.iso.org/iso/en/ISOOnline.frontpage), that

tackle (meta-) terminological standardization issues, e.g.:

ISO 704:2000 Terminology work – Principles and methods

ISO 860:1996 Terminology work – Harmonization of concepts and terms

ISO 1087-1:2000 Terminology work – Vocabulary – Part 1: Theory and application

ISO 1087-2:2000 Terminology work – Vocabulary – Part 2: Computer applications

ISO/IEC 11179 (all parts), Information technology — Metadata registries (MDR)

ISO/IEC CD 19773-11:2005, Information technology — Metadata modules (MM), Part 11:

Contact information

ISO 15188:2001 Project management guidelines for terminology standardization

ISO 12620:1999 Computer applications in terminology – Data categories

ISO 16642:2003 Computer applications in terminology – Terminological

ISO 1951:1997 Lexicographical symbols particularly for use in classified defining vocabularies

ISO 12200:1999 Computer applications in terminology - Machine-readable terminology

interchange format (MARTIF) - Negotiated interchange

ISO/TR 12618:1994 Computer aids in terminology - Creation and use of terminological

databases and text corpora

ISO 12620:1999 Computer applications in terminology - Data categories

For a review on these standards have a look at the following two papers by Barry Smith et al.:

http://ontology.buffalo.edu/medo/NCIT.pdf and http://ontology.buffalo.edu/medo/Wuesteria.pdf

7.1.6 Friend of a friend (FOAF)From: http://xmlns.com/foaf/0.1/


http://ontology.buffalo.edu/medo/Wuesteria.pdf

http://ontology.buffalo.edu/medo/NCIT.pdf

http://www.iso.org/iso/en/ISOOnline.frontpage


08.11.2006

Dodd's FOAF-a-matic javascript tool. To query a FOAF dataset via IRC, you can use Edd

Dumbill's FOAFbot tool, an IRC 'community support agent'. For more information on FOAF and

related projects, see the FOAF project home page at rdfweb.org.

7.1.7 Willpecker GlossaryThe Willpower Glossary is used by the current skos documentation. It is a glossary of terms

relating to thesauri and other forms of structured vocabulary for information retrieval. (See

http://www.willpowerinfo.co.uk/glossary.htm)

7.1.8 OntoClean: Metadata for ontology evaluationOntoClean provides Metaclasses and -properties used for ontology evaluation in terms of

semantic rigidity:

http://protege.stanford.edu/ontologies/ontoClean/ontoCleanOntology.html

If you include this Protégé ontology in your ontology, you can annotate your classes with meta-

properties of identity, unity, essence, and dependence. The OntoClean ontology in Protégé also

contains constraints in the Protégé Axiom Language (PAL) enabling you to verify whether the

ontology is "clean", i.e. does not violate any of the constraints based on these properties.

7.1.9 AnnoteaAnnotea for OWL

The Annotea framework provides an infrastructure for Web based creation and sharing of out of

band, fine grained, extensible annotations. The Annotea framework consists of two fundamental

aspects: an RDF based extensible annotation format and a protocol for sharing, publishing, and

retrieving those annotations.

7.1.10 AtomIn reaction to recognised issues with RSS (and because RSS 2.0 is frozen), a third group began

a new syndication specification, Atom, in June 2003, and their work was later adopted by

Internet Engineering Task Force (IETF).

The relative benefits of Atom and the two RSS branches are a matter of debate within the Web-

syndication community. Supporters of Atom claim that it improves on RSS by relying on

standard XML features, by specifying a payload container that can handle many different kinds

of content unambiguously, and by having a specification maintained by a recognised standards

organisation. Supporters of RSS claim that Atom unnecessarily introduces a third branch of

syndication specifications, further confusing the marketplace.


http://www.willpowerinfo.co.uk/glossary.htm

http://rdfweb.org/

http://rdfweb.org/foaf/

http://usefulinc.com/foaf/foafbot

http://www.ldodds.com/foaf/foaf-a-matic.html


08.11.2006

For a comparison of Atom 1.0 to RSS 2.0 see Atom Compared to RSS 2.0.

7.1.11 RSSRSS 1.0 etc can also be mixed in with FOAF terms, as can local extensions.

RSS: http://en.wikipedia.org/wiki/RSS_%28file_format%29

<rss:item rdf:about="http://www.w3.org/2001/sw/news#x20020125a">

<rss:title>An RDF Schema for P3P</rss:title>

<rss:link>http://www.w3.org/2001/sw/news#x20020125a</rss:link>

<dc:date>2002-01-25</dc:date>

<rss:description rdf:parseType="Literal">

<span class="description">The <a href="http://www.w3.org/P3P/"

shape="rect">P3P Working Group</a> has published An <a

href="http://www.w3.org/TR/2002/NOTE-p3p-rdfschema-20020125"

shape="rect"> RDF Schema for P3P</a> as a W3C Note. Based on The <a

href="http://www.w3.org/TR/2001/WD-P3P-20010928/"

shape="rect">Platform for Privacy Preferences 1.0 (P3P1.0)

Specification</a> Last Call Working Draft, the Note represents one

possible RDF schema for P3P. P3P simplifies and automates the

process of reading Web site privacy policies, promoting trust and

confidence in the Web.</span></rss:description>

</rss:item>

7.2 Self-made metadata annotation properties

7.2.1 Creating own owl:AnnotationProperties (recommended!)One possibility is to create new owl annotation datatype properties. See:

http://protege.stanford.edu/plugins/owl/publications/DL2004-protege-owl.pdf#search=

%22Protege%20owl%20scalability%20large%22

OWL supports this through annotation properties. The OWL Plugin allows to attach annotations

to ontologies, properties, individuals and classes. Annotation properties can be edited by means

of a specific table widget. The OWL Plugin allows the user to put arbitrary values into

annotations, including complex objects. These are currently being optimized for the Dublin Core

metadata so that, for example, annotation properties with change dates and authors can be

filled in automatically.


http://protege.stanford.edu/plugins/owl/publications/DL2004-protege-owl.pdf#search=%22Protege%20owl%20scalability%20large%22

http://protege.stanford.edu/plugins/owl/publications/DL2004-protege-owl.pdf#search=%22Protege%20owl%20scalability%20large%22


08.11.2006

OWL-DL supports high expressiveness without loosing computational completeness and

decidability for reasoning systems, but unlike OWL-Full it has some restriction for using

annotation properties. The sets of different properties (object-, datatype- and annotation

properties) must be disjoint, i.e. owl:versionInfo is not allowed to define a datatype and an

annotation property at the same time. Identifying domain or range constraints and sub-

properties for annotation properties is not allowed, because annotation properties must not be

used in property axioms.

The owl:AnnotationProperty is a commenting assertion which can be uniformly applied to all

sorts of OWL entities. All annotation properties are ignored by the reasoner, and they may not

themselves be structured by further axioms. owl:AnnotationProperty assertions can have as

objects either individuals or datavalues, including rdf:XMLLiterals, thus can embed arbitrary

XML, including RDF/XML (e.g., Annotea comments), XHTML, or SVG.

The built in annotation properties rdfs:label and rdfs:comment are already extensively used in

user interfaces (e.g. tool tips) and in end user renderings of ontologies.

[refine, add]

7.2.2 Creating metaclasses with new propertiesOne could add fields for metadata to the metadata-schema (the KR-language itself), but this

can force the ontology into OWL Full and one can’t use many useful protégé tools anymore. In

general it should be avoided to add slots for capturing metadata by creating a metaclass and

attaching a new meta-property to this metaclasss and subclass all usable classes from this new

metaclass (as one would do in the traditional OKBC CLIPS Protégé format). The owl plugin is

currently undergoing massive changes and will be rebuild in a way, that is more independent

from the Protégé meta-architecture.

7.2.3 Search flags within the rdfs:comment field (intermediate solution !)As long as we are still working on the final recommendations to capture metadata formally, we

simply use defined search flags within the rdfs:comment and owl:versionInfo fields. To allow fast

editing we make use of certain search-strings / markers which flag the rdfs:comment field with

annotations for certain semantic and administrative issues. In general each marker starts in a

new line and therefore starts with a capital letter. When it has multiple values, these are

separated with a comma (has to be discussed, alternatively they are added one per line each

time after the marker and a number). Do not use multiple rdfs:comment fields for one class to



08.11.2006

make more than one comment. Since there is no semantics which could disambiguate between

these, there is no advantage in dispersing annotations over multiple comments.

7.2.4 Administrative Information within class names (here rdf:label)This is not a recommendation, rather a possibility: Helper-classes, sometimes called

residual categories, that are designated through specific Pre- or Postfixes can be introduced.

Helper-classes such as "_unknown" or “_obsolete” do not designate biological universals, but nevertheless they can be useful as temporal containers while developing the ontological structure. The ”_” prefix can be used to mark helper-classes of administrative nature. Following GO editing guidelines (at http://www.geneontology.org/GO.usage.shtml) it is

recommended not to delete classes, but to transfer them into an ‘_obsolete’ class container as

we might want to use them later. When a RU is deleted, state in the comment field why and add in the definition a remapping to a corresponding RU in use. Administrative markers

within the rdfs:label class name will be seen in the hierarchy and therefore will allow for easy

recognition when browsing the hierarchy. E.g. like with the “_”, a "?" can be added directly in

front of the class name (no delimiter) when its position is not clear or it needs to be deleted or

refined. So-called residual categories (‘other’, ‘NOS’, etc.) exist in many biomedical

terminologies, though their inclusion has been subjected to criticism [e.g. College of American

Pathologists, SNOMED Clinical Terms Consultation Document; Requirements Analysis. Version

10, 2000 Oct 12.]. Often, a residual class is interpreted as the complement of the union of all the

non-residual siblings listed, but this interpretation causes problems when a terminology is

expanded to include more such siblings.

It would be nice if terms can be marked obsolete and they yet remain "in the ontology".

Dropping them intop an obsolete container looses positional information on their previous

classification. We do not want to re-capitulate the whole structure in the Obsolete container.

Maybe we can import an administrative ontology version which has residual categories. Or

maybe there is a possibility to just mark classes 'deleted# and let them persist in the ontology

and just render them invisible for the end user…

Some systems use suffixes to encode the KR-formalism entities the name belongs to, for

example “has_motherPr” (relation/predicate), “moleculeCFn” (function - returns a class),

“binary_predicatePMC” (metaclass predicate). This encoding system can be advantageous in


http://www.geneontology.org/GO.usage.shtml


08.11.2006

the early process of semantic enrichment, for example when "ontologizing" taxonomies.

However this is not always possible, because it requires an a priori knowledge of formalism

entities (RUs of the KR-Meta-language) and their semantics during the initial phase of the

collection of the CV.

7.2.5 Proposed format independent metadata recommendationThe following table gives a recommendation for a non-redundant set of metadata elements their

descriptions, cardinalities, usage obligations and a mapping to homolog elements from different

other metadata approaches (dc:core, skos, NCIT, birnlex).

We would like to point out that the recommendation in its tabular form is in principle independent from its implementation in a certain representation formalism. Nevertheless an implementation has been added in front of the tables.So far, some of these metadata elements have been kept as simple markers within the

rdfs:comment fields in the owl formalism (see above). This was an intermediate solution and

changes in the near future, when a concrete stable formalism/implementation has been agreed

upon by the group. Currently for the owl formalism creating annotation properties is the most

plausible way.

Implementation details, e.g. how to capture synonym provenances are currently being worked

out.


Metadata Annotations for Ontology Engineering Draft v1 MSI Ontology, PSI

Ontology and OBI WGs 08.11.2006

7.2.5.1 Metadata for representational units (RUs)

Find an implementation of these recommendations in owl format at https://svn.sourceforge.net/svnroot/msi-workgroups/ontology/RU_metadata.owlImport this ontology and you will also be provided with some residual

categories (e.g. _deleted, _inclusion_list and _temp_orphan) which can help

administering classes (see Chapter 7.2.5.3 Owl implementation …).

Metadata-descriptor

Definition Type (Editorial-,

Administrat

ive, Usage)

RU, not actually an annotation property

Usage category/Obligation (Required, Optional, Extensional)

Cardinality

Example for class “organism”

def_need (will

be obligate

when formal

def capturing

mechanism

exists)

To mark where no

proper definition

has been

assigned yet

A o 0:1 -

def The formalized

and normalized

class definition

according to

OBO-best

U,A * r 1 def: A living (or once

living) entity that has

(or can develop) the

ability to act or

function






practice,

explanaining the

meaning of a

class.

independently

alt_def An alternative

definition. Usually

the natural

language

definition initially

provided by the

domain

specialists

U,A o 1:* alt_def: An organism

is a biomaterial entity

which is self-

contained

temp_def When a def

needs to be

refined, it is

indicated by this

marker (was:

“???” at the

beginning of the

definition)

A o 0:1 temp_def: An

organism is a

selfsustaining system

that gains energy

through

decomposition of

nutrients. This

energy is used to

grow and propagate.

def_prov

[source: id]

The definition

provenance*

(was: Defsource)

E r 1 def_prov:

PMID:14755292




is put after the

definition. It can

be a source

publication, a

database or

ontology entry, a

group or person

name or a URL

(dbxref in obo)

GO:GO:0018995

OBI: Marc

Mustermann

uniprot:

www.websters-

online-dictionary.org

ISBN:0198506732

cls_prov The class

provenance. A

database cross

reference

E o 1 cls_prov:

GO:GO:0018995

ont_imp

[ontology

To mark from

where on in the

E o 0:* ont_imp: NCBI


http://www.websters-online-dictionary.org/

http://www.websters-online-dictionary.org/



name: class-

name and class

id]

Class-hierarchy

we want to import

/ refer to a

complete

subclass

hierarchy from

other ontologies

(was: refer to)

Taxonomy:organism

ont_imp:

ZDB:ZFA:0001094

ont_imp:

GO:GO:0018995




refact When a class has

been refactored

into more atomic

classes, then the

compound class

is made obsolete

and this deleted

source class is

mentioned after

the refact

statement in the

new atomic

classes

A, E o 0:1 refact:

selfstructuring_entity

alt_supr_cls An alternative

superclass

assertion

A o 0:* alt_spr_cls:

material_entity




cls_name The human

readable class

name

* r

cls_ID A unique

Identifyer for the

class, consisting

of Group prefix,

underscore and

number

* r OBI_001563

prpty_ID The property

unique identifyer

* r -

pref_propty_na

me

The preferred

name for a class,

usually the one

used to display in

the Hierarchy-

browser.

o -

pref_cls_name The preferred

name for a class

o organism

short_cls_nam

e

A short name

suitable for graph

visualisations etc.

synonym An alternative

class name used

as synonym

A,U o 0:* synonym: living thing




acronym An acromym for

the class name

e

abbrev An abbreviation

for the class

name

e

cls_del When a class is

deleted state why

it was deleted

A o 0:1 cls_del: redundant

class




axiom General axioms

to be fulfilled be

instances of the

class can be

captured

formlessly in

natural language

here

U * o 0:* axiom: An organism

often plays the role

Investigation object.

cls_expl An example

subclass for the

class or Database

entry which will

A,U o 0:* cls_expl.: Archaea,

Bacteria, Eukaryota,

Viroids, Viruses




be annotated

through this

inst_expl An example

value or instance

for the class or

Database entry

which will be

annotated

through this

A,U o 0:* Iist_expl: my dog

“Lassy”, patient

“Herbert Schmitt”

curation_status The status

(stability level) of

the class.

Specifies tracking

information.

A o 1 From:

http://www.w3.org/20

04/02/skos/mapping/

spec/

Each term in the

vocabulary has a

term status level

assigned. The status

of a term indicates its

level of stability, i.e.

how much it may be

expected to change

in the future. The

following status

values are allowed:

unstable

unstable, and

feedback is

welcomed on it's

current form and

utility (analagous to

'alpha' release in




software

development). It may

currently be poorly

defined. It's meaning

and/or form may be

expected to change

at any time. Do not

implement mission

critical systems that

depend on this term

persisting in its

current form.

testing The term has gone

beyond the raw

proposal stage, and

is undergoing testing

(analagous to 'beta'

release in software

development). This

term may still change

in response to

feedback from

testing, although it

may be expected not

to undergo any

radical change. The

cost to early

implementors of

changing the term

will be considered,

however the goal of

achieving wider




interoperability and

long-term stability

may override those

considerations.

stable

(meaning changing)

alterations will take

place. Implementors

can expect the term

to persist in its

current form

indefinitely.

unresolved_iss

ue

An important

problematic issue

that has to be

tackled by the

editors

editor A specific

editior/curator

who is

responsible for

and edits this RU

o

scope_note Any general

formless remark

or note about the

class (was: rem,

note)

A,U o 0:* scope_note: OBI

should link to an

external resource

here (e.g. NCBI

Taxonomy)




change_note A note that

indicates what

was modified or

changed

concerning the

RU.

o

replace Deleted /

deprecated terms

which the given

term has replaced

in recommended

usage.

o




edit_note A note related to

the RU intended

for its editor.

o

source o OBI, FMA, Chris

Mungall, …?

creation_date Date on which the

class or property

was first issued.

A o 2006-04-20




modified_date Date on which the

class or property

was last modified.

A o 2006-04-20

action_item A description of a

task / action for

the RU editor to

solve an issue

related to the RU

context_keywor

d

The main usage

contexts can be

stated, e.g. for

text mining

purposes or

translation

purposes.

formal_cls_na

me

A name for the

class that is

formaly controlled

through

linguistical rules

and axioms. E.G.

OBOL normalized

ones that adhere

to defined

principles of

word/morpheme/a

ffix order and

form. ???




old_cls_state State wheather a

class was defined

or primitive when

deleted.

old_sub_cls For deleted

classes state their

last position

within the

ontology, state

the old

subclasses.

rights Indicate access

rights for a RU.

The security

policy should be

compliant with the

rule-based

access control

standards,INCITS

, InterNational

Committee for

Information

Technology

Standards

(formerly NCITS).

(2003). Role

Based Access

Control. INCITS

359 DRAF,

4/4/2003.

http://csrc.nist.gov

/rbac/ Those

offer, in at the




same time, a

consistent layered

approach for

security policy

definition and

management and

for compliance

with a growing set

of supporting

tools.

short_cls_nam

e

A short class

name suitable for

graph

visualisations etc.

UMLS_connect A link to a UMLS

semantic Type

CUI

[this table is work in progress! Not all fields are filled with values!]

*Usage categories (Obligation):

– Required: These metadata facts are mandatory. Missing elements lead to

incomplete

metadata descriptions of ontologies and are handled accordingly by metadata

management tools.

– Optional: The specification of optional metadata elements, though not

mandatory, increases the reusability of the corresponding ontology.

– Extensional: This class of metadata elements is not represented in detail in

the core model, but can be further elaborated in extension modules

* Within the defprov specify the sources as follows:




Person source: State the Persons name or use its initials when it is unique

and the full name is available in the dc:creator value names list.

Database source: Database source identifiers have two parts, separated by

a colon: an abbreviation for the source database and the identifier of the item

in that database. For example, the definition source for the protein

GTR1_MOUSE in the Uniprot database would be represented as

“uniprot:P17809”.

Book source: If the definition comes from a book, use the ISBN. For

example, a definition source for the Oxford Dictionary of Molecular Biology

would be ISBN:0198506732. Hyphens should be removed from the ISBN.

Journal publication source: If the definition of a term comes from a paper,

use the PubMed ID, e.g. ISBN:0198506732PMID:11910864.

There are some more metadata we might want to capture (this is a draft,

contributions are welcome), e.g. synonym types, which could be captured as

done in obo (see also SKOS section).

I would like to be able to capture all comments in a RU centric based manner,

that means all comments on a RU should be accessible from within the

ontology. Possabilities are:

link to an external website, e.g. email thread on a discuss list or SF

term tracker,

capture comments directly as annotation properties

…. [add]

In general we could discuss if we want to add annotations helpful for format

conversions, analogous to the OBO, e.g.: Builtin: Def: Whether or not this

term or relation is builtin to the obo format. Allowable values are "true" and

"false" (false assumed as default). Rarely used. One example of where this is

used is the Obo relations ontology, which provides a stanza for the "is_a"

relation, even though this relation is axiomatic to the language.




We have to decide which properties we want to provide with the ontology

when its published (properties useful to the user) and which are ‘for our eyes

only’ (pure administrative and editorial). This of cause depends on the general

OE approach, i.e. one developer, a small core set of developers or a direct

access distributed development approach….

Mappings:

[add, refine]

About BIRN Property integration in the table above:For integration and mapping in the table above I left out the misspelling

property. Acronym and abbreviation could be modelled as Synonym sub

properties.

About NCIT Property integration in the table above:Is there a formal semantics behind the different ways to name properties? It

has ALL_CAPITALS, CamelCase, and space and underscore separators…

For integration and mapping in the table above I left out the domain specific

properties. Of the more general ones I left out the following:

LONG_DEFINITION, ALT_LONG_DEFINITION, Semantic Type,

Display_Name, ImageLink and NCI_META_CUI.

...

7.2.5.2 Metadata for representational artifacts (RA)

Currently edited through the metadata tab in protégé, using different metadata

ontologies

Find an implementation of these recommendations in owl format at https://svn.sourceforge.net/svnroot/msi-workgroups/ontology/RA_metadata.owl[here first draft].

ontology_title The name of

the ontology.

Dc:title

abbreviation

subject The Dc:subject




knowledge

domain

which the

ontology

allows to

represent

release_date date of the

last release

of the file

Dc:date,

created, issued

usage short

description

of the usage

of the CV file

Dec:description

editor Name of the

person

and/or the

working

group where

the last

release was

edited

Dc:creator,

contributor

publisher The

organisation

or the

person who

publishes

the ontology.

Dc:publisher

version version

number of

the released

CV file

Owl:versionInfo,

dc:hasVersion,

dc:isVersionOf

status




stability

applied_by Declares where the ontology has been applied.

tools_used The name of the tool used to create the Ontology

ont_type e.g.: Generic, Upper-Level, Domain,Application, Task, Foundational, Linguistic

OE_method/approach The name of the OE principle, method model used to create the Ontology, e.g. OBO.

repr_lang

home

URL

namespace

metrics

founder

accessability

rights

License_model

publication

documentation

domain

target_user

keywords

main_top_level classes

obo-foundry

Used_top_level_ontology

reviewer

Main_top_level_relations




Num_of_classes

Num_of_properties

Num_of_instances?

editing_mechanism

versioning_mechanism

development_period

searchability

scalability

Reasoning_services

max_hierarchy_level

maintance

known_bugs

[Also evaluate the following....]

7.2.5.2.1 OMV (Ontology Metadata Vocabulary) and DEMO

http://omv.ontoware.org/

OMV is a metadata scheme describing ontologies and ontological content.

Ontologies have seen quite an enormous development and application in

many domains within the last years, especially in the context of the next web

generation, the Semantic Web. Besides the work of countless researchers

across the world, industry starts developing ontologies to support their daily

operative business. Currently, most ontologies exist in pure form without any

additional information, e.g. authorship information, such as provided by Dublin

Core for text documents. This burden makes it difficult for academia and

industry e.g. to identify, find and apply - basically meaning to reuse -

ontologies effectively and efficiently. A proposal for a metadata standard is

Ontology Metadata Vocabulary OMV.

Tools:

..- Oyster: Decentralized Ontology repository

for managing, searching and exchanging metadata

about ontologies in a P2P network.

(http://oyster.ontoware.org)




..- Onthology.org: Centralized Ontology repository

that uses the OMV metadata schema to describe,

classify, access, evaluate and store ontologies.

(http://www.onthology.org)

OMV is a proposed core metadata vocabulary used by the DEMO (Design

Environment for Metadata Ontologies) project. OMV provides organizational,

methodological and technological level metadata. OMV is accessable as an

owl file from http://omv.ontoware.org




The following annotation properties have to be added yet in the figure above:

RepresentationParadigm and OntologyRepresentationLanguage




OntologyTask and more specialized sub-concepts such as SemanticSearch or

SemanticAnnotation.

DEMO provides the technical means required for metadata management and

maintenance for the SemanticWeb in form of the semantic engineering

platform OntoWare, which provides a scalable, collaborative software and

ontology engineering environment for the collaborating partners.

The mission of the DEMO framework can be categorized as follows:

– Provision of an organizational infrastructure for the development and

maintenance

of a commonly agreed metadata vocabulary for ontologies, including equitable

participation mechanisms for organizations involved in DEMO activities.

– Identification and application of suitable methodologies and technologies to

support

the complete life cycle of the OMV Core.

– Development and maintenance of the OMV Core.

– Promotion of OMV extensions relying on the OMV Core.

– Provision of an appropriate technical infrastructure for the enumerated

activities.

DEMO activities are driven and supervised by a Management Board (MB),

consisting of representatives from the OMV Consortium, which includes all

active OMV contributors. A central organization objective of DEMO is to keep

the barrier low for participants to join the OMV Consortium and to get involved

in the development and recommendation process. Complementary to this

distinction, DEMO foresees several Working Groups (WG) corresponding to

the aforementioned components (WG Engineering,WG Evolution,WGs

Extensions,WGs Applications).

7.2.5.2.2 Administrative Information within the ontology file name

Ignore the following if you use cvs or svn change tracking systems.Administrative information can be stored within the file and/or captured with a

file naming convention similar to the one proposed by GO (decision should be

taken):




ShortDescriptiveFilename_Date_Author_Version.ext

Where "ShortDescriptiveFilename" is a short descriptive filename that may

contain upper and lower case text, numerals, "-" (dash) and "_" (underscore).

Use upper CamelCase convention and underscore as separators. Space and

other symbols are not allowed. This should include the PSI WG acronym with

the suffix –CV. For the PSI molecular interaction controlled vocabulary it will

be “PSI-MI-CV”

"Author" is the name of the author and/or the organization where the file is

authored. Separate author and organization with a dash if both are featured.

Again, space and other symbols are not allowed here. This should include the

PSI WG acronym, followed by the WG CV chair-persons initials. For the PSI

molecular interaction controlled vocabulary with a CV chair person called

Luisa Montecchi-Palazzi it will be “PSI-MI-LMP”

"Version_Date" comprises the version number and/or the date the file is

released. Start the version number with a "v"; use "-" instead of "." in the

version numbering (like "v2-15" instead of "v2.15"). Separate version and date

with an underscore, if both are featured. For the date reference, the more significant parts should come first -- use "yyyymmdd". The advantage is, that if you sort your files alphabetically, the date is still sequential. Add an "a", "b", "c", ... suffix, if multiple versions may occur with the same

date reference. Again, space and other symbols are not allowed here. After

this follows the "." (a dot, there should only be one dot in the entire filename

and that should be right before the file extension).

"ext" is the standard file extension by which this file can be associated with an

appropriate application that will handle it. This is generally in 2~4 lower case

alphanumeric characters.

E.g.: PSI-MI-CV_PSI-MI-LMP_v1-9_20060420.oboA similar convention is being used by w3c for their published work (e.g. note

their page header information http://www.w3.org/TR/2004/REC-webont-req-

20040210/).


http://www.w3.org/TR/2004/REC-webont-req-20040210/

http://www.w3.org/TR/2004/REC-webont-req-20040210/



7.2.5.3 Owl Implementation of this metadata recommendation

An initial implementation of these recommendations as simple non-

hierarchical owl annotation properties has been created:

RA_metadata.owl for Representational Artifacts (RA)and

RU_metadata.owl for Representational Units (RU)

7.2.5.3.1 RA_metadata.owl

RA_metadata.owl formalizes recommendations for annotation properties to

describe the ontology as a whole. Metadata properties required for ontology

submission to the OBO and BioPortal repositories have been integrated as

well.

7.2.5.3.2 RU_metadata.owl

RU_metadata.owl formalizes recommendations for annotation properties to

describe the constitual parts (representational units or 'KR idioms') of the ontology. They should be sufficiently rich to aid the main domain

independent ontology engineering and administration processes. These

metadata elements provide tractable search tags to query for administrative

and editorial metadata on classes and properties.

7.2.5.3.3 Implementation principles

These implementations were build in a manner to be modular (import RU and

RA metadata separately) and simple to use. This is a lightweight set of

metadata descriptors for people that feel the need for a more ontology-centric

coverage, compared to the dublin core or skos. The Annotation properties

names were choosen to be maximally intuitive to a majority of developers and

yet short as possible, so that their xml element representation does not take

too much memory. No use of property hierarchies was made so far, but can

be added easily. Besides the dublin core, many of the more domain

independent NCIT and birnlex metadata elements were also evaluated to

build this RU metadata recommendation.

RU_metadata.owl also provides some residual categories (e.g. _deleted,

_inclusion_list and _temp_orphan) which can help administering classes, e.g.


http://msi-ontology.sourceforge.net/ontology/RA_metadata.owl



the _deleted class can substitute the current '_deleted_classes' in OBI. Such

'administrative only' classes should be separated from the domain ontology

and are hence better placed in an imported metadata ontology.

7.2.5.3.4 Usage of the owl implementation and example annotation

Import these two ontologies into the ontology you want to annotate. Use the

owl:imports statement and load them over the web from these URLs:

https://svn.sourceforge.net/svnroot/msi-workgroups/ontology/RA_metadata.owlhttps://svn.sourceforge.net/svnroot/msi-workgroups/ontology/RU_metadata.owl

As an example we show how an annotated class (here the

‘instrument_configuration’ class from the nmr.owl) looks like:

Here is the owl code for the class shown above:<owl:Class rdf:ID="NMR_400062">

<rumeta:synonym rdf:datatype="http://www.w3.org/2001/XMLSchema#string"




>machine configuration

instrument setting</rumeta:synonym>

<rdfs:subClassOf

rdf:resource="http://obi.sourceforge.net/ontology/OBI.owl#OBI_3"/>

<rumeta:editor rdf:datatype="http://www.w3.org/2001/XMLSchema#string"

>Daniel Schober</rumeta:editor>

<rumeta:action_item rdf:datatype="http://www.w3.org/2001/XMLSchema#string"

>Move to OBI.</rumeta:action_item>

<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string"

>An instrument configuration is the process of setting the possible parameters of

an instrument in order to archive a certain intended goal.</rdfs:comment>

<rumeta:pref_cls_name rdf:datatype="http://www.w3.org/2001/XMLSchema#string"

>instrument configuration</rumeta:pref_cls_name>

<rumeta:alt_def rdf:datatype="http://www.w3.org/2001/XMLSchema#string"

>An instrument configuration is the process of setting the possible parameters of

an instrument in order to archive a certain intended goal.</rumeta:alt_def>

<rumeta:modif_date rdf:datatype="http://www.w3.org/2001/XMLSchema#string"

>061108</rumeta:modif_date>

<rumeta:unresolved_issue rdf:datatype="http://www.w3.org/2001/XMLSchema#string"

>It is not clear if this domain independent class should be moved to

OBI.</rumeta:unresolved_issue>

<rumeta:rights rdf:datatype="http://www.w3.org/2001/XMLSchema#string"

>Free</rumeta:rights>

<rumeta:temp_def rdf:datatype="http://www.w3.org/2001/XMLSchema#string"

>An instrument configuration is the description for the setting of an instrument or a

machine in order to archive a certain intended goal or task.</rumeta:temp_def>

<rumeta:cls_prov rdf:datatype="http://www.w3.org/2001/XMLSchema#string"

>ArMet OM</rumeta:cls_prov>

<rdfs:label rdf:datatype="http://www.w3.org/2001/XMLSchema#string"

>instrument_configuration</rdfs:label>

<rumeta:curation_status rdf:datatype="http://www.w3.org/2001/XMLSchema#string"

>unstable</rumeta:curation_status>

<rumeta:scope_note rdf:datatype="http://www.w3.org/2001/XMLSchema#string"




>This class should capture different instrument settings on the machine used in

response to diverse analytical approaches.</rumeta:scope_note>

</owl:Class>




8 Using Annotation Metadata Properties

8.1 Using the Protégé QueryTab

[Explain profit from Search falgs and building a Query Lib]

[also look at what FuGE:audit captures…]

8.2 On term obsoletions (taken from the psi recommendations by

Luisa…)

Following GO editing guidelines (at

http://www.geneontology.org/GO.usage.shtml) a term that is no longer used

MUST not be deleted, but tagged as 'obsolete'. A unique identifier MUST NOT

be deleted once used. IDs should be conserved at all times so that, even if a

term is defunct or has a new ID, someone searching using the old ID can find

it.

A term can become obsolete when it is removed or redefined, but a term

MUST NOT be made obsolete due to changes in wording that do not alter the

meaning of the term. When a term's definition changes meaning, the term

should also be assigned a new ID, and the old ID considered obsolete.

To make a term obsolete, the CV update procedure should be followed (see

below section 13.). When you make a term obsolete, insert the word

'OBSOLETE.' at the beginning of the term definition and add a comment that

explains why the term has become obsolete and suggests alternative terms

for annotators to use. Use the following syntax for the reason for obsoletion:

comment: This term was made obsolete because [reason].

Alternative terms for obsoleted termsTo suggest alternative terms to be used instead of, or as a replacement for,

obsolete terms, use one of the following:

Exact replacement(s)When exact replacement is possible (i.e. it is safe to move all existing

annotations, keyword mappings, etc. to one term), precede the suggested

term with the verb 'use':




To update annotations, use the [PSI:XXX namespace] term '[term] ; XXX:[id]'.

Example, using a use case from the gene ontology

term: transfer RNA

goid: GO:0005563

comment: This term was made obsolete because it represents a gene

product. To update annotations, use the molecular function term 'triplet codon-

amino acid adaptor ; GO:0030533'.

No exact replacement(s)In cases where all existing annotations and mappings cannot necessarily be

transferred to one term, put 'consider' in front of the suggested terms. Syntax

for different situations:

1. There is only one suggestion, but it may not work for all annotations:

To update annotations, consider the [PSI:XXX namespace] term '[term] ; XXX:

[id]'.

2. To make more than one specific suggestion:

a) from a single ontology, separate terms with commas:

To update annotations, consider the [PSI:XXX namespace] terms '[term1] ;

XXX:[id1]', '[term2] ;XXX:[id2]', '[term3] ; XXX:[id3]'.

b) from more than one ontology, separate terms from one ontology with

commas, and use 'and' between ontology names:

To update annotations, consider the [PSI:XXX namespace] terms '[term1] ;

XXX:[id1]' and the [PSI:YYY namespace] term '[term2]; YYY:[id2]'.

examples: using a use case from the gene ontology

term: expansin

goid: GO:0009936

comment: This term was made obsolete because it represents a gene

product. To update annotations, consider the cellular component term 'cell

wall (sensu Magnoliophyta) ; GO:0009505' and the biological process term

'cell growth ; GO:0016049'.

term: blue-sensitive opsin

goid: GO:0015059

comment: This term was made obsolete because it refers to a class of

proteins. To update annotations, consider the molecular function terms




'photoreceptor ; GO:0009881', '3,4-didehydroretinal binding ; GO:0046876'

and 'retinal binding ; GO:0016918' and its children, the cellular component

term 'integral to membrane ; GO:0016021' and the biological process terms

'phototransduction, visible light ; GO:0007603' and 'UV-A, blue light

phototransduction ; GO:0009588'.

To suggest a term and all its children, use the syntax 'consider the [ontology

name] term '[term] ; GO:[id]' and its children' (as in the example above).

Restoring obsolete termsIf you need to reinstate an obsolete term back into the CV, use the following:

comment: Note that this term was reinstated from obsolete.




9 Annotating Instantiations (Annotation of Annotations)

One can see an annotation of data to TBox idioms as instantiation. The result

is an assertional box (ABox or knowledgebase (KB)). In many systems in use

today, Ontology class-instance (data)-associations derived from manual

curation or experimental evidence can carry the same weight as annotations

which have been predicted. A distinction between these different stati should

be made such that the user of the knowledgebaseis aware of the confidence

assocatied with each annotation. This distinction is critical as biologists using

this resource must be aware of the different levels of confidence associated

with the different methods of annotation. In this context Metadata on

Annotation confidence is critical for working with data from KB repositories on

ontologoically annotaded Data, e.g. the Open Biomedical Data (OBD)

repositories currently under development by NCBO.

The first step in this process is to establish the ‘status’ of all annotation types.

Could GO evidence codes be expanded and applied to our and the OBO

ontologies here? What is the ontology of 'annotation'? Can we use lessons

learned from the corrections made in successive versions for the improvement

of ontologies ? How can version-tracking be exploited for annotating

annotation-evidences ?

9.1 GO evidence codes

http://www.geneontology.org/GO.evidence.shtml

Every GO annotation must indicate the type of evidence that supports it; these

evidence codes correspond to broad categories of experimental or other

support.

An evidence code indicates how annotation to a particular term is supported,

and is not necessarily a classification of an experiment.

For every evidence code, there is room for curators to exercise judgement

about the quality of the evidence, and how well it supports annotation to a

node within each ontology.

Evidence Codes


http://www.geneontology.org/GO.evidence.shtml#evCodes

http://www.geneontology.org/GO.evidence.shtml



IC: Inferred by Curator

IDA: Inferred from Direct Assay

IEA: Inferred from Electronic Annotation

IEP: Inferred from Expression Pattern

IGI: Inferred from Genetic Interaction

IMP: Inferred from Mutant Phenotype

IPI: Inferred from Physical Interaction

ISS: Inferred from Sequence or Structural Similarity

NAS: Non-traceable Author Statement

ND: No biological Data available

RCA: inferred from Reviewed Computational Analysis

TAS: Traceable Author Statement

NR: Not Recorded

The distinction between TAS and NAS is particularly sensitive to interpretation

The evidence fields can be thought of in a loose hierarchy of reliability:

TAS / IDA o IMP / IGI / IPI o ISS / IEP o NAS

o IEA

This hierarchy should not be interpreted as a rigid ranking of evidence types;

users can and should form their own conclusions as to the reliability of each

type of evidence and each individual annotation. It is a loose hierarchy also

partly because the strength of the evidence will also depend on to what

resolution you are annotating, and because there is a range of reliability within

each evidence category (e.g. 90% versus 20% identity for "sequence

similarity" or a two-hybrid result versus co-purification over several columns

for "physical interaction").

There may be different kinds of evidence available to support annotating a

gene product to different levels within each ontology. For example, there

might be a direct assay showing that a protein localizes to the mitochondrion,


http://www.geneontology.org/GO.evidence.shtml#nr

http://www.geneontology.org/GO.evidence.shtml#tas

http://www.geneontology.org/GO.evidence.shtml#rca

http://www.geneontology.org/GO.evidence.shtml#nd

http://www.geneontology.org/GO.evidence.shtml#nas

http://www.geneontology.org/GO.evidence.shtml#iss

http://www.geneontology.org/GO.evidence.shtml#ipi

http://www.geneontology.org/GO.evidence.shtml#imp

http://www.geneontology.org/GO.evidence.shtml#igi

http://www.geneontology.org/GO.evidence.shtml#iep

http://www.geneontology.org/GO.evidence.shtml#iea

http://www.geneontology.org/GO.evidence.shtml#ida

http://www.geneontology.org/GO.evidence.shtml#ic



and a physical interaction suggesting localization to the mitochondrial matrix

(more specific node, but less reliable evidence). Curators can annotate genes

to both a parent and a child, and cite the same or different kinds of evidence

for the annotations as appropriate.

Added 2000-11-08: Heather has seen cases where a paper presents several

lines of evidence supporting a conclusion, of which each line of evidence

alone is sufficient to annotate to a higher-level (more generic) node, but

combining the lines of evidence gives the author (or curator) enough data to

support annotating to a lower-level (more specific) node. We've decided to

annotate each line of evidence singly, with the appropriate evidence code, for

the higher node (e.g. have a line for IMP, another line for IPI, for one GO ID).

The annotation to the lower node can then be included with TAS as the

evidence; cite the paper if the author draws the conclusion. If the curator

draws the conclusion, keep some record of what went into the decision.

9.2 Evidenve codes within GOA

GOA uses the following:

Use of 'Qualifiers'

A curator can choose to alter the meaning of an annotation by using a

‘qualifier’.

There are three qualifiers; NOT, colocalises_with and contributes_to and, if

used, are present in column 4 of the gene association file.

Special attention must be paid to the NOT qualifier as this completely

reverses the meaning of the annotation.

NOT is used to make an explicit note that the gene product is not associated

with the GO term. For example, if a protein has sequence similarity to an

enzyme (whose activity is GO:nnnnnnn), but has been shown experimentally

not to have the enzymatic activity, it can be annotated as NOT GO:nnnnnnn.

Colocalizes_with is used only with terms in the Cellular Component ontology

and is given to gene products that are transiently or peripherally associated

with an organelle or complex.

Contributes_to is used only with terms in the Molecular Function ontology and

is given to a gene product that is a member of a complex which has an activity




but the individual gene product does not have this activity. All gene products

annotated using 'contributes_to' must also be annotated to a cellular

component term representing the complex that possesses the activity.

[to be refined]

9.3 An ‘evidence code’ classification within DAS-BioSapiens

http://www.ebi.ac.uk/~gabby/classification.html

The DAS protocol as used by the BioSapiens project will use an evidence

code derived mini-ontology to make annotations of annotations possible:

The DAS group proposes to cluster the evidence codes into four broader,

super-categories:

Manually curated (super-code, MC), experimentally verified (EV),

computationally predicted (CP) and those where no assignment is possible

(NA).

Technically, these evidence codes will be handled by adding an ‘evidence’

attribute to the response from DAS ‘types’ commands. The value of this

‘evidence’ attribute will be the two or three uppercase letter abbreviation given

in the following table.

GO Evidence codes clustered into four categories:

Evidence Code Description BioSapiens Supercodes

Manually curated IC Inferred by Curator

MCNAS Non-traceable Author StatementRCA Comput. AnalysisTAS Traceable Author StatementExperimentally verifiedIDA Inferred from Direct Assay

EVIEP Inferred from Expression PatternIGI Inferred from Genetic InteractionIMP Inferred from Mutant PhenotypeIPI Inferred from Physical InteractionComputationally predicted




ISS Inferred From Sequence or Struct. Similarity CP

IEA Inferred from Electronic AnnotationNo assignment possibleND No biological Data available ND




10 ContributionsThis document has been drafted by Daniel Schober and it has received input

from the MSI Ontology WG, PSI Ontology WGs, OBO WG and OBI WGs’

members, in particular from:

- Gilberto Fragoso (OBI)

- Luisa Montecchi-Palazzi, Frank Gibson (PSI)

- Chris Mungall (OBO)

- Barry Smith (cBIO, OBO)

- William Bug (BIRN-Lex)

- Phillippe Rocca-Serra and Susanna-Assunta Sansone (MSI)




11 References[1] <<Naming Conventions for Controlled Vocabularies (CVs) and

Ontologies>>

http://msi-ontology.sourceforge.net/recommendations/Naming_Conv_v10.doc

[2] Establishing reporting standards for metabolomic and metabonomic

studies: A call for participation. Fiehn O, Kristal B, van Ommen B, Sumner

LW, Sansone SA, Taylor C, Hardy N, Kaddurah-Daouk R. OMICS 2006

Summer;10(2):158-63.

[3] Proteomics Standards Initiative (PSI): http://psidev.sourceforge.net/

[4] Development of FuGO: an ontology for functional genomics investigations.

Whetzel PL, Brinkman RR, Causton HC, Fan L, Field D, Fostel J, Fragoso G,

Gray T, Heiskanen M, Hernandez-Boussard T, Morrison N, Parkinson H,

Rocca-Serra P, Sansone SA, Schober D, Smith B, Stevens R, Stoeckert CJ

Jr, Taylor C, White J, Wood A; FuGO Working Group. OMICS 2006

Summer;10(2):199-204.

[5] http://obo.sourceforge.net/

[6] S. Bradner, Key words for use in RFCs to Indicate Requirement Levels,

Internet Engineering Task Force, RFC 2119, http://www.ietf.org/rfc/rfc2119.txt,

March 1997

***** NOTE: This draft document is a work in progress *****Comments and ideas are welcomed and should be sent to:

[email protected]


http://www.ietf.org/rfc/rfc2119.txt

1msi-ontology.sourceforge.net/metadata_annotation_v1.doc · web viewof cause here ones has to avoid...

Documents