239 lines
14 KiB
Plaintext
239 lines
14 KiB
Plaintext
|
head 1.8;
|
|||
|
|
access;
|
|||
|
|
symbols;
|
|||
|
|
locks; strict;
|
|||
|
|
comment @# @;
|
|||
|
|
|
|||
|
|
|
|||
|
|
1.8
|
|||
|
|
date 2009.11.25.03.14.33; author GarryJolleyRogers; state Exp;
|
|||
|
|
branches;
|
|||
|
|
next 1.7;
|
|||
|
|
|
|||
|
|
1.7
|
|||
|
|
date 2009.11.20.02.45.25; author LeeBelbin; state Exp;
|
|||
|
|
branches;
|
|||
|
|
next 1.6;
|
|||
|
|
|
|||
|
|
1.6
|
|||
|
|
date 2007.03.06.17.30.00; author TWikiGuest; state Exp;
|
|||
|
|
branches;
|
|||
|
|
next 1.5;
|
|||
|
|
|
|||
|
|
1.5
|
|||
|
|
date 2004.06.05.14.47.01; author BobMorris; state Exp;
|
|||
|
|
branches;
|
|||
|
|
next 1.4;
|
|||
|
|
|
|||
|
|
1.4
|
|||
|
|
date 2004.05.11.13.17.00; author GregorHagedorn; state Exp;
|
|||
|
|
branches;
|
|||
|
|
next 1.3;
|
|||
|
|
|
|||
|
|
1.3
|
|||
|
|
date 2004.05.07.10.05.10; author GregorHagedorn; state Exp;
|
|||
|
|
branches;
|
|||
|
|
next 1.2;
|
|||
|
|
|
|||
|
|
1.2
|
|||
|
|
date 2004.05.07.07.41.00; author GregorHagedorn; state Exp;
|
|||
|
|
branches;
|
|||
|
|
next 1.1;
|
|||
|
|
|
|||
|
|
1.1
|
|||
|
|
date 2004.04.21.19.42.43; author BobMorris; state Exp;
|
|||
|
|
branches;
|
|||
|
|
next ;
|
|||
|
|
|
|||
|
|
|
|||
|
|
desc
|
|||
|
|
@none
|
|||
|
|
@
|
|||
|
|
|
|||
|
|
|
|||
|
|
1.8
|
|||
|
|
log
|
|||
|
|
@none
|
|||
|
|
@
|
|||
|
|
text
|
|||
|
|
@%META:TOPICINFO{author="GarryJolleyRogers" date="1259118873" format="1.1" version="1.8"}%
|
|||
|
|
%META:TOPICPARENT{name="SDD2004Berlin"}%
|
|||
|
|
---+!! %TOPIC%
|
|||
|
|
|
|||
|
|
I'll raise these points:
|
|||
|
|
* Should individual characters be discoverable?
|
|||
|
|
* Should individual states be discoverable?
|
|||
|
|
* Should BDI.SDD_ support separate OWL (or other ontology languages) that allow comparisons between characters or states?
|
|||
|
|
|
|||
|
|
-- 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. BDI.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 <nop>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 BDI.SDD_. Instead only the ID/linking mechanisms provided in the <nop>ProxyBaseType (URL, <nop>WebService, <nop>LifeScienceID) would be used in similarly structured BDI.SDD_ terminology proxy objects.
|
|||
|
|
|
|||
|
|
One reason why no placeholder type is yet present in BDI.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 <20>ontology driven integration<6F>. 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
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
|
|||
|
|
%META:FILEATTACHMENT{name="D20_FedModelsDraft1.rtf.zip" attr="h" comment="" date="1083915345" path="C:\Data\Desktop\DESCR\D20_FedModelsDraft1.rtf.zip" size="173326" user="GregorHagedorn" version="1.1"}%
|
|||
|
|
%META:FILEATTACHMENT{name="D20_FedModelsDraft1.pdf" attr="h" comment="" date="1083915361" path="C:\Data\Desktop\DESCR\D20_FedModelsDraft1.pdf" size="121291" user="GregorHagedorn" version="1.1"}%
|
|||
|
|
%META:FILEATTACHMENT{name="D20_FedModelsDraft2.pdf" attr="" comment="" date="1084280947" path="C:\Data\Desktop\DESCR\D20_FedModelsDraft2.pdf" size="123591" user="GregorHagedorn" version="1.1"}%
|
|||
|
|
%META:FILEATTACHMENT{name="D20_FedModelsDraft2.rtf.zip" attr="" comment="" date="1084280967" path="C:\Data\Desktop\DESCR\D20_FedModelsDraft2.rtf.zip" size="170670" user="GregorHagedorn" version="1.1"}%
|
|||
|
|
@
|
|||
|
|
|
|||
|
|
|
|||
|
|
1.7
|
|||
|
|
log
|
|||
|
|
@none
|
|||
|
|
@
|
|||
|
|
text
|
|||
|
|
@d1 1
|
|||
|
|
a1 1
|
|||
|
|
%META:TOPICINFO{author="LeeBelbin" date="1258685125" format="1.1" reprev="1.7" version="1.7"}%
|
|||
|
|
d8 1
|
|||
|
|
a8 1
|
|||
|
|
* Should BDI.SDD support separate OWL (or other ontology languages) that allow comparisons between characters or states?
|
|||
|
|
d22 1
|
|||
|
|
a22 1
|
|||
|
|
1. BDI.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.
|
|||
|
|
d26 1
|
|||
|
|
a26 1
|
|||
|
|
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 <nop>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 BDI.SDD. Instead only the ID/linking mechanisms provided in the <nop>ProxyBaseType (URL, <nop>WebService, <nop>LifeScienceID) would be used in similarly structured BDI.SDD terminology proxy objects.
|
|||
|
|
d28 1
|
|||
|
|
a28 1
|
|||
|
|
One reason why no placeholder type is yet present in BDI.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!
|
|||
|
|
@
|
|||
|
|
|
|||
|
|
|
|||
|
|
1.6
|
|||
|
|
log
|
|||
|
|
@Added topic name via script
|
|||
|
|
@
|
|||
|
|
text
|
|||
|
|
@d1 2
|
|||
|
|
a4 2
|
|||
|
|
%META:TOPICINFO{author="BobMorris" date="1086446820" format="1.0" version="1.5"}%
|
|||
|
|
%META:TOPICPARENT{name="SDD2004Berlin"}%
|
|||
|
|
d6 3
|
|||
|
|
a8 3
|
|||
|
|
* Should individual characters be discoverable?
|
|||
|
|
* Should individual states be discoverable?
|
|||
|
|
* Should SDD support separate OWL (or other ontology languages) that allow comparisons between characters or states?
|
|||
|
|
d22 1
|
|||
|
|
a22 1
|
|||
|
|
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.
|
|||
|
|
d26 1
|
|||
|
|
a26 1
|
|||
|
|
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 <nop>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 <nop>ProxyBaseType (URL, <nop>WebService, <nop>LifeScienceID) would be used in similarly structured SDD terminology proxy objects.
|
|||
|
|
d28 1
|
|||
|
|
a28 1
|
|||
|
|
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!
|
|||
|
|
d40 1
|
|||
|
|
@
|
|||
|
|
|
|||
|
|
|
|||
|
|
1.5
|
|||
|
|
log
|
|||
|
|
@none
|
|||
|
|
@
|
|||
|
|
text
|
|||
|
|
@d1 2
|
|||
|
|
@
|
|||
|
|
|
|||
|
|
|
|||
|
|
1.4
|
|||
|
|
log
|
|||
|
|
@none
|
|||
|
|
@
|
|||
|
|
text
|
|||
|
|
@d1 1
|
|||
|
|
a1 1
|
|||
|
|
%META:TOPICINFO{author="GregorHagedorn" date="1084281420" format="1.0" version="1.4"}%
|
|||
|
|
d35 3
|
|||
|
|
@
|
|||
|
|
|
|||
|
|
|
|||
|
|
1.3
|
|||
|
|
log
|
|||
|
|
@none
|
|||
|
|
@
|
|||
|
|
text
|
|||
|
|
@d1 1
|
|||
|
|
a1 1
|
|||
|
|
%META:TOPICINFO{author="GregorHagedorn" date="1083924310" format="1.0" version="1.3"}%
|
|||
|
|
d20 1
|
|||
|
|
a20 1
|
|||
|
|
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 project containing only terminology. -- If we decided to introduce terminology modules, we think beyond characters and states (those are left purposely left and thus are simple to split). How do we associate reusable concepts 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?
|
|||
|
|
d22 1
|
|||
|
|
a22 1
|
|||
|
|
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 <nop>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. -- 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!
|
|||
|
|
d24 1
|
|||
|
|
d26 6
|
|||
|
|
a31 1
|
|||
|
|
-- Gregor Hagedorn - 7. May 2004
|
|||
|
|
d35 4
|
|||
|
|
a38 2
|
|||
|
|
%META:FILEATTACHMENT{name="D20_FedModelsDraft1.rtf.zip" attr="" comment="" date="1083915345" path="C:\Data\Desktop\DESCR\D20_FedModelsDraft1.rtf.zip" size="173326" user="GregorHagedorn" version="1.1"}%
|
|||
|
|
%META:FILEATTACHMENT{name="D20_FedModelsDraft1.pdf" attr="" comment="" date="1083915361" path="C:\Data\Desktop\DESCR\D20_FedModelsDraft1.pdf" size="121291" user="GregorHagedorn" version="1.1"}%
|
|||
|
|
@
|
|||
|
|
|
|||
|
|
|
|||
|
|
1.2
|
|||
|
|
log
|
|||
|
|
@none
|
|||
|
|
@
|
|||
|
|
text
|
|||
|
|
@d1 1
|
|||
|
|
a1 1
|
|||
|
|
%META:TOPICINFO{author="GregorHagedorn" date="1083915660" format="1.0" version="1.2"}%
|
|||
|
|
d10 4
|
|||
|
|
d16 7
|
|||
|
|
a22 1
|
|||
|
|
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.
|
|||
|
|
a23 1
|
|||
|
|
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.
|
|||
|
|
d27 2
|
|||
|
|
a28 2
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
@
|
|||
|
|
|
|||
|
|
|
|||
|
|
1.1
|
|||
|
|
log
|
|||
|
|
@none
|
|||
|
|
@
|
|||
|
|
text
|
|||
|
|
@d1 1
|
|||
|
|
a1 1
|
|||
|
|
%META:TOPICINFO{author="BobMorris" date="1082576563" format="1.0" version="1.1"}%
|
|||
|
|
a3 1
|
|||
|
|
|
|||
|
|
d6 1
|
|||
|
|
a6 2
|
|||
|
|
* Should SDD support separate OWL (or other ontology languages)that allow comparisons between characters or states?
|
|||
|
|
|
|||
|
|
d9 13
|
|||
|
|
@
|