158 lines
9.8 KiB
Plaintext
158 lines
9.8 KiB
Plaintext
head 1.7;
|
|
access;
|
|
symbols;
|
|
locks; strict;
|
|
comment @# @;
|
|
|
|
|
|
1.7
|
|
date 2009.11.25.03.14.39; author GarryJolleyRogers; state Exp;
|
|
branches;
|
|
next 1.6;
|
|
|
|
1.6
|
|
date 2009.11.20.02.45.32; author LeeBelbin; state Exp;
|
|
branches;
|
|
next 1.5;
|
|
|
|
1.5
|
|
date 2007.03.06.17.30.00; author TWikiGuest; state Exp;
|
|
branches;
|
|
next 1.4;
|
|
|
|
1.4
|
|
date 2006.05.08.10.22.39; author GregorHagedorn; state Exp;
|
|
branches;
|
|
next 1.3;
|
|
|
|
1.3
|
|
date 2004.07.15.18.20.00; author GregorHagedorn; state Exp;
|
|
branches;
|
|
next 1.2;
|
|
|
|
1.2
|
|
date 2004.06.11.13.46.09; author DavidRemsen; state Exp;
|
|
branches;
|
|
next 1.1;
|
|
|
|
1.1
|
|
date 2004.06.11.08.10.10; author GregorHagedorn; state Exp;
|
|
branches;
|
|
next ;
|
|
|
|
|
|
desc
|
|
@none
|
|
@
|
|
|
|
|
|
1.7
|
|
log
|
|
@none
|
|
@
|
|
text
|
|
@%META:TOPICINFO{author="GarryJolleyRogers" date="1259118879" format="1.1" version="1.7"}%
|
|
%META:TOPICPARENT{name="UBioXidDevelopment"}%
|
|
---+!! %TOPIC%
|
|
|
|
Patrick wrote: "As far as the name sources go, we do plan on combining the two project eventually, but we are really trying to get X:ID fully functioning and comprehensive by itself." -- The idea of SDD, and in fact something we are currently testing for all GBIF interaction in a schema probably called UBIF is that to allow interaction, it is a good idea to have something like proxies inside your current domain/application. The <nop>ClassNames collection is just a proxy, which is the reason why the name is under Label rather than something more specific like <nop>TaxonName or Name. The idea of proxies is to provide inside, e.g., the identification application a local list of external objects with a minimal representation, so that it can function when the other service, e.g. the uBio name service, is down. Also, the proxies encapsulate all the linking. So rather than providing specifically uBio linking stuff throughout the X:ID application, you consistently refer to the <nop>ClassName proxies under local schema control. If your application wants to do something real smart, it goes to the uBio service that is identified by some mechanism inside the <nop>ClassName/ObjectLink. The proxy also takes care of the case that the external data source provides most, but not all objects, and that the external is not under your control. So although it may be a good idea to tell them, you can have a local-only name. The nicest thing is that the name service can detects this after discovering a UBIF-style resource and conversely fill its gaps or report to you! So it is quite flexible and provides loose coupling, which I consider desirable.
|
|
|
|
Since we are just trying to hammer this out, any comments on whether it is a good idea, and how we can make this intuitive to understand are greatly appreciated. What are the X:ID ideas about linking?
|
|
|
|
The topics that try to explain more about proxy data are UBIF.ObsoleteTopicProxyDataModel and as an example discussion the publication proxy under UBIF.ProxyDataPublication. Both general comments and specifics on the proposed publication extensions in the latter topic are extremely welcome!
|
|
|
|
-- Main.GregorHagedorn - 11 Jun 2004
|
|
|
|
<hr>
|
|
|
|
The notion of name linking came about when we were experimenting with XSLT as part of the key development process and had the notion we could not only create different styles for different user expertise levels but that we could also add additional nomenclature metadata from an external resource. Originally, we thought it would be technically interesting to be able to add vernacular forms next to the scientific names - Carcharodon carcharias (Great White Shark) - for a non-expert style by language. So we explored how to do this using our SOAP calls. We created a function that took the taxa list from the LIF as an array then called the name server with the names as strings to make sure we could actually account for the taxa in the list. After checking our listings for homonyms we end up with a list of identifiers for each source name, looked up any vernaculars forms, and stored all of this as an array in the session variables for the specific key session.
|
|
|
|
It would be interesting to revisit at some point under the auspices of a more generalized means of defining and using an external resource. Aside from the vernacular lookups we werent sure what else in our name server would be that useful to aid in actually keying something out. On the other hand, we know we don't know very much.
|
|
|
|
--DavidRemsen- 11 Jun 2004@
|
|
|
|
|
|
1.6
|
|
log
|
|
@none
|
|
@
|
|
text
|
|
@d1 1
|
|
a1 1
|
|
%META:TOPICINFO{author="LeeBelbin" date="1258685132" format="1.1" reprev="1.6" version="1.6"}%
|
|
d5 1
|
|
a5 1
|
|
Patrick wrote: "As far as the name sources go, we do plan on combining the two project eventually, but we are really trying to get X:ID fully functioning and comprehensive by itself." -- The idea of BDI.SDD, and in fact something we are currently testing for all GBIF interaction in a schema probably called UBIF is that to allow interaction, it is a good idea to have something like proxies inside your current domain/application. The <nop>ClassNames collection is just a proxy, which is the reason why the name is under Label rather than something more specific like <nop>TaxonName or Name. The idea of proxies is to provide inside, e.g., the identification application a local list of external objects with a minimal representation, so that it can function when the other service, e.g. the uBio name service, is down. Also, the proxies encapsulate all the linking. So rather than providing specifically uBio linking stuff throughout the X:ID application, you consistently refer to the <nop>ClassName proxies under local schema control. If your application wants to do something real smart, it goes to the uBio service that is identified by some mechanism inside the <nop>ClassName/ObjectLink. The proxy also takes care of the case that the external data source provides most, but not all objects, and that the external is not under your control. So although it may be a good idea to tell them, you can have a local-only name. The nicest thing is that the name service can detects this after discovering a UBIF-style resource and conversely fill its gaps or report to you! So it is quite flexible and provides loose coupling, which I consider desirable.
|
|
d19 1
|
|
a19 1
|
|
--DavidRemsen- 11 Jun 2004
|
|
@
|
|
|
|
|
|
1.5
|
|
log
|
|
@Added topic name via script
|
|
@
|
|
text
|
|
@d1 2
|
|
d5 1
|
|
a5 3
|
|
%META:TOPICINFO{author="GregorHagedorn" date="1147083759" format="1.1" version="1.4"}%
|
|
%META:TOPICPARENT{name="UBioXidDevelopment"}%
|
|
Patrick wrote: "As far as the name sources go, we do plan on combining the two project eventually, but we are really trying to get X:ID fully functioning and comprehensive by itself." -- The idea of SDD, and in fact something we are currently testing for all GBIF interaction in a schema probably called UBIF is that to allow interaction, it is a good idea to have something like proxies inside your current domain/application. The <nop>ClassNames collection is just a proxy, which is the reason why the name is under Label rather than something more specific like <nop>TaxonName or Name. The idea of proxies is to provide inside, e.g., the identification application a local list of external objects with a minimal representation, so that it can function when the other service, e.g. the uBio name service, is down. Also, the proxies encapsulate all the linking. So rather than providing specifically uBio linking stuff throughout the X:ID application, you consistently refer to the <nop>ClassName proxies under local schema control. If your application wants to do something real smart, it goes to the uBio service that is identified by some mechanism inside the <nop>ClassName/ObjectLink. The proxy also takes care of the case that the external data source provides most, but not all objects, and that the external is not under your control. So although it may be a good idea to tell them, you can have a local-only name. The nicest thing is that the name service can detects this after discovering a UBIF-style resource and conversely fill its gaps or report to you! So it is quite flexible and provides loose coupling, which I consider desirable.
|
|
@
|
|
|
|
|
|
1.4
|
|
log
|
|
@none
|
|
@
|
|
text
|
|
@d1 2
|
|
@
|
|
|
|
|
|
1.3
|
|
log
|
|
@none
|
|
@
|
|
text
|
|
@d1 1
|
|
a1 1
|
|
%META:TOPICINFO{author="GregorHagedorn" date="1089915600" format="1.0" version="1.3"}%
|
|
d7 1
|
|
a7 1
|
|
The topics that try to explain more about proxy data are UBIF.ProxyDataModel and as an example discussion the publication proxy under UBIF.ProxyDataPublication. Both general comments and specifics on the proposed publication extensions in the latter topic are extremely welcome!
|
|
d13 1
|
|
a13 1
|
|
The notion of name linking came about when we were experimenting with XSLT as part of the key development process and had the notion we could not only create different styles for different user expertise levels but that we could also add additional nomenclature metadata from an external resource. Originally, we thought it would be technically interesting to be able to add vernacular forms next to the scientific names - Carcharodon carcharias (Great White Shark) - for a non-expert style by language. So we explored how to do this using our SOAP calls. We created a function that took the taxa list from the LIF as an array then called the name server with the names as strings to make sure we could actually account for the taxa in the list. After checking our listings for homonyms we end up with a list of identifiers for each source name, looked up any vernaculars forms, and stored all of this as an array in the session variables for the specific key session.
|
|
a17 1
|
|
|
|
@
|
|
|
|
|
|
1.2
|
|
log
|
|
@none
|
|
@
|
|
text
|
|
@d1 1
|
|
a1 1
|
|
%META:TOPICINFO{author="DavidRemsen" date="1086961569" format="1.0" version="1.2"}%
|
|
d7 1
|
|
a7 1
|
|
The topics that try to explain more about proxy data are ProxyDataModel and as an example discussion the publication proxy under ProxyDataPublication. Both general comments and specifics on the proposed publication extensions in the latter topic are extremely welcome!
|
|
@
|
|
|
|
|
|
1.1
|
|
log
|
|
@none
|
|
@
|
|
text
|
|
@d1 1
|
|
a1 1
|
|
%META:TOPICINFO{author="GregorHagedorn" date="1086941409" format="1.0" version="1.1"}%
|
|
d10 9
|
|
@
|