GregorHagedorn - Mon May 08 2006 - Version 1.5
Parent topic: 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
a) complex data models
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.
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."
-- Gregor Hagedorn - 12 Sep 2004