GarryJolleyRogers - Wed Nov 25 2009 - Version 1.28
UBIF Wiki
UBIF currently is out of sync with the recent schema versions (UBIF still forms a core and foundation for the ongoing BDI.SDD_ development). However, this Wiki contains valuable discussions, and has therefore been migrated to the TDWG site. It needs, however, much refactoring and clean-up work at this time. UBIF is open to any revitalization, and under new leadership if a need for cross-cutting schemata arises again -- Main.GregorHagedorn - 26 April 2007
Discussions in 2006
CanonicalURI (problems when using and comparing URIs as GUIDs)
What was UBIF up to 2005?
UBIF is an attempt to define a common foundation for several TDWG/GBIF standards like BDI.SDD_ (see BDI.SDD_ WIKI), ABCD (see ABCD content schema homepage) or TaxonConceptNames (see Taxonomic Concept Transfer Schema WIKI). The following text is taken from the base annotation of the UBIF.xsd schema file. Please do correct or comment on this details of the text, and also comment on the general desirability of aspects!
Unified Biosciences Information Frameword (UBIF) XML schema for data exchange and integration across knowledge domains. The schema has been design for biological data, but is applicable to other knowledge areas as well. It is based on work of the TDWG BDI.SDD_ and ABCD subgroups and currently jointly authored by the BDI.SDD_, ABCD, TaxonName subgroups and by GBIF (Global Biodiversity Information Facility). The framework may be used without changes for new schemata, no registration is necessary. Its main features are:
A foundation of shared simple and complex types, including some enumerations to simplify world-wide data integration and interoperability across language barriers. [Please discuss in SimpleTypes, ComplexTypes, and EnumeratedValues]
A top-level structure of Datasets collections containing independent Dataset objects. The collection is purposely semantically neutral; relations between Dataset have to be discovered by the data consumer or are assumed to be implicit in the protocol requesting the data. [Please discuss in TopLevelStructure]
Derivation metadata that support tracing and debugging the online transformation history data. They provide important technical information about access providers and the path of potentially multiple portals involved. [Please discuss in DerivationHistory]
Metadata describing the principal data collection from which the dataset was derived. The dataset may represent the entire source dataset or it may be filtered, normalized, or enriched with secondary information. A dataset is never an aggregation of multiple data collection sources with different authorship, copyright, or other IPR; these are assumed to be delivered as separate datasets. Note: Derivation and project metadata together provide all necessary information for UDDI support. [Please discuss in ContentMetadata]
External data interface (EDI) providing a standard mechanism to link to external data providers for knowledge domains outside of the scope of the current dataset. This includes a collection of supported object linking mechanisms involving globally unique identifiers and resolving mechanisms. Proxy objects can replace a links in cases where a specific object is (perhaps not yet) available in an external data source, and they cache a minimalized data interface on the assumption that access is asynchronous, slow, or may be temporarily unavailable. Furthermore, these cached data provide semantic information to human readers, preserving the semantics of a link even if it has become permanently broken. [Please discuss in ObsoleteTopicProxyDataModel, see also ObsoleteProxyListsInAllTdwgGbifStandards which contains a diagram! See also GuidLinking for a general discussion of GUID types used.]
A single "payload" element which may come from a different namespace. Note that within a Datasets collection each Dataset object may have a payload from a different external schema. It is the responsibility of the consumer to decide which dataset payload it is interested in or can process.
A proposal to handle some basic text (= xhtml inline) formatting (bold, italic, super/subscript) in a way that does not hurt interaction, and is relatively neutral if ignored. For perfect searching and display, indexing and rendering processors should however be aware of the conventions used. See UBIF.FormattedText for further information.
PS. Please review/comment on/correct the text given above. I cannot do much more without feedback or contributions... It will also be very helpful if, with or without reference to the a someone could provide a brainstorm of which features are considered most important - perhaps with indications of priority - for overarching design patterns all TDWG schemata. I believe this will be useful even if you are not already intimately acquainted with current BDI.SDD_ or ABCD structures! -- Gregor Hagedorn - 19 July 2004
Until May 2006 this wiki was hosted by the Electronic Field Guide project. Many thanks to Bob Morris and his colleagues of the University of Massachusetts at Boston!