head 1.28; access; symbols; locks; strict; comment @# @; 1.28 date 2009.11.25.03.14.42; author GarryJolleyRogers; state Exp; branches; next 1.27; 1.27 date 2009.11.20.02.45.35; author LeeBelbin; state Exp; branches; next 1.26; 1.26 date 2007.04.25.22.35.09; author GregorHagedorn; state Exp; branches; next 1.25; 1.25 date 2007.03.06.18.06.51; author RicardoPereira; state Exp; branches; next 1.24; 1.24 date 2006.10.06.10.13.37; author JessieKennedy; state Exp; branches; next 1.23; 1.23 date 2006.05.13.01.00.30; author GregorHagedorn; state Exp; branches; next 1.22; 1.22 date 2006.05.10.08.57.52; author GregorHagedorn; state Exp; branches; next 1.21; 1.21 date 2006.05.08.10.42.51; author GregorHagedorn; state Exp; branches; next 1.20; 1.20 date 2006.05.05.20.35.23; author RicardoPereira; state Exp; branches; next 1.19; 1.19 date 2006.05.05.18.22.19; author BobMorris; state Exp; branches; next 1.18; 1.18 date 2005.03.10.05.52.24; author BobMorris; state Exp; branches; next 1.17; 1.17 date 2005.03.09.15.14.34; author GregorHagedorn; state Exp; branches; next 1.16; 1.16 date 2005.03.09.09.08.32; author GregorHagedorn; state Exp; branches; next 1.15; 1.15 date 2004.12.13.17.04.54; author GregorHagedorn; state Exp; branches; next 1.14; 1.14 date 2004.12.13.09.40.08; author GregorHagedorn; state Exp; branches; next 1.13; 1.13 date 2004.11.01.11.26.00; author GregorHagedorn; state Exp; branches; next 1.12; 1.12 date 2004.10.26.13.06.20; author GregorHagedorn; state Exp; branches; next 1.11; 1.11 date 2004.10.26.09.45.17; author GregorHagedorn; state Exp; branches; next 1.10; 1.10 date 2004.10.25.16.33.30; author GregorHagedorn; state Exp; branches; next 1.9; 1.9 date 2004.10.06.09.19.00; author GregorHagedorn; state Exp; branches; next 1.8; 1.8 date 2004.08.25.10.51.18; author GregorHagedorn; state Exp; branches; next 1.7; 1.7 date 2004.08.13.10.39.00; author GregorHagedorn; state Exp; branches; next 1.6; 1.6 date 2004.07.19.13.37.42; author GregorHagedorn; state Exp; branches; next 1.5; 1.5 date 2004.07.19.08.06.00; author GregorHagedorn; state Exp; branches; next 1.4; 1.4 date 2002.04.14.06.48.51; author PeterThoeny; state Exp; branches; next 1.3; 1.3 date 2002.04.07.10.31.00; author PeterThoeny; state Exp; branches; next 1.2; 1.2 date 2001.11.24.11.40.23; author PeterThoeny; state Exp; branches; next 1.1; 1.1 date 2001.08.08.05.20.01; author PeterThoeny; state Exp; branches; next ; desc @none @ 1.28 log @none @ text @%META:TOPICINFO{author="GarryJolleyRogers" date="1259118882" format="1.1" 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_][BDI.SDD_ WIKI]]), ABCD (see [[http://www.bgbm.org/TDWG/CODATA/Schema/default.htm][ABCD content schema homepage]]) or TaxonConceptNames (see [[http://wiki.tdwg.org/twiki/bin/view/TNC/WebHome][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. -- [[Main.GregorHagedorn][Gregor Hagedorn]] - 2. June 2004 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! -- [[Main.GregorHagedorn][Gregor Hagedorn]] - 19 July 2004 What should UBIF become? --- ---+++UBIF Topics * SchemaDiscussion (main topic) * BDI.SDD_.CurrentSchemaVersion (download current schema of UBIF and BDI.SDD_) * BestPractices --- EFG home Until May 2006 this wiki was hosted by the [[http://www.cs.umb.edu/~alyons/efg_web/ Electronic Field Guide]] project. Many thanks to Bob Morris and his colleagues of the [[http://umb.edu/ University of Massachusetts at Boston]]! @ 1.27 log @none @ text @d1 1 a1 1 %META:TOPICINFO{author="LeeBelbin" date="1258685135" format="1.1" reprev="1.27" version="1.27"}% d4 1 a4 1 * 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 d12 1 a12 1 UBIF is an attempt to define a common foundation for several TDWG/GBIF standards like BDI.SDD (see [[BDI.SDD][BDI.SDD WIKI]]), ABCD (see [[http://www.bgbm.org/TDWG/CODATA/Schema/default.htm][ABCD content schema homepage]]) or TaxonConceptNames (see [[http://wiki.tdwg.org/twiki/bin/view/TNC/WebHome][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! d16 1 a16 1

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: d27 1 a27 1 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! -- [[Main.GregorHagedorn][Gregor Hagedorn]] - 19 July 2004 d37 1 a37 1 * BDI.SDD.CurrentSchemaVersion (download current schema of UBIF and BDI.SDD) @ 1.26 log @none @ text @d1 1 a1 1 %META:TOPICINFO{author="GregorHagedorn" date="1177540509" format="1.1" reprev="1.26" version="1.26"}% d4 1 a4 1 * UBIF currently is out of sync with the recent schema versions (UBIF still forms a core and foundation for the ongoing 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 d12 1 a12 1 UBIF is an attempt to define a common foundation for several TDWG/GBIF standards like SDD (see [[SDD.WebHome][SDD WIKI]]), ABCD (see [[http://www.bgbm.org/TDWG/CODATA/Schema/default.htm][ABCD content schema homepage]]) or TaxonConceptNames (see [[http://wiki.tdwg.org/twiki/bin/view/TNC/WebHome][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! d16 1 a16 1

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 SDD and ABCD subgroups and currently jointly authored by the 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: d27 1 a27 1 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 SDD or ABCD structures! -- [[Main.GregorHagedorn][Gregor Hagedorn]] - 19 July 2004 d37 1 a37 1 * SDD.CurrentSchemaVersion (download current schema of UBIF and SDD) @ 1.25 log @none @ text @d1 1 a1 1 %META:TOPICINFO{author="RicardoPereira" date="1173204411" format="1.1" version="1.25"}% d4 1 a4 1 Welcome to the home of the SDD WIKI! This is a web-based collaboration area for discussions of the subgroup on the Structure of Descriptive Data of the [[http://www.tdwg.org][Taxonomic Data Working Group]]. We welcome your contributions - please see the bottom of this page if you are new to this Wiki. d6 1 a6 5 --- *The UBIF Wiki currently is out of sync with the recent schema versions. It contains valuable discussions, and has therefore been migrated to the TDWG site. It needs, however, much refactoring and clean-up work at this time. -- Main.GregorHagedorn - 08 May 2006 Ongoing discussions (new topics 2006) d10 1 a10 1

What is UBIF currently?

a31 3 ??? a40 9

Notes for WIKI newcomers:

* Click on TWiki.TWikiRegistration to register if you want to contribute * If you are new to wikis, learn how to use it in ThreeEasySteps. * This wiki is open to anyone interested in the topic, but you must be a registered user to edit pages and add content. Register at the TWikiRegistration page. * See Main.TWikiUsers for a list of current subscribers. * See [[Main.WebHome][Main Main.WebHome]] for a list of all Wiki Webs supported on this site. * Want automatic email notifications when a topic on this web is modified? Simply add your wiki name to WebNotify. * Topic name conventions: topics renamed to ResolvedTopic... or ClosedTopic... are still valuable to read, but old and not relevant to ongoing discussions. Topics renamed to ZZZObsolete are resolved or closed topics that I consider no longer intelligable based on the current version of the schema. @ 1.24 log @none @ text @d1 3 a3 1 %META:TOPICINFO{author="JessieKennedy" date="1160129617" format="1.1" version="1.24"}% @ 1.23 log @none @ text @d1 1 a1 1 %META:TOPICINFO{author="GregorHagedorn" date="1147482030" format="1.1" version="1.23"}% d14 1 a14 1 UBIF is an attempt to define a common foundation for several TDWG/GBIF standards like SDD (see [[SDD.WebHome][SDD WIKI]]), ABCD (see [[http://www.bgbm.org/TDWG/CODATA/Schema/default.htm][ABCD content schema homepage]]) or TaxonConceptNames (see [[http://www.soc.napier.ac.uk/tdwg/index.php][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! @ 1.22 log @none @ text @d1 2 a2 2 %META:TOPICINFO{author="GregorHagedorn" date="1147251472" format="1.1" version="1.22"}% Welcome to the home of the UBIF WIKI! This is a web-based collaboration area for discussions on the Unified Biosciences Information Framework (UBIF). d8 2 a9 1 d46 8 a53 11

Notes for newcomers:

* Click on TWiki.AboutTheWiki if you're new to Wikis. Click on TWiki.TWikiRegistration to register if you want to contribute (see Main.TWikiUsers for a list of subscribers). * To see the entire list of Wiki Webs supported, visit The Main Main.WebHome. Of special interest to readers of this Wiki Web might be the [[SDD.WebHome][Structured Descriptive Date (SDD) WebHome]] and the [[SPECIESid.WebHome][Species Identification WebHome]]. * Want automatic email notifications when a topic is modified? Simply edit WebNotify to add the wiki name you registered. * Topic name conventions: topics renamed to ResolvedTopic... or ClosedTopic... are still valuable to read, but old and not relevant to ongoing discussions. Topics renamed to ZZZObsolete are resolved or closed topics that I consider no longer intelligable based on the current version of the schema. -- Gregor Site Tools: %INCLUDE{"%TWIKIWEB%.WebSiteTools"}% %INCLUDE{"%TWIKIWEB%.YouAreHere"}% EFG home Many thanks to Bob Morris of the [[http://umb.edu/ University of Massachusetts at Boston]] and the [[http://www.cs.umb.edu/~alyons/efg_web/ Electronic Field Guide]] project for providing the wiki infrastructure (in addition to participating ín the discussions)! d55 1 @ 1.21 log @none @ text @d1 1 a1 1 %META:TOPICINFO{author="GregorHagedorn" date="1147084971" format="1.1" version="1.21"}% d18 1 a18 1 * 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 EnumerationTypes] @ 1.20 log @none @ text @d1 1 a1 1 %META:TOPICINFO{author="RicardoPereira" date="1146861323" format="1.1" version="1.20"}% a4 1

News

d6 1 a6 2 1. A new revised ObjectOntology, ObjectTypePattern, and ObjectIdentifierPattern. * Related is also a presentation of the DataModelMatrix (future data sets may be a mosaic on a matrix of object types and detail of representation). a7 4 2. An attempt to wrap up the discussion of MultilingualDesignPattern - I propose this to be part of the level-1 abstractions for objects (label and link, as proposed in the current UBIF version. 3. Discussions on "core sets", low-structured sets of data elements, that abstract from the complexity of a more complete object model. The core sets act like data-interfaces to more complex models like ABCD or TCS. The most simple interface is always a combination for free-form text label and a machine readable link ("level 1" abstraction). The discussion here is centered on "level 2" abstraction providing a commonly required richness, sufficient for much of the data interchange, query, and consumption requirements, but by no means complete. * UBIF.LinneanCore (taxonomic names) * UBIF.AlexandriaCore (publication / publication reference) d22 1 a22 1 * 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 ProxyDataModel, see also UseProxyListsInAllTdwgGbifStandards which contains a diagram! See also GuidLinking for a general discussion of GUID types used.] @ 1.19 log @none @ text @d1 1 a1 1 %META:TOPICINFO{author="BobMorris" date="1146853339" format="1.0" version="1.19"}% a4 4 --- +++%RED% Wiki moving to tdwg web site. Watch this space for address. No further edits permitted. %ENDCOLOR% --- d7 2 a8 2 1. A new revised ObjectOntology, ObjectTypePattern, and ObjectIdentifierPattern. * Related is also a presentation of the DataModelMatrix (future data sets may be a mosaic on a matrix of object types and detail of representation). d10 4 a13 4 2. An attempt to wrap up the discussion of MultilingualDesignPattern - I propose this to be part of the level-1 abstractions for objects (label and link, as proposed in the current UBIF version. 3. Discussions on "core sets", low-structured sets of data elements, that abstract from the complexity of a more complete object model. The core sets act like data-interfaces to more complex models like ABCD or TCS. The most simple interface is always a combination for free-form text label and a machine readable link ("level 1" abstraction). The discussion here is centered on "level 2" abstraction providing a commonly required richness, sufficient for much of the data interchange, query, and consumption requirements, but by no means complete. * UBIF.LinneanCore (taxonomic names) * UBIF.AlexandriaCore (publication / publication reference) d24 7 a30 7 * 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 EnumerationTypes] * 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 ProxyDataModel, see also UseProxyListsInAllTdwgGbifStandards 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. d46 3 a48 3 * SchemaDiscussion (main topic) * SDD.CurrentSchemaVersion (download current schema of UBIF and SDD) * BestPractices d52 4 a55 4 * Click on TWiki.AboutTheWiki if you're new to Wikis. Click on TWiki.TWikiRegistration to register if you want to contribute (see Main.TWikiUsers for a list of subscribers). * To see the entire list of Wiki Webs supported, visit The Main Main.WebHome. Of special interest to readers of this Wiki Web might be the [[SDD.WebHome][Structured Descriptive Date (SDD) WebHome]] and the [[SPECIESid.WebHome][Species Identification WebHome]]. * Want automatic email notifications when a topic is modified? Simply edit WebNotify to add the wiki name you registered. * Topic name conventions: topics renamed to ResolvedTopic... or ClosedTopic... are still valuable to read, but old and not relevant to ongoing discussions. Topics renamed to ZZZObsolete are resolved or closed topics that I consider no longer intelligable based on the current version of the schema. -- Gregor @ 1.18 log @none @ text @d1 1 a1 1 %META:TOPICINFO{author="BobMorris" date="1110433944" format="1.0" version="1.18"}% d5 3 @ 1.17 log @none @ text @d1 1 a1 1 %META:TOPICINFO{author="GregorHagedorn" date="1110381274" format="1.0" version="1.17"}% d49 1 a49 1 @ 1.16 log @none @ text @d1 1 a1 1 %META:TOPICINFO{author="GregorHagedorn" date="1110359312" format="1.0" version="1.16"}% d8 1 a8 1 1. A new revised ObjectOntology and ObjectIdentifierPattern. @ 1.15 log @none @ text @d1 1 a1 1 %META:TOPICINFO{author="GregorHagedorn" date="1102957494" format="1.0" version="1.15"}% d8 5 a12 2 1. An attempt to wrap up the discussion of MultilingualDesignPattern - I propose this to be part of the level-1 abstractions for objects (label and link, as proposed in the current UBIF version. 2. Discussions on "core sets", low-structured sets of data elements, that abstract from the complexity of a more complete object model. The core sets act like data-interfaces to more complex models like ABCD or TCS. The most simple interface is always a combination for free-form text label and a machine readable link ("level 1" abstraction). The discussion here is centered on "level 2" abstraction providing a commonly required richness, sufficient for much of the data interchange, query, and consumption requirements, but by no means complete. a14 1 3. Also: please let us discuss in the UBIF structural framework a better name for the "ExternalDataInterface" element: NameForProxyOrInterfaceSection. The term "ExternalDataInterface" was much critized in Christchurch. The aim is to find a name for a section that serves as a container for replacement proxy objects where no external data exist, and for caching / interface proxies where linking information is available. @ 1.14 log @none @ text @d1 1 a1 1 %META:TOPICINFO{author="GregorHagedorn" date="1102930808" format="1.0" version="1.14"}% d8 5 a12 7 1. An attempt to wrap up the discussion of MultilingualDesignPattern - I propose this to be part of the level-1 abstractions for objects (label and link, as proposed in the current UBIF version. 2. Discussions on "core sets", low-structured sets of data elements, that abstract from the complexity of a more complete object model. The core sets act like data-interfaces to more complex models like ABCD or TCS. The most simple interface is always a combination for free-form text label and a machine readable link ("level 1" abstraction). The discussion here is centered on "level 2" abstraction providing a commonly required richness, sufficient for much of the data interchange, query, and consumption requirements, but by no means complete. * UBIF.LinneanCore (taxonomic names) * UBIF.AlexandriaCore (publication / publication reference) 3. Also: please let us discuss in the UBIF structural framework a better name for the "ExternalDataInterface" element: NameForProxyOrInterfaceSection. The term "ExternalDataInterface" was much critized in Christchurch. The aim is to find a name for a section that serves as a container for replacement proxy objects where no external data exist, and for caching / interface proxies where linking information is available. @ 1.13 log @none @ text @d1 63 a63 60 %META:TOPICINFO{author="GregorHagedorn" date="1099308360" format="1.0" version="1.13"}% Welcome to the home of the UBIF WIKI! This is a web-based collaboration area for discussions on the Unified Biosciences Information Framework (UBIF). ---

News

1. An attempt to wrap up the discussion of MultilingualDesignPattern - I propose this to be part of the level-1 abstractions for objects (label and link, as proposed in the current UBIF version. 2. Discussions on "core sets", low-structured sets of data elements, that abstract from the complexity of a more complete object model. The core sets act like data-interfaces to more complex models like ABCD or TCS. The most simple interface is always a combination for free-form text label and a machine readable link ("level 1" abstraction). The discussion here is centered on "level 2" abstraction providing a commonly required richness, sufficient for much of the data interchange, query, and consumption requirements, but by no means complete. * UBIF.LinneanCore (taxonomic names) * UBIF.AlexandriaCore (publication / publication reference) 3. Also: please let us discuss in the UBIF structural framework a better name for the "ExternalDataInterface" element: NameForProxyOrInterfaceSection. The term "ExternalDataInterface" was much critized in Christchurch. The aim is to find a name for a section that serves as a container for replacement proxy objects where no external data exist, and for caching / interface proxies where linking information is available. ---

What is UBIF currently?

UBIF is an attempt to define a common foundation for several TDWG/GBIF standards like SDD (see [[SDD.WebHome][SDD WIKI]]), ABCD (see [[http://www.bgbm.org/TDWG/CODATA/Schema/default.htm][ABCD content schema homepage]]) or TaxonConceptNames (see [[http://www.soc.napier.ac.uk/tdwg/index.php][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 SDD and ABCD subgroups and currently jointly authored by the 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 EnumerationTypes] * 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 ProxyDataModel, see also UseProxyListsInAllTdwgGbifStandards 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. -- [[Main.GregorHagedorn][Gregor Hagedorn]] - 2. June 2004 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 SDD or ABCD structures! -- [[Main.GregorHagedorn][Gregor Hagedorn]] - 19 July 2004 What should UBIF become? ??? --- ---+++UBIF Topics * SchemaDiscussion (main topic) * SDD.CurrentSchemaVersion (download current schema of UBIF and SDD) ---

Notes for newcomers:

* Click on TWiki.AboutTheWiki if you're new to Wikis. Click on TWiki.TWikiRegistration to register if you want to contribute (see Main.TWikiUsers for a list of subscribers). * To see the entire list of Wiki Webs supported, visit The Main Main.WebHome. Of special interest to readers of this Wiki Web might be the [[SDD.WebHome][Structured Descriptive Date (SDD) WebHome]] and the [[SPECIESid.WebHome][Species Identification WebHome]]. * Want automatic email notifications when a topic is modified? Simply edit WebNotify to add the wiki name you registered. * Topic name conventions: topics renamed to ResolvedTopic... or ClosedTopic... are still valuable to read, but old and not relevant to ongoing discussions. Topics renamed to ZZZObsolete are resolved or closed topics that I consider no longer intelligable based on the current version of the schema. -- Gregor Site Tools: %INCLUDE{"%TWIKIWEB%.WebSiteTools"}% %INCLUDE{"%TWIKIWEB%.YouAreHere"}% @ 1.12 log @none @ text @d1 1 a1 1 %META:TOPICINFO{author="GregorHagedorn" date="1098795980" format="1.0" version="1.12"}% d14 1 a14 1 3. Also: please let us discuss in the UBIF structural framework a better name for ExternalDataInterface, which was critized in the Christchurch. @ 1.11 log @none @ text @d1 1 a1 1 %META:TOPICINFO{author="GregorHagedorn" date="1098783917" format="1.0" version="1.11"}% d8 3 a10 1 Discussions on "core sets", low-structured sets of data elements, that abstract from the complexity of a more complete object model. The core sets act like data-interfaces to more complex models like ABCD or TCS. The most simple interface is always a combination for free-form text label and a machine readable link ("level 1" abstraction). The discussion here is centered on "level 2" abstraction providing a commonly required richness, sufficient for much of the data interchange, query, and consumption requirements, but by no means complete. d14 1 a14 1 Also: please let us discuss in the UBIF structural framework a better name for ExternalDataInterface, which was critized in the Christchurch. @ 1.10 log @none @ text @d1 1 a1 1 %META:TOPICINFO{author="GregorHagedorn" date="1098722010" format="1.0" version="1.10"}% d4 12 d58 1 a58 2 %INCLUDE{"%TWIKIWEB%.YouAreHere"}% @ 1.9 log @none @ text @d1 1 a1 1 %META:TOPICINFO{author="GregorHagedorn" date="1097054340" format="1.0" version="1.9"}% d16 1 a16 1 * A single "payload" element which must 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. d46 2 a47 1 %INCLUDE{"%TWIKIWEB%.YouAreHere"}% @ 1.8 log @none @ text @d1 1 a1 1 %META:TOPICINFO{author="GregorHagedorn" date="1093431078" format="1.0" version="1.8"}% d15 1 a15 1 * 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 ProxyDataModel, see also UseProxyListsInAllTdwgGbifStandards which contains a diagram!] d17 1 d27 1 @ 1.7 log @none @ text @d1 1 a1 1 %META:TOPICINFO{author="GregorHagedorn" date="1092393540" format="1.0" version="1.7"}% d11 1 a11 1 * 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 EnumerationsTypes] @ 1.6 log @none @ text @d1 1 a1 1 %META:TOPICINFO{author="GregorHagedorn" date="1090244262" format="1.0" version="1.6"}% d6 1 a6 1 UBIF is an attempt to define a common foundation for several TDWG/GBIF standards like SDD (see [[SDD.WebHome][SDD WIKI]]), ABCD (see [[http://www.bgbm.org/TDWG/CODATA/Schema/default.htm][ABCD content schema homepage]]) or TaxonNames (see [[http://tdwg.napier.ac.uk/phpwiki/index.php/HomePage][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! d14 1 a14 1 * 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 SourceMetadata] @ 1.5 log @none @ text @d1 1 a1 1 %META:TOPICINFO{author="GregorHagedorn" date="1090224360" format="1.0" version="1.5"}% d32 1 @ 1.4 log @none @ text @d1 2 a2 2 %META:TOPICINFO{author="PeterThoeny" date="1018766931" format="1.0" version="1.4"}% Welcome to the home of %WIKITOOLNAME%.%WEB%. This is a web-based collaboration area for ... d4 1 a4 2 * MeetingMinutes * d6 1 a6 1 ---++ Site Tools of the %WEB% Web d8 34 a42 2 *Notes:* a43 2 %INCLUDE{"%TWIKIWEB%.SiteMap"}% @ 1.3 log @none @ text @d1 1 a1 1 %META:TOPICINFO{author="PeterThoeny" date="1018175460" format="1.0" version="1.3"}% d7 3 a9 9 ---++ Maintenance of the %WEB% web
*    (More options in WebSearch) * WebChanges: Find out recent modifications to the %WIKITOOLNAME%.%WEB% web. * WebIndex: Display all %WIKITOOLNAME%.%WEB% topics in alphabetical order. See also the faster WebTopicList * %NOTIFYTOPIC%: Subscribe to be automatically notified when something changes in the %WIKITOOLNAME%.%WEB% web. * %STATISTICSTOPIC%: View access statistics of the %WIKITOOLNAME%.%WEB% web. * %WEBPREFSTOPIC%: Preferences of the %WIKITOOLNAME%.%WEB% web.
d12 1 a12 2 * You are currently in the %WIKITOOLNAME%.%WEB% web. The color code for this web is a (SPECIFY COLOR) background, so you know where you are. * If you are not familiar with the %WIKITOOLNAME% collaboration tool, please visit %TWIKIWEB%.WelcomeGuest in the %WIKITOOLNAME%.%TWIKIWEB% web first. @ 1.2 log @none @ text @d1 1 a1 1 %META:TOPICINFO{author="PeterThoeny" date="1006602023" format="1.0" version="1.2"}% d21 1 a21 1 %INCLUDE{"%TWIKIWEB%.TWikiWebsTable"}% @ 1.1 log @none @ text @d1 1 a1 1 %META:TOPICINFO{author="PeterThoeny" date="997248001" format="1.0beta2" version="1.1"}% d11 1 a11 1 * WebIndex: Display all %WIKITOOLNAME%.%WEB% topics in alphabetical order. @