UBIF_BasePattern.xsd schema file overview

(Version: Unified Biosciences Information Framework (UBIF) 1.1)

TDWG working group: Structure of Descriptive Data (SDD)


This document gives an overview of the schema components present in a single schema file, similar to the entry view provided by graphical schema editors. It documents only the root level annotations and components (elements, global attributes, simple and complex types, and groups). The definition of the components listed here is documented separately (hyperlinking could not yet be implemented).

Because the UBIF schema is designed as a type library, complex types represent class definitions and most schema files contain only a single root-level element.

Please see the schema documentation resource directory for schema overviews of other files and detailed component documentation.

Schema file content

The following content is generated automatically from the documentation inside the schema file:

Unified Biosciences Information Framework (UBIF) XML schema. This part provides a fundamental abstract bioscience object with a pattern for object-id, object representation, and object linking and referencing (simple direct text, document-internal cross-references, global guid references, or nested use of full object type).

Copyright © 2006 TDWG (Taxonomic Databases Working Group, www.tdwg.org). See the file UBIF_(c).xsd for authorship and licensing information.

Includes: UBIF_TypeLib.xsd

All fundamental UBIF object types are derived from the following base type:

Instance Identifiers are used for linking within a document (within a data set or between data sets):

Each object may have an instance ID by which exactly this digital representation may be referred to within instance documents. It is recommended to use semantically neutral ids. Temporary (repeated queries may result in documents having different ids), provider-local, and global identifier schemes are acceptable, but the consumer does not need to persist the id/ref values (i.e. always treats them as temporary). If instead of ref the resolvable uri-attribute is used, the retrieval of data should result in exactly the same representation.

The id attribute is optional. When it is missing, no document-local reference to an object instance is possible. The object may still be referenced through a uri-reference (Link) if it contains a Link rel="current" element. References should not attempt to point to URIs defined through a Link rel="about" element.

General Note: The use of attribute groups instead of globally defined and referred attributes is a work-around for problems occurring with attribute definitions in included library schemata. Normally one would use global attributes by ref; this however causes problems when attempting to use a library with no target namespace in multiple namespaces (chameleon pattern). Spy 2004.4 says, e. g., "... attributes need to be qualified because your schema uses attributeForm = qualified or global attributes. You must specify a prefix for your schema namespace."

Local (referring to id) or uri-based attribute groups used for referencing:

URI references: URIs are primarily identifiers; they may - but are not required to - allow data retrieval. URIs should not change. Recommended URI schemata for linking to related objects or abstract/ conceptual objects (like character concepts) are: 1) Conventional URLs (persistent URLs = purls are recommended). URLs may be a query like "http://x.y.fr/p/au=smith?yr=1998". 2) DOI, digital object identifier (used by the publishing industry). Example: doi:10.47198/923347' 3) Perhaps also LSID. Ideally, URIs should remain unchanged to enable data comparisons. Social reasons may prevent this, especially where authors working at organisation are not allowed to use the organisations DNS address after they stop working there. Other options (sci. societies, GBIF) should then be investigated. Further, the path within the URI of the organisation should be constructed so that uniqueness can be expected for social reasons, especially by including a personal or team-name. Example: http://xyz.de/g.hage/ coelomycetes, but not. xyz.de/plants.

References to objects should use either the ref (pointer to an id in same document) or href (= pointer to a uri) attribute. The name of element name should differ from the object name, to allow designs that offer a choice of providing a full object or an object reference (xml schema can not use different attributes content to detect the type!)

derived types based on URIRef

binary file encoding:

Components used in the Representation part of the general AbstractObject type:

Note: Earlier UBIF versions had specific label types of various complexity (SimpleLabel, Label, LabelWithDetail, RichMediaLabel, etc.) for different objects. This caused a significant additional complexity in the design. The new model accepts that some objects may offer a number of representation choices that may rarely or never be used.

In contrast to most reference types (defined in UBIF_CoreOntology or schemata defining derived object types), GeographicArea and MediaObject references are already defined here. Media files such as still images are used as part of representation. This is especially important for structural, character or state concepts but even audio or video have customarily title image representing them in the form of a fully informative image or an icon.

Public objects carrying an id also generally provide for developer annotations/comments (undefined language), version extensions for future versions of UBIF, and custom extensions (= "application annotations").

Collection base types:

w3c schema provides no internal method to inform software whether the sequence of elements that may occur multiple time (i.e. sequence of members in a collection) bears any significance or not. By default all processors should preserve sequence. However, for many purposes (editing, sorted reporting, data integration from multiple sources) it is important to know whether a sequence carries semantics or not. The following base types express this for those parts of the schema where collections are expressed within container elements.

(Generated on 23. May 2006 by DiversitySchemaTools Version 0.5. Copyright (c) G. Hagedorn 2006.)