UBIF_BasePattern.xsd schema file overview

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

TDWG working group: Structure of Descriptive Data (SDD)

Introduction

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:

• AbstractObjectOrEventBase (Abstract Complex type): Abstract base type for all knowledge- domain specific first class object classes (= object types) in UBIF, containing generic representation, linking, text annotation, and element/attribute extension mechanisms. Although not all first-class objects require an id-attribute for local references, it may be required because of xs:key identity constraints defined in many UBIF-based schema (including SDD). This is a limitation of xml schema: It is not possible to make IDs optional, but require those present to be unique and the target of keyrefs pointing to these.
• AbstractObject (Abstract Complex type, based on AbstractObjectOrEventBase by restriction): AbstractObject with restriction: representation is required.
• AbstractEvent (Abstract Complex type, based on AbstractObjectOrEventBase by extension): Basic object type (representation not required), plus event data (date/time span, geo-location as geographic area).

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.

• LocalInstanceID (Attribute group): An instance identifier identifies a specific representation. This value is used when referencing an object (using 'ref'-attributes). It may be a value unique only within a dataset and derived object type, or within elements of the dataset, or a global id such as a uri.

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:

• LocalRefOptional (Attribute group)
• LocalRefRequired (Attribute group)

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.

• URIRefOptional (Attribute group)
• URIRefRequired (Attribute group)

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!)

• AbstractRef (Abstract Complex type): Base type for all reference types (derived by restriction)
• AbstractLocalRef (Complex type, based on AbstractRef by restriction): Local, within-document reference.
• AbstractLongStringPlusRef (Complex type, based on AbstractRef by extension): A required human readable string (label, title, name) as free-format, long-length string in the attribute 'literal'; plus optional local ref / global href attributes. Used where strings/names are often ambiguous, but may occasionally be identified as an object (e.g. publication, genus names, or taxon authors).
• AbstractShortStringPlusRef (Complex type, based on AbstractLongStringPlusRef by restriction): A required human readable string (label, title, name) as free-format, limited-length string in the attribute 'literal'; plus optional local ref / global href attributes. Like Like AbstractLongStringPlusRef, except that the literal may only be a ShortString.
• URIRef (Complex type, based on AbstractRef by restriction): Global href reference to a URI (used in derivations for specific resources types but also directly, i.e. non-abstract).

derived types based on URIRef

• Link (Complex type, based on URIRef by extension): Object linking mechanism used on entire data sets as well as all first class object types!
• LinkSet (Complex type, based on Set by extension): A collection of Link elements

binary file encoding:

• EncodedContent (Complex type, based on xs:base64Binary by extension): Base-64 encoded data (usually a binary resource file like an image) plus a MIME content type attribute. The binary data itself should be directly encoded, not wrapped in an additional MIME container.

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

• RepresentationGroup (Element group): This group may occur multiple times, i.e. Label, Detail, MediaObject may each occur multiple times, in any sequence.

• Representation (Complex type, based on Alt by extension): Language/audience specific object representation for human consumers, using free-form text labels, descriptions, images, etc.
• RepresentationReqrd (Complex type, based on Representation by restriction): Representation type, with at least one Representation element required (restriction)
• SimpleRepresentation (Complex type, based on Alt by extension): Like Representation, but without Detail, and without Label role (may be treated as if Label role were fixed to 'full').
• LabelText (Complex type, based on ShortStringL by extension): ShortStringL extended with LabelRoleEnum 'role' attribute. Content is free form text that (usually uniquely) represent the object to human consumers. Such labels are often essential to preserve semantics if machine-readable links/IDs break. Content text may optionally be UBIF-formatted. In an LSID-based interaction, the 'title' metadata item may be considered a label with role='full'.
• DetailText (Complex type, based on LongStringL by extension): LongStringL extended with a DetailRoleEnum 'role' attribute.

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.

• GeographicAreaRef (Complex type, based on AbstractLocalRef by extension): Defines an element with a ref attribute pointing to a geographic area object (GeographicAreas/GeographicArea)
• MediaObjectRef (Complex type, based on AbstractLocalRef by extension): Defines an element with a ref attribute pointing to a MediaObject (MediaObjects/MediaObject)
• MediaObjectRichRef (Complex type, based on AbstractLocalRef by extension): MediaObjectRef plus optional role and language attributes

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").

• VersionExtension (Complex type): To allow fully forward compatible extensions of UBIF-compatible schemata, an extension container for the target namespace is provided for the use by the designers of the schema.

• Extensions (Element group): (NextVersion, Extensions)
• SpecificExtension (Element group)

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.

• CollectionContainer (Abstract Complex type): Base type for seq (= sequence), set, or alt (= alternatives)
• Set (Abstract Complex type, based on CollectionContainer by extension): Elements form a set, each element may occur only once and order may be changed at any time.
• Seq (Abstract Complex type, based on CollectionContainer by extension): Elements form a sequence, order carries semantics.
• Alt (Abstract Complex type, based on CollectionContainer by extension): Elements form a set of alternatives, i.e. order does not matter and processes will normally select only one member (e.g. for a given language)

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