wiki-archive/twiki/data/UBIF/InterfaceDiscussion.txt,v

head	1.6;
access;
symbols;
locks; strict;
comment	@# @;


1.6
date	2007.03.06.17.30.00;	author TWikiGuest;	state Exp;
branches;
next	1.5;

1.5
date	2006.05.08.10.22.38;	author GregorHagedorn;	state Exp;
branches;
next	1.4;

1.4
date	2005.03.21.22.39.58;	author JenniferForman;	state Exp;
branches;
next	1.3;

1.3
date	2004.09.12.16.46.09;	author GregorHagedorn;	state Exp;
branches;
next	1.2;

1.2
date	2004.09.08.16.46.00;	author GregorHagedorn;	state Exp;
branches;
next	1.1;

1.1
date	2004.09.02.13.46.43;	author GregorHagedorn;	state Exp;
branches;
next	;


desc
@none
@


1.6
log
@Added topic name via script
@
text
@---+!! %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
@


1.5
log
@none
@
text
@d1 2
@


1.4
log
@none
@
text
@d1 2
a2 2
%META:TOPICINFO{author="JenniferForman" date="1111444798" format="1.0" version="1.4"}%
%META:TOPICPARENT{name="ProxyDataModel"}%
d17 2
a18 2
	* 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?
a20 1

@


1.3
log
@none
@
text
@d1 1
a1 1
%META:TOPICINFO{author="GregorHagedorn" date="1095007569" format="1.0" version="1.3"}%
d3 17
a19 17
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://efgblade.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?

@


1.2
log
@none
@
text
@d1 1
a1 1
%META:TOPICINFO{author="GregorHagedorn" date="1094661960" format="1.0" version="1.2"}%
d7 1
a7 1
Data interfaces should shield the complexity of a fuller model (i.e. the full model can be treated as a black box). It should be rough enough to fit to several models, but it also should be 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).
d9 1
a9 1
In essence, data interface are used a lot. 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://efgblade.cs.umb.edu/twiki/bin/view/UBIF/ProxyDataPublication).
d20 2
a21 1
-- Main.GregorHagedorn - 02 Sep 2004
@


1.1
log
@none
@
text
@d1 1
a1 1
%META:TOPICINFO{author="GregorHagedorn" date="1094132803" format="1.0" version="1.1"}%
d3 3
d7 1
a7 1
this discussion could fit into the UBIF space (Unified Biosciences Information Framework). 
d9 1
a9 1
I think the discussion is a bit misleading if viewed under the aspect of extensibility (start simple, then extend). This is often not easily possible. However, there is another aspect: provide a simplified interface to various (and perhaps different) complex models for each knowledge domain. 
d11 1
a11 1
When the full functionality is not needed, I often want to view the data that from my standpoint are "external" as a black box about which in 95% I do not care, but I need a relatively minimal interface.
d13 1
a13 6
I believe this interface is what we need for literature, geographical location, taxon name at least.

This is where I see DarwinCore (which essentially provides three interface - for 

Note that Specify is NOT a 
this is all we need. The problem is that
d15 1
d17 2
@