23 lines
2.8 KiB
Plaintext
23 lines
2.8 KiB
Plaintext
---+!! %TOPIC%
|
|
|
|
%META:TOPICINFO{author="GregorHagedorn" date="1147083758" format="1.1" version="1.5"}%
|
|
%META:TOPICPARENT{name="ObsoleteTopicProxyDataModel"}%
|
|
One way to view the proxy model is to view them as interfaces to more complex data models. Whether a complex xml model exists (ABCD, TCS, SDD, etc.) or whether the interface design directly addresses relational databases (such as <nop>DarwinCore) is irrelevant in this context. I believe for the major knowledge domains (names, concepts, geography, literature/publication, agent, descriptions) we ultimately need <br/>
|
|
a) complex data models<br/>
|
|
b) data interface definitions.
|
|
|
|
Data interfaces should shield the complexity of a fuller model (i.e. the full model can be treated as a black box). They should be rough enough to fit to several models, but also detailed enough to allow the definition of proxy data (i.e. make a substantial semantic definition in cases where no external model is available, this is the idea of the proxy as a stand-in if no external data are available - which is the most common case now).
|
|
|
|
Data interface are often implicitly used in current practice. Specify uses a simplified literature and nomenclature interface. <nop>DwC contains name and geographical location interfaces. Napier Taxon Concept schema contains yet other interfaces for literature and specimen, and Linn.Core has yet another literature interface (and Jerry explicitly points to the need to agree on a common one, see the UBIF WIKI literature proxy page, http://wiki.cs.umb.edu/twiki/bin/view/UBIF/ProxyDataPublication).
|
|
|
|
I think the query/protocol question is a natural offspring of having a data interface. The interface by its very nature should be ideal for a simplified and general query protocol.
|
|
|
|
---
|
|
|
|
Chris Lyal wrote: "I agree with you that we need to discuss the issues in a non-technical fashion (or as non-techical as possible). There are some practical problems to solve, and we will need to make what we settle on accessible to a lot of people who do not know XML and want a simple tool (with simple terminology) to enable them to get their name data on the web in a forma that allows interoperability. I think that we can produce this while still encompassing all the details that we will come across in dealing with name-related matters. I would like to go away from the meeting secure in the knowledge that we are on track to getting a standard that ECAT can use, and have operating, within 12 months. I don't think this is unrealistic, and I fear that any greater delay will cause us major problems."
|
|
|
|
* When you look at ProxyDataPublication -- are such diagrams a way to lead the discussions despite their technical nature? What would you do different?
|
|
* Can we hold such a discussion on the WIKI?
|
|
|
|
-- [[Main.GregorHagedorn][Gregor Hagedorn]] - 12 Sep 2004
|