GarryJolleyRogers - Wed Nov 25 2009 - Version 1.8
Parent topic: SDD2004Berlin

FederationOfTerminology

I'll raise these points:

-- Main.BobMorris - 21 Apr 2004

I don't understand what you mean by "discoverable". To me the issue of finding or indexing a terminology resource is rather independent of being able to use it in federations. Perhaps you could clarify the points by giving an example of data elements that would have to be added to the standard if the answer is yes. If the question has no influence on the information model, we would not need to discuss it.

-- Gregor Hagedorn - 7. May 2004

Below I attach a discussion document as zipped rtf (for Word etc.) and Adobe-pdf file in which I try to sort out my thoughts on the issues involved in federating terminology. Most is provided only inside the document; I only paste the final paragraphs here:

Conclusions and Questions for SDD

1. SDD has no mechanism at the moment to define modules within the terminology of a project. Such a module mechanism is not strictly required when following the mixed template/declarative federation model. The terminology modules could simply be packaged as a dataset containing only terminology.

If we decide to introduce terminology modules, we need to think beyond characters and states (those are purposely flat and thus simple to split). How do we associate reusable concepts, concept states, modifiers, or statistical measures with modules? In fact, how is this to be done when no separate terminology module mechanism exists and multiple terminology projects are combined? Each would define its own local frequency modifiers that would be synonymous? Clearly, these should be derived from another level of standard, but how?

2. The GUID references needed in the declarative model are not yet present. They should in principle follow the resource proxy model used for objects, class names, references, etc. However, it would only use a related object linking mechanism. The ProxyBaseType would not directly form the basis of the type derivation, since this type makes some assumptions about the external object being viewed with a minimized interface (= as a black box, not knowing about the exact internal data structures). This is not appropriate when referring to external objects of types defined inside of SDD. Instead only the ID/linking mechanisms provided in the ProxyBaseType (URL, WebService, LifeScienceID) would be used in similarly structured SDD terminology proxy objects.

One reason why no placeholder type is yet present in SDD for these purposes is that I am undecided whether it is actually appropriate to place it on objects such as characters or states. I vaguely believe that we are interested in declaring identity of semantics for the purpose of data integration, which would be best defined on the level of the glossary entries. Thus two characters pointing to the same glossary entry, or rather to two glossary entries that are proxy objects of the same external term definition would be considered interoperable. In this scenario only the glossary entries themselves would have to be proxy objects with a GUID! Or do we need to refer to external character and state definitions more directly? What would be achieved by this? I look forward to a discussion on this!

Bob comments: "Ah, so your proposal is actually “ontology driven integration”. That is part of the Ph.D. research just starting of my student Hui Dong. See also the bibliography in http://www.cs.iastate.edu/~honavar/Papers/jaimethesis.pdf"

-- Gregor Hagedorn - 11. May 2004

See also IncludeMechanismsInSupportOfIntegration -- Main.BobMorris - 05 Jun 2004