]> S''%0a.S'%3c?xml version="1.0" encoding="ASCII"?%3e\r\n%3c!-- %3c!DOCTYPE VersavantTMA SYSTEM "http://www.versavant.org/dtds/TMAConfigFile.dtd"%3e--%3e\r\n%3c!--\r\n#####################################################################\r\n#####################################################################\r\n## Copyright 2005 Steven R. Newcomb ##\r\n## ##\r\n## This software is licensed under the Apache License, Version 2.0 ##\r\n## (the "License"); you may not use this file except in compliance ##\r\n## with the License. Copies of the License are available at ##\r\n## http://www.apache.org/licenses/LICENSE-2.0 ##\r\n## ##\r\n## Unless required by applicable law or agreed to in writing, ##\r\n## software distributed under the License is distributed on an "AS ##\r\n## IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either ##\r\n## express or implied. See the License for the specific language ##\r\n## governing permissions and limitations under the License. ##\r\n## ##\r\n## Copies of the source code and the license are available at ##\r\n## http://www.versavant.org ##\r\n#####################################################################\r\n#####################################################################\r\n--%3e\r\n%3c!DOCTYPE VersavantTMA SYSTEM "../versavantTMA.dtd"%3e\r\n%3cVersavantTMA\r\nVersavantTMADTDVersion="1"\r\n\r\n %3e%3cDesc%3eUniverse of Discourse (UoD) for EMAIL subjects.%3c/Desc\r\n\r\n %3e%3cValueType ValueTypeName="rawProxyIdList"\r\n %3e%3cDesc%3eGeneral-purpose list-of-subject-proxies value type.%3c/Desc\r\n %3e%3cValueIsNotOfType__\r\n functionModuleFilePath="${VSVEXECDIR}/Lib/VTproxyIdList.py"\r\n functionName="ValueIsNotOfType_proxyIdList_"\r\n /%3e%3cInstanceOf__ValueTypeToXMLContentString\r\n functionModuleFilePath="${VSVEXECDIR}/Lib/VTproxyIdList.py"\r\n functionName="InstanceOf_proxyIdListRaw_ValueTypeToXMLContentString"\r\n /%3e%3cXMLContentStringToInstanceOf__ValueType\r\n functionModuleFilePath="${VSVEXECDIR}/Lib/VTproxyIdList.py"\r\n functionName="XMLContentStringToInstanceOf_proxyIdListRaw_ValueType"\r\n /%3e%3c/ValueType\r\n\r\n %3e%3cValueType ValueTypeName="rawUnicodeString"\r\n %3e%3cDesc%3eGeneral-purpose Unicode string value type.%3c/Desc\r\n %3e%3cValueIsNotOfType__\r\n functionModuleFilePath="${VSVEXECDIR}/Lib/VTstring.py"\r\n functionName="ValueIsNotOfType_rawUnicodeString_"\r\n /%3e%3cInstanceOf__ValueTypeToXMLContentString\r\n functionModuleFilePath="${VSVEXECDIR}/Lib/VTstring.py"\r\n functionName="InstanceOf_rawUnicodeString_ValueTypeToXMLContentString"\r\n /%3e%3cXMLContentStringToInstanceOf__ValueType\r\n functionModuleFilePath="${VSVEXECDIR}/Lib/VTstring.py"\r\n functionName="XMLContentStringToInstanceOf_rawUnicodeString_ValueType"\r\n /%3e%3c/ValueType\r\n\r\n %3e%3cValueType ValueTypeName="rawUnicodeStringList"\r\n %3e%3cDesc%3eGeneral-purpose value type that is a list of raw Unicode strings.%3c/Desc\r\n %3e%3cValueIsNotOfType__\r\n functionModuleFilePath="${VSVEXECDIR}/Lib/VTstringList.py"\r\n functionName="ValueIsNotOfType_unicodeStringList_"\r\n /%3e%3cInstanceOf__ValueTypeToXMLContentString\r\n functionModuleFilePath="${VSVEXECDIR}/Lib/VTstringList.py"\r\n functionName="InstanceOf_rawUnicodeStringList_ValueTypeToXMLContentString"\r\n /%3e%3cXMLContentStringToInstanceOf__ValueType\r\n functionModuleFilePath="${VSVEXECDIR}/Lib/VTstringList.py"\r\n functionName="XMLContentStringToInstanceOf_rawUnicodeStringList_ValueType"\r\n /%3e%3c/ValueType\r\n\r\n %3e%3cPropertyClass PropertyClassName="personNames" ValueType="rawUnicodeStringList"\r\n %3e%3cDesc%3eSIP for persons; each item is a name for the person; if any name matches, it\'s the same subject.%3c/Desc\r\n %3e%3cAdd__PropToOverheadDict\r\n functionModuleFilePath="${VSVEXECDIR}/Lib/PCstringSet.py"\r\n functionName="Add_stringSet_anyMatch_PropToOverheadDict"\r\n /%3e%3cRemove__PropFromOverheadDict\r\n functionModuleFilePath="${VSVEXECDIR}/Lib/PCstringSet.py"\r\n functionName="Remove_stringSet_anyMatch_PropFromOverheadDict"\r\n /%3e%3cMerge__PropertyValues\r\n functionModuleFilePath="${VSVEXECDIR}/Lib/PCstringSet.py"\r\n functionName="Merge_stringSet_PropertyValues"\r\n /%3e%3cMergeProxiesBecause__PropertyInstancesSpecifySameSubject\r\n functionModuleFilePath="${VSVEXECDIR}/Lib/PCstringSet.py"\r\n functionName="MergeProxiesBecause_stringSet_anyMatch_PropertyInstancesSpecifySameSubject"\r\n /%3e%3cValuesOf__PropertyInstancesAreSignificantlyDifferent\r\n functionModuleFilePath="${VSVEXECDIR}/Lib/PCstringSet.py"\r\n functionName="ValuesOf_stringSet_PropertyInstancesAreSignificantlyDifferent"\r\n /%3e%3cProxiesWith__ValueNotSignificantlyDifferentFrom\r\n functionModuleFilePath="${VSVEXECDIR}/Lib/PCstringSet.py"\r\n functionName="ProxiesOfSubjectIdentifiedBy_stringSet_anyMatch_Value"\r\n /%3e%3c/PropertyClass\r\n\r\n %3e%3cPropertyClass PropertyClassName="emails" ValueType="rawProxyIdList"\r\n %3e%3cDesc%3eSet of emails.%3c/Desc\r\n %3e%3cAdd__PropToOverheadDict\r\n functionModuleFilePath="${VSVEXECDIR}/Lib/PCproxyIdSet.py"\r\n functionName="Add_proxyIdSet_PropToOverheadDict"\r\n /%3e%3cRemove__PropFromOverheadDict\r\n functionModuleFilePath="${VSVEXECDIR}/Lib/PCproxyIdSet.py"\r\n functionName="Remove_proxyIdSet_PropFromOverheadDict"\r\n /%3e%3cMerge__PropertyValues\r\n functionModuleFilePath="${VSVEXECDIR}/Lib/PCproxyIdSet.py"\r\n functionName="Merge_accumulatingProxyIdSet_PropertyValues"\r\n /%3e%3cValuesOf__PropertyInstancesAreSignificantlyDifferent\r\n functionModuleFilePath="${VSVEXECDIR}/Lib/PCproxyIdSet.py"\r\n functionName="ValuesOf_proxyIdSet_PropertyInstancesAreSignificantlyDifferent"\r\n /%3e%3cProxiesWith__ValueNotSignificantlyDifferentFrom\r\n functionModuleFilePath="${VSVEXECDIR}/Lib/PCproxyIdSet.py"\r\n functionName="ProxiesOfSubjectIdentifiedBy_proxyIdSet_Value"\r\n /%3e%3cUpdateProxyReferencesIn__Value\r\n functionModuleFilePath="${VSVEXECDIR}/Lib/PCproxyIdSet.py"\r\n functionName="UpdateProxyReferencesIn_proxyIdSet_Value"\r\n /%3e%3c/PropertyClass\r\n\r\n %3e%3cPropertyClass PropertyClassName="emailSubjectLines" ValueType="rawProxyIdList"\r\n %3e%3cDesc%3eSet of email subject lines.%3c/Desc\r\n %3e%3cAdd__PropToOverheadDict\r\n functionModuleFilePath="${VSVEXECDIR}/Lib/PCproxyIdSet.py"\r\n functionName="Add_proxyIdSet_PropToOverheadDict"\r\n /%3e%3cRemove__PropFromOverheadDict\r\n functionModuleFilePath="${VSVEXECDIR}/Lib/PCproxyIdSet.py"\r\n functionName="Remove_proxyIdSet_PropFromOverheadDict"\r\n /%3e%3cMerge__PropertyValues\r\n functionModuleFilePath="${VSVEXECDIR}/Lib/PCproxyIdSet.py"\r\n functionName="Merge_accumulatingProxyIdSet_PropertyValues"\r\n /%3e%3cValuesOf__PropertyInstancesAreSignificantlyDifferent\r\n functionModuleFilePath="${VSVEXECDIR}/Lib/PCproxyIdSet.py"\r\n functionName="ValuesOf_proxyIdSet_PropertyInstancesAreSignificantlyDifferent"\r\n /%3e%3cProxiesWith__ValueNotSignificantlyDifferentFrom\r\n functionModuleFilePath="${VSVEXECDIR}/Lib/PCproxyIdSet.py"\r\n functionName="ProxiesOfSubjectIdentifiedBy_proxyIdSet_Value"\r\n /%3e%3cUpdateProxyReferencesIn__Value\r\n functionModuleFilePath="${VSVEXECDIR}/Lib/PCproxyIdSet.py"\r\n functionName="UpdateProxyReferencesIn_proxyIdSet_Value"\r\n /%3e%3c/PropertyClass\r\n\r\n %3e%3cPropertyClass PropertyClassName="emailID" ValueType="rawUnicodeString"\r\n %3e%3cDesc%3eSIP for emails; values are email "Message-ID:s".%3c/Desc\r\n %3e%3cAdd__PropToOverheadDict\r\n functionModuleFilePath="${VSVEXECDIR}/Lib/PCstring.py"\r\n functionName="Add_string_PropToOverheadDict"\r\n /%3e%3cRemove__PropFromOverheadDict\r\n functionModuleFilePath="${VSVEXECDIR}/Lib/PCstring.py"\r\n functionName="Remove_string_PropFromOverheadDict"\r\n /%3e%3cMerge__PropertyValues\r\n functionModuleFilePath="${VSVEXECDIR}/Lib/PCstring.py"\r\n functionName="Merge_string_PropertyValues"\r\n /%3e%3cMergeProxiesBecause__PropertyInstancesSpecifySameSubject\r\n functionModuleFilePath="${VSVEXECDIR}/Lib/PCstring.py"\r\n functionName="MergeProxiesBecause_string_PropertyInstancesSpecifySameSubject"\r\n /%3e%3cValuesOf__PropertyInstancesAreSignificantlyDifferent\r\n functionModuleFilePath="${VSVEXECDIR}/Lib/PCstring.py"\r\n functionName="ValuesOf_string_PropertyInstancesAreSignificantlyDifferent"\r\n /%3e%3cProxiesWith__ValueNotSignificantlyDifferentFrom\r\n functionModuleFilePath="${VSVEXECDIR}/Lib/PCstring.py"\r\n functionName="ProxiesOfSubjectIdentifiedBy_string_Value"\r\n /%3e%3c/PropertyClass\r\n\r\n %3e%3cPropertyClass PropertyClassName="sender" ValueType="rawProxyIdList"\r\n %3e%3cDesc%3eReference to a sender (a person) of an email.%3c/Desc\r\n %3e%3cAdd__PropToOverheadDict\r\n functionModuleFilePath="${VSVEXECDIR}/Lib/PCproxyIdSet.py"\r\n functionName="Add_proxyIdSet_PropToOverheadDict"\r\n /%3e%3cRemove__PropFromOverheadDict\r\n functionModuleFilePath="${VSVEXECDIR}/Lib/PCproxyIdSet.py"\r\n functionName="Remove_proxyIdSet_PropFromOverheadDict"\r\n /%3e%3cMerge__PropertyValues\r\n functionModuleFilePath="${VSVEXECDIR}/Lib/PCproxyIdSet.py"\r\n functionName="Merge_proxyIdSet_PropertyValues"\r\n /%3e%3cValuesOf__PropertyInstancesAreSignificantlyDifferent\r\n functionModuleFilePath="${VSVEXECDIR}/Lib/PCproxyIdSet.py"\r\n functionName="ValuesOf_proxyIdSet_PropertyInstancesAreSignificantlyDifferent"\r\n /%3e%3cProxiesWith__ValueNotSignificantlyDifferentFrom\r\n functionModuleFilePath="${VSVEXECDIR}/Lib/PCproxyIdSet.py"\r\n functionName="ProxiesOfSubjectIdentifiedBy_proxyIdSet_Value"\r\n /%3e%3cUpdateProxyReferencesIn__Value\r\n functionModuleFilePath="${VSVEXECDIR}/Lib/PCproxyIdSet.py"\r\n functionName="UpdateProxyReferencesIn_proxyIdSet_Value"\r\n /%3e%3c/PropertyClass\r\n\r\n %3e%3cPropertyClass PropertyClassName="subjectLine" ValueType="rawProxyIdList"\r\n %3e%3cDesc%3eReference to proxy for a subject line.%3c/Desc\r\n %3e%3cAdd__PropToOverheadDict\r\n functionModuleFilePath="${VSVEXECDIR}/Lib/PCproxyIdSet.py"\r\n functionName="Add_proxyIdSet_PropToOverheadDict"\r\n /%3e%3cRemove__PropFromOverheadDict\r\n functionModuleFilePath="${VSVEXECDIR}/Lib/PCproxyIdSet.py"\r\n functionName="Remove_proxyIdSet_PropFromOverheadDict"\r\n /%3e%3cMerge__PropertyValues\r\n functionModuleFilePath="${VSVEXECDIR}/Lib/PCproxyIdSet.py"\r\n functionName="Merge_accumulatingProxyIdSet_PropertyValues"\r\n /%3e%3cValuesOf__PropertyInstancesAreSignificantlyDifferent\r\n functionModuleFilePath="${VSVEXECDIR}/Lib/PCproxyIdSet.py"\r\n functionName="ValuesOf_proxyIdSet_PropertyInstancesAreSignificantlyDifferent"\r\n /%3e%3cProxiesWith__ValueNotSignificantlyDifferentFrom\r\n functionModuleFilePath="${VSVEXECDIR}/Lib/PCproxyIdSet.py"\r\n functionName="ProxiesOfSubjectIdentifiedBy_proxyIdSet_Value"\r\n /%3e%3cUpdateProxyReferencesIn__Value\r\n functionModuleFilePath="${VSVEXECDIR}/Lib/PCproxyIdSet.py"\r\n functionName="UpdateProxyReferencesIn_proxyIdSet_Value"\r\n /%3e%3c/PropertyClass\r\n\r\n %3e%3cPropertyClass PropertyClassName="inReplyTo" ValueType="rawProxyIdList"\r\n %3e%3cDesc%3eReference to the email, if any, to which this email is a reply.%3c/Desc\r\n %3e%3cAdd__PropToOverheadDict\r\n functionModuleFilePath="${VSVEXECDIR}/Lib/PCproxyIdSet.py"\r\n functionName="Add_proxyIdSet_PropToOverheadDict"\r\n /%3e%3cRemove__PropFromOverheadDict\r\n functionModuleFilePath="${VSVEXECDIR}/Lib/PCproxyIdSet.py"\r\n functionName="Remove_proxyIdSet_PropFromOverheadDict"\r\n /%3e%3cMerge__PropertyValues\r\n functionModuleFilePath="${VSVEXECDIR}/Lib/PCproxyIdSet.py"\r\n functionName="Merge_proxyIdSet_PropertyValues"\r\n /%3e%3cValuesOf__PropertyInstancesAreSignificantlyDifferent\r\n functionModuleFilePath="${VSVEXECDIR}/Lib/PCproxyIdSet.py"\r\n functionName="ValuesOf_proxyIdSet_PropertyInstancesAreSignificantlyDifferent"\r\n /%3e%3cProxiesWith__ValueNotSignificantlyDifferentFrom\r\n functionModuleFilePath="${VSVEXECDIR}/Lib/PCproxyIdSet.py"\r\n functionName="ProxiesOfSubjectIdentifiedBy_proxyIdSet_Value"\r\n /%3e%3cUpdateProxyReferencesIn__Value\r\n functionModuleFilePath="${VSVEXECDIR}/Lib/PCproxyIdSet.py"\r\n functionName="UpdateProxyReferencesIn_proxyIdSet_Value"\r\n /%3e%3c/PropertyClass\r\n\r\n %3e%3cPropertyClass PropertyClassName="previousInThread" ValueType="rawProxyIdList"\r\n %3e%3cDesc%3eReference to the email that appears previous to this one in the same thread, if any.%3c/Desc\r\n %3e%3cAdd__PropToOverheadDict\r\n functionModuleFilePath="${VSVEXECDIR}/Lib/PCproxyIdSet.py"\r\n functionName="Add_proxyIdSet_PropToOverheadDict"\r\n /%3e%3cRemove__PropFromOverheadDict\r\n functionModuleFilePath="${VSVEXECDIR}/Lib/PCproxyIdSet.py"\r\n functionName="Remove_proxyIdSet_PropFromOverheadDict"\r\n /%3e%3cMerge__PropertyValues\r\n functionModuleFilePath="${VSVEXECDIR}/Lib/PCproxyIdSet.py"\r\n functionName="Merge_proxyIdSet_PropertyValues"\r\n /%3e%3cValuesOf__PropertyInstancesAreSignificantlyDifferent\r\n functionModuleFilePath="${VSVEXECDIR}/Lib/PCproxyIdSet.py"\r\n functionName="ValuesOf_proxyIdSet_PropertyInstancesAreSignificantlyDifferent"\r\n /%3e%3cProxiesWith__ValueNotSignificantlyDifferentFrom\r\n functionModuleFilePath="${VSVEXECDIR}/Lib/PCproxyIdSet.py"\r\n functionName="ProxiesOfSubjectIdentifiedBy_proxyIdSet_Value"\r\n /%3e%3cUpdateProxyReferencesIn__Value\r\n functionModuleFilePath="${VSVEXECDIR}/Lib/PCproxyIdSet.py"\r\n functionName="UpdateProxyReferencesIn_proxyIdSet_Value"\r\n /%3e%3c/PropertyClass\r\n\r\n %3e%3cPropertyClass PropertyClassName="nextInThread" ValueType="rawProxyIdList"\r\n %3e%3cDesc%3eReference to the email that appears next in the same thread, if any.%3c/Desc\r\n %3e%3cAdd__PropToOverheadDict\r\n functionModuleFilePath="${VSVEXECDIR}/Lib/PCproxyIdSet.py"\r\n functionName="Add_proxyIdSet_PropToOverheadDict"\r\n /%3e%3cRemove__PropFromOverheadDict\r\n functionModuleFilePath="${VSVEXECDIR}/Lib/PCproxyIdSet.py"\r\n functionName="Remove_proxyIdSet_PropFromOverheadDict"\r\n /%3e%3cMerge__PropertyValues\r\n functionModuleFilePath="${VSVEXECDIR}/Lib/PCproxyIdSet.py"\r\n functionName="Merge_proxyIdSet_PropertyValues"\r\n /%3e%3cValuesOf__PropertyInstancesAreSignificantlyDifferent\r\n functionModuleFilePath="${VSVEXECDIR}/Lib/PCproxyIdSet.py"\r\n functionName="ValuesOf_proxyIdSet_PropertyInstancesAreSignificantlyDifferent"\r\n /%3e%3cProxiesWith__ValueNotSignificantlyDifferentFrom\r\n functionModuleFilePath="${VSVEXECDIR}/Lib/PCproxyIdSet.py"\r\n functionName="ProxiesOfSubjectIdentifiedBy_proxyIdSet_Value"\r\n /%3e%3cUpdateProxyReferencesIn__Value\r\n functionModuleFilePath="${VSVEXECDIR}/Lib/PCproxyIdSet.py"\r\n functionName="UpdateProxyReferencesIn_proxyIdSet_Value"\r\n /%3e%3c/PropertyClass\r\n\r\n %3e%3cPropertyClass PropertyClassName="threadStart" ValueType="rawProxyIdList"\r\n %3e%3cDesc%3eReference to the email starting this thread, if not the same as this email.%3c/Desc\r\n %3e%3cAdd__PropToOverheadDict\r\n functionModuleFilePath="${VSVEXECDIR}/Lib/PCproxyIdSet.py"\r\n functionName="Add_proxyIdSet_PropToOverheadDict"\r\n /%3e%3cRemove__PropFromOverheadDict\r\n functionModuleFilePath="${VSVEXECDIR}/Lib/PCproxyIdSet.py"\r\n functionName="Remove_proxyIdSet_PropFromOverheadDict"\r\n /%3e%3cMerge__PropertyValues\r\n functionModuleFilePath="${VSVEXECDIR}/Lib/PCproxyIdSet.py"\r\n functionName="Merge_proxyIdSet_PropertyValues"\r\n /%3e%3cValuesOf__PropertyInstancesAreSignificantlyDifferent\r\n functionModuleFilePath="${VSVEXECDIR}/Lib/PCproxyIdSet.py"\r\n functionName="ValuesOf_proxyIdSet_PropertyInstancesAreSignificantlyDifferent"\r\n /%3e%3cProxiesWith__ValueNotSignificantlyDifferentFrom\r\n functionModuleFilePath="${VSVEXECDIR}/Lib/PCproxyIdSet.py"\r\n functionName="ProxiesOfSubjectIdentifiedBy_proxyIdSet_Value"\r\n /%3e%3cUpdateProxyReferencesIn__Value\r\n functionModuleFilePath="${VSVEXECDIR}/Lib/PCproxyIdSet.py"\r\n functionName="UpdateProxyReferencesIn_proxyIdSet_Value"\r\n /%3e%3c/PropertyClass\r\n\r\n %3e%3cPropertyClass PropertyClassName="content" ValueType="rawUnicodeString"\r\n %3e%3cDesc%3eEntire content of email.%3c/Desc\r\n %3e%3cAdd__PropToOverheadDict\r\n functionModuleFilePath="${VSVEXECDIR}/Lib/PCstring.py"\r\n functionName="Add_string_PropToOverheadDict"\r\n /%3e%3cRemove__PropFromOverheadDict\r\n functionModuleFilePath="${VSVEXECDIR}/Lib/PCstring.py"\r\n functionName="Remove_string_PropFromOverheadDict"\r\n /%3e%3cMerge__PropertyValues\r\n functionModuleFilePath="${VSVEXECDIR}/Lib/PCstring.py"\r\n functionName="BOGUS_Merge_string_PropertyValues"\r\n /%3e%3cValuesOf__PropertyInstancesAreSignificantlyDifferent\r\n functionModuleFilePath="${VSVEXECDIR}/Lib/PCstring.py"\r\n functionName="ValuesOf_string_PropertyInstancesAreSignificantlyDifferent"\r\n /%3e%3cProxiesWith__ValueNotSignificantlyDifferentFrom\r\n functionModuleFilePath="${VSVEXECDIR}/Lib/PCstring.py"\r\n functionName="ProxiesOfSubjectIdentifiedBy_string_Value"\r\n /%3e%3c/PropertyClass\r\n\r\n %3e%3cPropertyClass PropertyClassName="date" ValueType="rawUnicodeString"\r\n %3e%3cDesc%3eSIP for dates; values are date strings normalized to YYYY/MM/DD.%3c/Desc\r\n %3e%3cAdd__PropToOverheadDict\r\n functionModuleFilePath="${VSVEXECDIR}/Lib/PCstring.py"\r\n functionName="Add_string_PropToOverheadDict"\r\n /%3e%3cRemove__PropFromOverheadDict\r\n functionModuleFilePath="${VSVEXECDIR}/Lib/PCstring.py"\r\n functionName="Remove_string_PropFromOverheadDict"\r\n /%3e%3cMerge__PropertyValues\r\n functionModuleFilePath="${VSVEXECDIR}/Lib/PCstring.py"\r\n functionName="Merge_string_PropertyValues"\r\n /%3e%3cMergeProxiesBecause__PropertyInstancesSpecifySameSubject\r\n functionModuleFilePath="${VSVEXECDIR}/Lib/PCstring.py"\r\n functionName="MergeProxiesBecause_string_PropertyInstancesSpecifySameSubject"\r\n /%3e%3cValuesOf__PropertyInstancesAreSignificantlyDifferent\r\n functionModuleFilePath="${VSVEXECDIR}/Lib/PCstring.py"\r\n functionName="ValuesOf_string_PropertyInstancesAreSignificantlyDifferent"\r\n /%3e%3cProxiesWith__ValueNotSignificantlyDifferentFrom\r\n functionModuleFilePath="${VSVEXECDIR}/Lib/PCstring.py"\r\n functionName="ProxiesOfSubjectIdentifiedBy_string_Value"\r\n /%3e%3c/PropertyClass\r\n\r\n %3e%3cPropertyClass PropertyClassName="firstEmail" ValueType="rawProxyIdList"\r\n %3e%3cDesc%3eSIP for threads; value is a reference to the proxy for the first email in the thread.%3c/Desc\r\n %3e%3cAdd__PropToOverheadDict\r\n functionModuleFilePath="${VSVEXECDIR}/Lib/PCproxyIdSet.py"\r\n functionName="Add_proxyIdSet_PropToOverheadDict"\r\n /%3e%3cRemove__PropFromOverheadDict\r\n functionModuleFilePath="${VSVEXECDIR}/Lib/PCproxyIdSet.py"\r\n functionName="Remove_proxyIdSet_PropFromOverheadDict"\r\n /%3e%3cMerge__PropertyValues\r\n functionModuleFilePath="${VSVEXECDIR}/Lib/PCproxyIdSet.py"\r\n functionName="Merge_proxyIdSet_PropertyValues"\r\n /%3e%3cMergeProxiesBecause__PropertyInstancesSpecifySameSubject\r\n functionModuleFilePath="${VSVEXECDIR}/Lib/PCproxyIdSet.py"\r\n functionName="MergeProxiesBecause_proxyIdSet_PropertyInstancesSpecifySameSubject"\r\n /%3e%3cValuesOf__PropertyInstancesAreSignificantlyDifferent\r\n functionModuleFilePath="${VSVEXECDIR}/Lib/PCproxyIdSet.py"\r\n functionName="ValuesOf_proxyIdSet_PropertyInstancesAreSignificantlyDifferent"\r\n /%3e%3cProxiesWith__ValueNotSignificantlyDifferentFrom\r\n functionModuleFilePath="${VSVEXECDIR}/Lib/PCproxyIdSet.py"\r\n functionName="ProxiesOfSubjectIdentifiedBy_proxyIdSet_Value"\r\n /%3e%3cUpdateProxyReferencesIn__Value\r\n functionModuleFilePath="${VSVEXECDIR}/Lib/PCproxyIdSet.py"\r\n functionName="UpdateProxyReferencesIn_proxyIdSet_Value"\r\n /%3e%3c/PropertyClass\r\n\r\n%3e%3c/VersavantTMA%3e\r\n'%0ap1%0a.S'#####################################################################\r\n#####################################################################\r\n## Copyright 2005 Steven R. Newcomb ##\r\n## ##\r\n## This software is licensed under the Apache License, Version 2.0 ##\r\n## (the "License"); you may not use this file except in compliance ##\r\n## with the License. Copies of the License are available at ##\r\n## http://www.apache.org/licenses/LICENSE-2.0 ##\r\n## ##\r\n## Unless required by applicable law or agreed to in writing, ##\r\n## software distributed under the License is distributed on an "AS ##\r\n## IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either ##\r\n## express or implied. See the License for the specific language ##\r\n## governing permissions and limitations under the License. ##\r\n## ##\r\n## Copies of the source code and the license are available at ##\r\n## http://www.versavant.org ##\r\n#####################################################################\r\n#####################################################################\r\n\r\n####################################\r\ncvsRevision = "$Revision: 1.8 $" ##\r\n####################################\r\n\r\n\r\nimport sys, pdb\r\n\r\n\r\n#######################################\r\n## proxyIdSet PC implementation ##\r\n#######################################\r\n\r\n## These functions are useful as implementations of SIPs or OPs whose\r\n## values are lists of references to proxies. Obviously, the name\r\n## "proxyIdSet" only applies to these (library) functions; TMA\r\n## designers can use any name(s) for such properties.\r\n\r\n#######################################################\r\ndef Add_proxyIdSet_PropToOverheadDict( vsv, propertyInstance, overheadDict, proxyIdMap):\r\n\r\n if proxyIdMap:\r\n value = %5b%5d\r\n for proxyId in propertyInstance._value:\r\n value.append( proxyIdMap%5b proxyId%5d)\r\n propertyInstance._value = value\r\n\r\n workDict = {}\r\n for proxyId in propertyInstance._value:\r\n workDict%5b proxyId%5d = None\r\n propertyInstance.listOfIdsOfReferencedProxies = propertyInstance._value = workDict.keys()\r\n\r\n hashablePropertyValue = propertyInstance.hashablePropertyValue = frozenset( propertyInstance._value)\r\n\r\n if overheadDict.has_key( hashablePropertyValue):\r\n if overheadDict%5b hashablePropertyValue%5d.has_key( propertyInstance.proxyId):\r\n vsv.errMsg( \'ProxyId %25s is already listed in the overheadDict of property class for the value (%25s)\' %25 (\r\n propertyInstance.proxyId, propertyInstance._value))\r\n sys.exit( 1)\r\n overheadDict%5b hashablePropertyValue%5d%5b propertyInstance.proxyId%5d = None\r\n else:\r\n overheadDict%5b hashablePropertyValue%5d = { propertyInstance.proxyId: None}\r\n\r\n vsv.addNewProxyReferencesToReferencedProxiesDict( propertyInstance)\r\n\r\n#######################################################\r\ndef Remove_proxyIdSet_PropFromOverheadDict( vsv, propertyInstance, overheadDict):\r\n hashablePropertyValue = propertyInstance.hashablePropertyValue\r\n if not overheadDict.has_key( hashablePropertyValue):\r\n vsv.errMsg( \'No entry in overheadDict of property class for the value (%25s) of property %25s\' %25 (\r\n propertyInstance._value,\r\n vsv.catKey( propertyInstance.topicMap.topicMapName, propertyInstance.propertyInstanceKey)))\r\n sys.exit( 1)\r\n if propertyInstance.proxyId not in overheadDict%5b hashablePropertyValue%5d:\r\n vsv.errMsg( \'ProxyId %25s not found in the overheadDict of property class for the value (%25s) of property %25s\' %25 (\r\n propertyInstance.proxyId,\r\n propertyInstance._value,\r\n vsv.catKey( propertyInstance.topicMap.topicMapName, propertyInstance.propertyInstanceKey)))\r\n sys.exit( 1)\r\n\r\n del overheadDict%5b hashablePropertyValue%5d%5b propertyInstance.proxyId%5d\r\n if not len( overheadDict%5b hashablePropertyValue%5d):\r\n del overheadDict%5b hashablePropertyValue%5d\r\n\r\n vsv.removeOldProxyReferencesFromReferencedProxiesDict( propertyInstance)\r\n\r\n#######################################################\r\ndef ValueIsInvalidFor_proxyIdSet_Property( vsv, propertyValue, propertyClass, propertyInstance = None):\r\n ## the value type validator does everything necessary\r\n return False\r\n\r\n#######################################################\r\ndef Merge_proxyIdSet_PropertyValues( vsv, value1, value2):\r\n if value1 == value2:\r\n return value1\r\n else:\r\n return None ## merge is unsuccessful\r\n\r\n#######################################################\r\ndef Merge_accumulatingProxyIdSet_PropertyValues( vsv, value1, value2):\r\n wkdict = {}\r\n for proxyId in value1:\r\n wkdict%5b proxyId%5d = None\r\n for proxyId in value2:\r\n wkdict%5b proxyId%5d = None\r\n return wkdict.keys()\r\n\r\n#######################################################\r\ndef ValuesOf_proxyIdSet_PropertyInstancesAreSignificantlyDifferent( vsv, value1, value2):\r\n if frozenset( value1) != frozenset( value2): ## ignore differences in sequence and ignore redundant entries\r\n return True\r\n return False\r\n\r\n#######################################################\r\ndef MergeProxiesBecause_proxyIdSet_PropertyInstancesSpecifySameSubject( vsv, propertyClass):\r\n for key in propertyClass.overheadDict:\r\n if len( propertyClass.overheadDict%5b key%5d) %3e 1:\r\n vsv.mergeListOfProxies( propertyClass, key, propertyClass.overheadDict%5b key%5d.keys())\r\n\r\n#######################################################\r\ndef ProxiesOfSubjectIdentifiedBy_proxyIdSet_Value( vsv, propertyClass, value):\r\n hashablePropertyValue = frozenset( value)\r\n if propertyClass.overheadDict.has_key( hashablePropertyValue):\r\n return propertyClass.overheadDict%5b hashablePropertyValue%5d.keys()\r\n else:\r\n return %5b%5d ## empty list -- no match\r\n\r\n#######################################################\r\ndef UpdateProxyReferencesIn_proxyIdSet_Value( vsv, propertyInstance, proxyIdToReplace, replacementProxyId):\r\n value = propertyInstance._value\r\n if proxyIdToReplace not in value:\r\n vsv.errMsg( \'proxyIdToReplace "%25s" not found in the value of %25s\' %25 (\r\n proxyIdToReplace,\r\n vsv.catKey( propertyInstance.topicMap.topicMapName, propertyInstance.propertyInstanceKey)))\r\n sys.exit( 1)\r\n\r\n propertyClass = propertyInstance.propertyClass\r\n \r\n\r\n ## Remove old value from the "overhead" data for this property class\r\n if propertyClass.Remove__PropFromOverheadDictFArgString:\r\n execStr = \'propertyClass.Remove__PropFromOverheadDictF( vsv, propertyInstance, propertyClass.overheadDict, %25s)\' %25 (\r\n propertyClass.Remove__PropFromOverheadDictFArgString)\r\n exec execStr\r\n else:\r\n propertyClass.Remove__PropFromOverheadDictF( vsv, propertyInstance, propertyClass.overheadDict)\r\n\r\n ## Replace the proxyIdToReplace with the replacementProxyId\r\n oldValue = value%5b:%5d\r\n del value%5b:%5d\r\n for proxyId in oldValue:\r\n if proxyId == proxyIdToReplace:\r\n proxyId = replacementProxyId\r\n if proxyId not in value:\r\n value.append( proxyId)\r\n \r\n ## Expose the list of proxy references that appear in the value as a list of proxyIds\r\n propertyInstance.listOfIdsOfReferencedProxies = value\r\n ## happens to be a list, so use the same list\r\n\r\n\r\n ## Add new value to the "overhead" data for this property class\r\n if propertyClass.Add__PropToOverheadDictFArgString:\r\n execStr = \'propertyClass.Add__PropToOverheadDictF( vsv, propertyInstance, propertyClass.overheadDict, None, %25s)\' %25 (\r\n propertyClass.Add__PropToOverheadDictFArgString)\r\n exec execStr\r\n else:\r\n propertyClass.Add__PropToOverheadDictF( vsv, propertyInstance, propertyClass.overheadDict, None)\r\n\r\n'%0ap1%0a.S'#####################################################################\r\n#####################################################################\r\n## Versavant Topic Map Application Bus / Subject Addressing Engine ##\r\n## Copyright 2005 Steven R. Newcomb ##\r\n## ##\r\n## This software is licensed under the Apache License, Version 2.0 ##\r\n## (the "License"); you may not use this file except in compliance ##\r\n## with the License. Copies of the License are available at ##\r\n## http://www.apache.org/licenses/LICENSE-2.0 ##\r\n## ##\r\n## Unless required by applicable law or agreed to in writing, ##\r\n## software distributed under the License is distributed on an "AS ##\r\n## IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either ##\r\n## express or implied. See the License for the specific language ##\r\n## governing permissions and limitations under the License. ##\r\n## ##\r\n## Copies of the source code and the license are available at ##\r\n## http://www.versavant.org ##\r\n#####################################################################\r\n#####################################################################\r\n\r\n####################################\r\ncvsRevision = "$Revision: 1.9 $" ##\r\n####################################\r\n\r\n######################################################################################\r\n## A simple property class implementation for properties whose values are strings. ##\r\n######################################################################################\r\n\r\n#######################################################\r\ndef Add_string_PropToOverheadDict( vsv, propertyInstance, overheadDict, proxyIdMap):\r\n valueHash = propertyInstance.hashablePropertyValue = propertyInstance._value\r\n if overheadDict.has_key( valueHash):\r\n overheadDict%5b valueHash%5d.append( propertyInstance.proxyId)\r\n else:\r\n overheadDict%5b valueHash%5d = %5b propertyInstance.proxyId%5d\r\n\r\n\r\n#######################################################\r\ndef Remove_string_PropFromOverheadDict( vsv, propertyInstance, overheadDict):\r\n valueHash = propertyInstance.hashablePropertyValue\r\n overheadDict%5b valueHash%5d.remove( propertyInstance.proxyId)\r\n if not len( overheadDict%5b valueHash%5d):\r\n del overheadDict%5b valueHash%5d ## be a good citizen and clean up after yourself\r\n\r\n\r\n#######################################################\r\ndef Merge_string_PropertyValues( vsv, value1, value2):\r\n if value1 == value2:\r\n return value1\r\n else:\r\n return None ## the merge failed.\r\n\r\n#######################################################\r\ndef BOGUS_Merge_string_PropertyValues( vsv, value1, value2):\r\n return value1\r\n\r\n#######################################################\r\ndef ValuesOf_string_PropertyInstancesAreSignificantlyDifferent( vsv, value1, value2):\r\n if value1 == value2:\r\n return False\r\n else:\r\n return True \r\n\r\n#######################################################\r\ndef ProxiesOfSubjectIdentifiedBy_string_Value( vsv, propertyClass, value):\r\n if propertyClass.overheadDict.has_key( value):\r\n return propertyClass.overheadDict%5b value%5d\r\n else:\r\n return %5b%5d ## empty list -- no match\r\n\r\n#######################################################\r\ndef MergeProxiesBecause_string_PropertyInstancesSpecifySameSubject( vsv, propertyClass):\r\n ## Declare this one if and only if your property class is for SIPs\r\n ## (subject identity properties).\r\n\r\n for hashablePropertyValue in propertyClass.overheadDict:\r\n if len( propertyClass.overheadDict%5b hashablePropertyValue%5d) %3e 1:\r\n vsv.mergeListOfProxies( propertyClass, hashablePropertyValue, propertyClass.overheadDict%5b hashablePropertyValue%5d)\r\n \r\n'%0ap1%0a.S'#####################################################################\r\n#####################################################################\r\n## Versavant Topic Map Application Bus / Subject Addressing Engine ##\r\n## Copyright 2005 Steven R. Newcomb ##\r\n## ##\r\n## This software is licensed under the Apache License, Version 2.0 ##\r\n## (the "License"); you may not use this file except in compliance ##\r\n## with the License. Copies of the License are available at ##\r\n## http://www.apache.org/licenses/LICENSE-2.0 ##\r\n## ##\r\n## Unless required by applicable law or agreed to in writing, ##\r\n## software distributed under the License is distributed on an "AS ##\r\n## IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either ##\r\n## express or implied. See the License for the specific language ##\r\n## governing permissions and limitations under the License. ##\r\n## ##\r\n## Copies of the source code and the license are available at ##\r\n## http://www.versavant.org ##\r\n#####################################################################\r\n#####################################################################\r\n\r\n####################################\r\ncvsRevision = "$Revision: 1.8 $" ##\r\n####################################\r\n\r\n#######################################################################\r\n## This property class assumes a value type of lists whose items are ##\r\n## strings. However, they are treated as a set, not a list; their ##\r\n## order is not significant and redundant items will be ignored. ##\r\n## The value type implementation found in ##\r\n## versavant/Lib/VTstringSet.py can be used. ##\r\n## ##\r\n## * Subject sameness is having all the same items in both values. ##\r\n## ##\r\n## * If you desire any two values to be regarded as having the same ##\r\n## subject if they have one or more items in common, use the ##\r\n## variant functions with "anyMatch" in their names. ##\r\n#######################################################################\r\n\r\n###\r\nimport pdb, traceback\r\n###\r\n\r\n#######################################################\r\n## Subject sameness is sameness of the whole sets:\r\ndef Add_stringSet_PropToOverheadDict( vsv, propertyInstance, overheadDict, proxyIdMap):\r\n hashableValue = propertyInstance.hashablePropertyValue = frozenset( propertyInstance._value)\r\n if overheadDict.has_key( hashableValue):\r\n overheadDict%5b hashableValue%5d.append( propertyInstance.proxyId)\r\n else:\r\n overheadDict%5b hashableValue%5d = %5b propertyInstance.proxyId%5d\r\n\r\n#######################################################\r\n## Subject sameness is sameness of any item in the sets (intersection of sets is non-empty):\r\ndef Add_stringSet_anyMatch_PropToOverheadDict( vsv, propertyInstance, overheadDict, proxyIdMap):\r\n\r\n value = propertyInstance._value\r\n for item in value:\r\n if overheadDict.has_key( item):\r\n overheadDict%5b item%5d.append( propertyInstance.proxyId)\r\n else:\r\n overheadDict%5b item%5d = %5b propertyInstance.proxyId%5d\r\n\r\n\r\n#######################################################\r\ndef Remove_stringSet_PropFromOverheadDict( vsv, propertyInstance, overheadDict):\r\n## Subject sameness is sameness of the whole sets:\r\n hashableValue = propertyInstance.hashablePropertyValue\r\n overheadDict%5b hashableValue%5d.remove( propertyInstance.proxyId)\r\n if not len( overheadDict%5b hashableValue%5d):\r\n del overheadDict%5b hashableValue%5d\r\n\r\n#######################################################\r\ndef Remove_stringSet_anyMatch_PropFromOverheadDict( vsv, propertyInstance, overheadDict):\r\n## Subject sameness is sameness of any item in the sets (intersection of sets is non-empty):\r\n\r\n value = propertyInstance._value\r\n for item in value:\r\n try: ## because this is an anymatch situation, it may already have been removed.\r\n overheadDict%5b item%5d.remove( propertyInstance.proxyId)\r\n except:\r\n pass\r\n try:\r\n if not len( overheadDict%5b item%5d):\r\n try:\r\n del overheadDict%5b item%5d\r\n except:\r\n pass\r\n except:\r\n pass\r\n\r\n#######################################################\r\n## This works either way.\r\ndef Merge_stringSet_PropertyValues( vsv, value1, value2):\r\n newList = %5b%5d\r\n for stringItem in value1:\r\n if stringItem not in newList:\r\n newList.append( stringItem)\r\n for stringItem in value2:\r\n if stringItem not in newList:\r\n newList.append( stringItem)\r\n return newList\r\n\r\n#######################################################\r\n## This works either way.\r\ndef ValuesOf_stringSet_PropertyInstancesAreSignificantlyDifferent( vsv, value1, value2):\r\n if frozenset( value1) == frozenset( value2):\r\n return False\r\n else:\r\n return True \r\n\r\n#######################################################\r\ndef ProxiesOfSubjectIdentifiedBy_stringSet_Value( vsv, propertyClass, value):\r\n## Subject sameness is sameness of the whole set:\r\n fset = frozenset( value)\r\n if propertyClass.overheadDict.has_key( fset):\r\n return propertyClass.overheadDict%5b fset%5d\r\n else:\r\n return %5b%5d ## empty list -- no match\r\n\r\n#######################################################\r\ndef ProxiesOfSubjectIdentifiedBy_stringSet_anyMatch_Value( vsv, propertyClass, value):\r\n## Subject sameness is sameness of any item in the sets (intersection of sets is non-empty):\r\n proxyIdList = %5b%5d\r\n for item in value:\r\n if propertyClass.overheadDict.has_key( item):\r\n for proxyId in propertyClass.overheadDict%5b item%5d:\r\n if proxyId not in proxyIdList:\r\n proxyIdList.append( proxyId)\r\n return proxyIdList\r\n\r\n#######################################################\r\ndef MergeProxiesBecause_stringSet_PropertyInstancesSpecifySameSubject( vsv, propertyClass):\r\n## Subject sameness is sameness of the whole set:\r\n ## Declare this one if and only if your property class is for SIPs\r\n ## (subject identity properties).\r\n for hashablePropertyValue in propertyClass.overheadDict:\r\n if len( propertyClass.overheadDict%5b hashablePropertyValue%5d) %3e 1:\r\n vsv.mergeListOfProxies( propertyClass, hashablePropertyValue, propertyClass.overheadDict%5b hashablePropertyValue%5d)\r\n \r\n#######################################################\r\ndef MergeProxiesBecause_stringSet_anyMatch_PropertyInstancesSpecifySameSubject( vsv, propertyClass):\r\n## Subject sameness is sameness of any item in the sets (intersection of sets is non-empty):\r\n ## Declare this one if and only if your property class is for SIPs\r\n ## (subject identity properties).\r\n itemList = propertyClass.overheadDict.keys() ## stabilize what we\'re doing\r\n for item in itemList:\r\n if len( propertyClass.overheadDict%5b item%5d) %3e 1:\r\n vsv.mergeListOfProxies( propertyClass, item, propertyClass.overheadDict%5b item%5d)\r\n foundThingsToMerge = True\r\n\r\n\r\n'%0ap1%0a.S'#####################################################################\r\n#####################################################################\r\n## Versavant Topic Map Application Bus / Subject Addressing Engine ##\r\n## Copyright 2005 Steven R. Newcomb ##\r\n## ##\r\n## This software is licensed under the Apache License, Version 2.0 ##\r\n## (the "License"); you may not use this file except in compliance ##\r\n## with the License. Copies of the License are available at ##\r\n## http://www.apache.org/licenses/LICENSE-2.0 ##\r\n## ##\r\n## Unless required by applicable law or agreed to in writing, ##\r\n## software distributed under the License is distributed on an "AS ##\r\n## IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either ##\r\n## express or implied. See the License for the specific language ##\r\n## governing permissions and limitations under the License. ##\r\n## ##\r\n## Copies of the source code and the license are available at ##\r\n## http://www.versavant.org ##\r\n#####################################################################\r\n#####################################################################\r\n\r\n####################################\r\ncvsRevision = "$Revision: 1.10 $" ##\r\n####################################\r\n\r\n\r\n#############################################\r\n## "proxyIdList" value type implementation ##\r\n#############################################\r\n\r\n## This value type is useful for storing references to proxies,\r\n## regardless of whether they are treated by the property classes that\r\n## use this value type are lists or sets. For example, you should use\r\n## this "proxyIdList" value type for both "proxyIdSet"-type property\r\n## classes and "proxyIdList"-type property classes. At this level,\r\n## it doesn\'t matter.\r\n\r\n## Values are lists of proxyIds, i.e., proxy.proxyId values, which are\r\n## always strings of decimal digits that begin with two zeroes.\r\n\r\n## When you create other value types that contain proxy references,\r\n## you can use this implementation as a guide. It\'s tricky to\r\n## manage proxy references, not only because they die when merged, but\r\n## also because they can\'t possibly retain their original IDs when\r\n## they are imported.\r\n\r\n## NOTE: During importation of instances of this value type from XML,\r\n## some recordkeeping is done in vsv.currentTopicMapHoldingDict%5b\r\n## \'IoMapsDict\'%5d%5b (TMA name)%5d%5b propertyClassName%5d. \r\n\r\nimport types, traceback\r\n\r\n#######################################################\r\ndef ValueIsNotOfType_proxyIdList_(vsv, propertyValue, propertyClass, propertyInstance = None, **args):\r\n propertyClassName = propertyClass.propertyClassName\r\n topicMap = propertyClass.topicMap\r\n TMA = propertyClass.TMA\r\n TMAName = TMA.TMAName\r\n\r\n if not ( isinstance( propertyValue, types.ListType) or isinstance( propertyValue, types.TupleType)):\r\n traceback.print_stack()\r\n if propertyInstance:\r\n vsv.errMsg( \'Value "%25s" of property %25s is neither list nor tuple.\' %25 ( propertyValue, propertyInstance.propertyInstanceKey))\r\n else:\r\n vsv.errMsg( \'Value "%25s" of a prospective %25s property is neither list nor tuple.\' %25 ( propertyValue, vsv.catKey( TMAName, propertyClassName)))\r\n return True\r\n\r\n for proxyId in propertyValue:\r\n if not isinstance(proxyId, types.StringType):\r\n if propertyInstance:\r\n vsv.errMsg( \'At least one item ("%25s") in the value of property %25s is not a string.\' %25 ( proxyId, propertyInstance.propertyInstanceKey))\r\n else:\r\n vsv.errMsg( \'At least one item ("%25s") in the value of a presumptive %25s property is not a string.\' %25 ( proxyId, vsv.catKey( TMAName, propertyClassName)))\r\n return True\r\n if not vsv.proxyIdStrValidatorRE.match( proxyId):\r\n if propertyInstance:\r\n vsv.errMsg( \'An item ("%25s") in the value of property %25s does not look like a proxy identifier string.\' %25 ( proxyId, propertyInstance.propertyInstanceKey))\r\n else:\r\n vsv.errMsg( \'An item ("%25s") in the value of a presumptive %25s property does not look like a proxy identifier string.\' %25 ( proxyId, vsv.catKey( TMAName, propertyClassName)))\r\n return True\r\n\r\n proxy = vsv.isProxyId( proxyId, topicMap)\r\n if not proxy:\r\n if proxyId not in vsv.currentTopicMapHoldingDict%5b \'IoMapsDict\'%5d%5b \'TMAs\'%5d%5b propertyInstance.TMAName%5d%5b propertyClassName%5d:\r\n ## We\'re probably in the process of importing a topic map, and these are\r\n ## references to proxies that don\'t exist yet because they haven\'t been imported\r\n ## yet. The above check is supposed to calm our fears that this proxy reference\r\n ## is invalid, giving us reason to believe that it will soon be valid, even\r\n ## though it\'s not quite valid yet.\r\n\r\n if propertyInstance:\r\n errString = \'An item ("%25s") in the list is not the ID of any proxy in topic map "%25s".\' %25 ( proxyId, propertyInstance.topicMap.topicMapName)\r\n else:\r\n errString = \'An item ("%25s") in the list is not the ID of any proxy in any open topic map.\' %25 ( proxyId)\r\n vsv.errMsg( errString)\r\n return True\r\n if proxy:\r\n if proxy.forwardTo:\r\n vsv.errMsg( \'An item ("%25s") in the list that is the value of property %25s is the ID of a dead proxy. Only the IDs of living proxies are permitted.\' %25 ( proxyId, propertyInstance.topicMap.topicMapName))\r\n return True\r\n\r\n return False ## all\'s well, presumably. \r\n\r\n#######################################################\r\ndef ValueIsNotOfType_proxyIdAndNoneList_(vsv, propertyValue, propertyClass, propertyInstance = None, **args):\r\n propertyClassName = propertyClass.propertyClassName\r\n topicMap = propertyClass.topicMap\r\n TMA = propertyClass.TMA\r\n TMAName = TMA.TMAName\r\n\r\n if not ( isinstance( propertyValue, types.ListType) or isinstance( propertyValue, types.TupleType)):\r\n traceback.print_stack()\r\n if propertyInstance:\r\n vsv.errMsg( \'Value "%25s" of property %25s is neither list nor tuple.\' %25 ( propertyValue, propertyInstance.propertyInstanceKey))\r\n else:\r\n vsv.errMsg( \'Value "%25s" of a prospective %25s property is neither list nor tuple.\' %25 ( propertyValue, vsv.catKey( TMAName, propertyClassName)))\r\n return True\r\n\r\n for proxyId in propertyValue:\r\n\r\n if not ( isinstance( proxyId, types.StringType) or isinstance( proxyId, types.NoneType)):\r\n if propertyInstance:\r\n vsv.errMsg( \'At least one item ("%25s") in the value of property %25s is neither string nor None.\' %25 ( proxyId, propertyInstance.propertyInstanceKey))\r\n else:\r\n vsv.errMsg( \'At least one item ("%25s") in the value of a presumptive %25s property is neither string nor None.\' %25 ( proxyId, vsv.catKey( TMAName, propertyClassName)))\r\n return True\r\n\r\n if proxyId != None:\r\n if not vsv.proxyIdStrValidatorRE.match( proxyId):\r\n if propertyInstance:\r\n vsv.errMsg( \'A string ("%25s") in the value of property %25s does not look like a proxy identifier string.\' %25 ( proxyId, propertyInstance.propertyInstanceKey))\r\n else:\r\n vsv.errMsg( \'An string ("%25s") in the value of a presumptive %25s property does not look like a proxy identifier string.\' %25 ( proxyId, vsv.catKey( TMAName, propertyClassName)))\r\n return True\r\n\r\n if not topicMap.proxies.has_key( proxyId):\r\n if proxyId not in vsv.currentTopicMapHoldingDict%5b \'IoMapsDict\'%5d%5b \'TMAs\'%5d%5b propertyInstance.TMAName%5d%5b propertyClassName%5d:\r\n ## We\'re probably in the process of importing a topic map, and these are\r\n ## references to proxies that don\'t exist yet because they haven\'t been imported\r\n ## yet. The above check is supposed to calm our fears that this proxy reference\r\n ## is invalid, giving us reason to believe that it will soon be valid, even\r\n ## though it\'s not quite valid yet.\r\n\r\n if propertyInstance:\r\n errString = \'An item ("%25s") in the list is not the ID of any proxy in topic map "%25s".\' %25 ( proxyId, propertyInstance.topicMap.topicMapName)\r\n else:\r\n errString = \'An item ("%25s") in the list is not the ID of any proxy in any open topic map.\' %25 ( proxyId)\r\n vsv.errMsg( errString)\r\n return True\r\n else:\r\n proxy = topicMap.proxies%5b proxyId%5d\r\n if proxy.forwardTo:\r\n vsv.errMsg( \'An item ("%25s") in the list that is the value of property %25s is the ID of a dead proxy. Only the IDs of living proxies are permitted.\' %25 ( proxyId, propertyInstance.topicMap.topicMapName))\r\n return True\r\n\r\n return False ## all\'s well, presumably. \r\n\r\n#######################################################\r\ndef InstanceOf_proxyIdList_ValueTypeToXMLContentString(vsv, propertyInstance):\r\n return vsv.cPickleDumpObjectAsXMLContentString( propertyInstance._value)\r\n\r\n#######################################################\r\ndef XMLContentStringToInstanceOf_proxyIdList_ValueType(vsv, string, propertyClass, **args):\r\n ## Import a list of proxy references, adjusting them as necessary to\r\n ## the new proxyIds of the imported proxies to which they refer.\r\n\r\n oldProxyIdList = vsv.cPickleLoadObjectFromXMLContentString( string)\r\n\r\n mem2xmlProxyIdDict = vsv.currentTopicMapHoldingDict%5b \'IoMapsDict\'%5d%5b \'ProxyIds.mem2xml\'%5d\r\n ## This dictionary allows us to look up the in-xml element id of a\r\n ## proxy, given the proxy\'s proxyId as it was in the topic map\r\n ## from which the proxy was exported as xml.\r\n\r\n firstImportedProxyId = vsv.firstImportedProxyId\r\n ## This is an integer which, if we were to convert it into a\r\n ## string of decimal digits with 2 prepended zero characters,\r\n ## would be the proxyId of the first (the first, that is, not\r\n ## counting the proxies created in order to register the TMAs\r\n ## of the xml topic map being imported) in-memory proxy to be\r\n ## imported into the being-imported-into topic map from the\r\n ## xml topic map that we\'re importing.\r\n\r\n propertyClassName = propertyClass.propertyClassName\r\n TMAName = propertyClass.TMA.TMAName\r\n\r\n newProxyIdList = %5b%5d\r\n\r\n for oldProxyId in oldProxyIdList:\r\n xmlProxyNum = mem2xmlProxyIdDict%5b int( oldProxyId)%5d\r\n newProxyNum = (xmlProxyNum + firstImportedProxyId) - 1\r\n newProxyId = \'00%25s\' %25 ( newProxyNum)\r\n newProxyIdList.append( newProxyId)\r\n\r\n appDict = vsv.currentTopicMapHoldingDict%5b \'IoMapsDict\'%5d%5b \'TMAs\'%5d%5b TMAName%5d\r\n if not appDict.has_key( propertyClassName):\r\n appDict%5b propertyClassName%5d = %5b newProxyId%5d\r\n else:\r\n if newProxyId not in appDict%5b propertyClassName%5d:\r\n appDict%5b propertyClassName%5d.append( newProxyId)\r\n ## vsv.IoMapsDict%5b args%5b \'TMAName\'%5d%5d%5b propertyClassName%5d will be consulted by\r\n ## the ValueIsNotOfType__() function in order to avoid a logical logjam over this.\r\n ## The logical logjam is that we\'re referring to proxies that haven\'t been imported\r\n ## yet, and the ValueIsNotOfType__() function checks to see that the proxy references are valid.\r\n ## This gives the ValueIsNotOfType__() function something to fall back on, as it checks.\r\n ## See that function, above, for more.\r\n\r\n return newProxyIdList\r\n\r\n#######################################################\r\ndef InstanceOf_proxyIdListRaw_ValueTypeToXMLContentString(vsv, propertyInstance):\r\n return repr( propertyInstance._value)\r\n\r\n#######################################################\r\ndef XMLContentStringToInstanceOf_proxyIdListRaw_ValueType(vsv, string, propertyClass, **args):\r\n ## Import a list of proxy references, adjusting them as necessary to\r\n ## the new proxyIds of the imported proxies to which they refer.\r\n\r\n exec \'oldProxyIdList = %25s\' %25 ( string)\r\n\r\n mem2xmlProxyIdDict = vsv.currentTopicMapHoldingDict%5b \'IoMapsDict\'%5d%5b \'ProxyIds.mem2xml\'%5d\r\n ## This dictionary allows us to look up the in-xml element id of a\r\n ## proxy, given the proxy\'s proxyId as it was in the topic map\r\n ## from which the proxy was exported as xml.\r\n\r\n firstImportedProxyId = vsv.firstImportedProxyId\r\n ## This is an integer which, if we were to convert it into a\r\n ## string of decimal digits with 2 prepended zero characters,\r\n ## would be the proxyId of the first (the first, that is, not\r\n ## counting the proxies created in order to register the TMAs\r\n ## of the xml topic map being imported) in-memory proxy to be\r\n ## imported into the being-imported-into topic map from the\r\n ## xml topic map that we\'re importing.\r\n\r\n propertyClassName = propertyClass.propertyClassName\r\n TMAName = propertyClass.TMA.TMAName\r\n\r\n newProxyIdList = %5b%5d\r\n\r\n for oldProxyId in oldProxyIdList:\r\n if oldProxyId == None:\r\n newProxyIdList.append( None)\r\n else:\r\n xmlProxyNum = mem2xmlProxyIdDict%5b int( oldProxyId)%5d\r\n newProxyNum = (xmlProxyNum + firstImportedProxyId) - 1\r\n newProxyId = \'00%25s\' %25 ( newProxyNum)\r\n newProxyIdList.append( newProxyId)\r\n\r\n appDict = vsv.currentTopicMapHoldingDict%5b \'IoMapsDict\'%5d%5b \'TMAs\'%5d%5b TMAName%5d\r\n if not appDict.has_key( propertyClassName):\r\n appDict%5b propertyClassName%5d = %5b newProxyId%5d\r\n else:\r\n if newProxyId not in appDict%5b propertyClassName%5d:\r\n appDict%5b propertyClassName%5d.append( newProxyId)\r\n ## vsv.IoMapsDict%5b args%5b \'TMAName\'%5d%5d%5b propertyClassName%5d will be consulted by\r\n ## the ValueIsNotOfType__() function in order to avoid a logical logjam over this.\r\n ## The logical logjam is that we\'re referring to proxies that haven\'t been imported\r\n ## yet, and the ValueIsNotOfType__() function checks to see that the proxy references are valid.\r\n ## This gives the ValueIsNotOfType__() function something to fall back on, as it checks.\r\n ## See that function, above, for more.\r\n\r\n return newProxyIdList\r\n\r\n#######################################################\r\ndef InstanceOf_proxyIdListRaw_ValueTypeToXMLContentString(vsv, propertyInstance):\r\n return repr( propertyInstance._value)\r\n\r\n#######################################################\r\ndef XMLContentStringToInstanceOf_proxyIdOrNoneListRaw_ValueType(vsv, string, propertyClass, **args):\r\n ## Import a list of proxy references, adjusting them as necessary to\r\n ## the new proxyIds of the imported proxies to which they refer.\r\n\r\n exec \'oldProxyIdList = %25s\' %25 ( string)\r\n\r\n mem2xmlProxyIdDict = vsv.currentTopicMapHoldingDict%5b \'IoMapsDict\'%5d%5b \'ProxyIds.mem2xml\'%5d\r\n ## This dictionary allows us to look up the in-xml element id of a\r\n ## proxy, given the proxy\'s proxyId as it was in the topic map\r\n ## from which the proxy was exported as xml.\r\n\r\n firstImportedProxyId = vsv.firstImportedProxyId\r\n ## This is an integer which, if we were to convert it into a\r\n ## string of decimal digits with 2 prepended zero characters,\r\n ## would be the proxyId of the first (the first, that is, not\r\n ## counting the proxies created in order to register the TMAs\r\n ## of the xml topic map being imported) in-memory proxy to be\r\n ## imported into the being-imported-into topic map from the\r\n ## xml topic map that we\'re importing.\r\n\r\n propertyClassName = propertyClass.propertyClassName\r\n TMAName = propertyClass.TMA.TMAName\r\n\r\n newProxyIdList = %5b%5d\r\n\r\n for oldProxyId in oldProxyIdList:\r\n if oldProxyId != None:\r\n xmlProxyNum = mem2xmlProxyIdDict%5b int( oldProxyId)%5d\r\n newProxyNum = (xmlProxyNum + firstImportedProxyId) - 1\r\n newProxyId = \'00%25s\' %25 ( newProxyNum)\r\n newProxyIdList.append( newProxyId)\r\n\r\n appDict = vsv.currentTopicMapHoldingDict%5b \'IoMapsDict\'%5d%5b \'TMAs\'%5d%5b TMAName%5d\r\n if not appDict.has_key( propertyClassName):\r\n appDict%5b propertyClassName%5d = %5b newProxyId%5d\r\n else:\r\n if newProxyId not in appDict%5b propertyClassName%5d:\r\n appDict%5b propertyClassName%5d.append( newProxyId)\r\n ## vsv.IoMapsDict%5b args%5b \'TMAName\'%5d%5d%5b propertyClassName%5d will be consulted by\r\n ## the ValueIsNotOfType__() function in order to avoid a logical logjam over this.\r\n ## The logical logjam is that we\'re referring to proxies that haven\'t been imported\r\n ## yet, and the ValueIsNotOfType__() function checks to see that the proxy references are valid.\r\n ## This gives the ValueIsNotOfType__() function something to fall back on, as it checks.\r\n ## See that function, above, for more.\r\n\r\n else:\r\n newProxyIdList.append( None)\r\n\r\n return newProxyIdList\r\n\r\n'%0ap1%0a.S'#####################################################################\r\n#####################################################################\r\n## Versavant Topic Map Application Bus / Subject Addressing Engine ##\r\n## Copyright 2005 Steven R. Newcomb ##\r\n## ##\r\n## This software is licensed under the Apache License, Version 2.0 ##\r\n## (the "License"); you may not use this file except in compliance ##\r\n## with the License. Copies of the License are available at ##\r\n## http://www.apache.org/licenses/LICENSE-2.0 ##\r\n## ##\r\n## Unless required by applicable law or agreed to in writing, ##\r\n## software distributed under the License is distributed on an "AS ##\r\n## IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either ##\r\n## express or implied. See the License for the specific language ##\r\n## governing permissions and limitations under the License. ##\r\n## ##\r\n## Copies of the source code and the license are available at ##\r\n## http://www.versavant.org ##\r\n#####################################################################\r\n#####################################################################\r\n\r\n####################################\r\ncvsRevision = "$Revision: 1.7 $" ##\r\n####################################\r\n\r\n\r\n################################################################\r\n## This simple value type is for strings. ##\r\n## They will be stored in pickled form ##\r\n## in the XML file. (See below for raw storage and unicode.) ##\r\n################################################################\r\n\r\nimport types\r\n\r\n#######################################################\r\ndef ValueIsNotOfType_string_( vsv, propertyValue, propertyClass, propertyInstance = None):\r\n if not ( isinstance( propertyValue, types.StringType) or isinstance( propertyValue, types.UnicodeType)):\r\n vsv.errMsg( \'Value "%25s" is neither a string nor a unicode; it\\\'s a %25s.\' %25 ( propertyValue, type( propertyValue)))\r\n return True\r\n return False\r\n\r\n#######################################################\r\ndef InstanceOf_string_ValueTypeToXMLContentString( vsv, propertyInstance):\r\n return vsv.cPickleDumpObjectAsXMLContentString( propertyInstance._value)\r\n\r\n#######################################################\r\ndef XMLContentStringToInstanceOf_string_ValueType( vsv, string, propertyClass):\r\n return vsv.cPickleLoadObjectFromXMLContentString( string)\r\n\r\n\r\n#######################################################\r\ndef InstanceOf_stringRaw_ValueTypeToXMLContentString( vsv, propertyInstance):\r\n return propertyInstance._value.replace( \'%3c\', \'%25.LT.%25\').replace( \'%3e\', \'%25.GT.%25\')\r\n\r\n#######################################################\r\ndef XMLContentStringToInstanceOf_stringRaw_ValueType( vsv, string, propertyClass):\r\n return string.replace( \'%25.LT.%25\', \'%3c\').replace( \'%25.GT.%25\', \'%3e\')\r\n\r\n######################################################################\r\n## Use these for string values that need to be directly editable in ##\r\n## the interchangeable XML file. This avoids pickling/unpickling, ##\r\n## allowing the strings to appear "in the raw" in the file. ##\r\n######################################################################\r\ndef ValueIsNotOfType_rawString_( vsv, propertyValue, propertyClass, propertyInstance = None):\r\n if not isinstance( propertyValue, types.StringType):\r\n vsv.errMsg( \'Value "%25s" is not a string, it is a %25s.\' %25 ( propertyValue, type( propertyValue)))\r\n return True\r\n return False\r\n\r\n#######################################################\r\ndef InstanceOf_rawString_ValueTypeToXMLContentString( vsv, propertyInstance):\r\n return propertyInstance._value.replace( \'%26\', \'%26amp;\').replace( \'%3c\', \'%26lt;\').replace( \'%3e\', \'%26gt;\').encode( \'utf-8\')\r\n\r\n#######################################################\r\ndef XMLContentStringToInstanceOf_rawString_ValueType( vsv, string, propertyClass):\r\n return string.replace( \'%26lt;\', \'%3c\').replace( \'%26gt;\', \'%3e\').replace( \'%26amp;\', \'%26\').encode( \'ASCII\')\r\n\r\n\r\n\r\n\r\n## Unicode version, with pickling. ##\r\n#######################################################\r\ndef ValueIsNotOfType_unicodeString_( vsv, propertyValue, propertyClass, propertyInstance = None):\r\n if not isinstance( propertyValue, types.UnicodeType):\r\n vsv.errMsg( \'Value "%25s" is not a Unicode string.\' %25 ( propertyValue))\r\n return True\r\n return False\r\n\r\n#######################################################\r\ndef InstanceOf_unicodeString_ValueTypeToXMLContentString( vsv, propertyInstance):\r\n return vsv.cPickleDumpObjectAsXMLContentString( propertyInstance._value)\r\n\r\n#######################################################\r\ndef XMLContentStringToInstanceOf_unicodeString_ValueType( vsv, string, propertyClass):\r\n return vsv.cPickleLoadObjectFromXMLContentString( string)\r\n\r\n\r\n## Unicode version, no pickling (raw). ##\r\n######################################################################\r\n## Use these for string values that need to be directly editable in ##\r\n## the interchangeable XML file. This avoids pickling/unpickling, ##\r\n## allowing the strings to appear "in the raw" in the file. ##\r\n######################################################################\r\ndef ValueIsNotOfType_rawUnicodeString_( vsv, propertyValue, propertyClass, propertyInstance = None):\r\n if not ( isinstance( propertyValue, types.UnicodeType) or isinstance( propertyValue, types.StringType)):\r\n vsv.errMsg( \'Value "%25s" is neither a %3ctype \\\'unicode\\\'%3e nor a %3ctype \\\'str\\\'%3e; it\\\'s a %25s.\' %25 ( propertyValue, type( propertyValue)))\r\n return True\r\n return False\r\n\r\n#######################################################\r\ndef InstanceOf_rawUnicodeString_ValueTypeToXMLContentString( vsv, propertyInstance):\r\n## return propertyInstance._value.replace( u\'%26\', u\'VSV-ENTITY-amp\').replace( u\'%3c\', u\'%26lt;\').replace( u\'%3e\', u\'%26gt;\')\r\n return vsv.pickleStringXMLEscapify( propertyInstance._value)\r\n\r\n#######################################################\r\ndef XMLContentStringToInstanceOf_rawUnicodeString_ValueType( vsv, string, propertyClass):\r\n## return string.replace( u\'%26lt;\', u\'%3c\').replace( u\'%26gt;\', u\'%3e\').replace( u\'VSV-ENTITY-amp\', u\'%26\')\r\n return vsv.pickleStringXMLUnescapify( string)\r\n\r\n'%0ap1%0a.S'#####################################################################\r\n#####################################################################\r\n## Versavant Topic Map Application Bus / Subject Addressing Engine ##\r\n## Copyright 2005 Steven R. Newcomb ##\r\n## ##\r\n## This software is licensed under the Apache License, Version 2.0 ##\r\n## (the "License"); you may not use this file except in compliance ##\r\n## with the License. Copies of the License are available at ##\r\n## http://www.apache.org/licenses/LICENSE-2.0 ##\r\n## ##\r\n## Unless required by applicable law or agreed to in writing, ##\r\n## software distributed under the License is distributed on an "AS ##\r\n## IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either ##\r\n## express or implied. See the License for the specific language ##\r\n## governing permissions and limitations under the License. ##\r\n## ##\r\n## Copies of the source code and the license are available at ##\r\n## http://www.versavant.org ##\r\n#####################################################################\r\n#####################################################################\r\n\r\n####################################\r\ncvsRevision = "$Revision: 1.7 $" ##\r\n####################################\r\n\r\n\r\n##############################################\r\n## This value type is for lists of strings. ##\r\n##############################################\r\n\r\nimport types\r\n\r\n#######################################################\r\ndef ValueIsNotOfType_stringList_( vsv, propertyValue, propertyClass, propertyInstance = None):\r\n if not isinstance( propertyValue, types.ListType):\r\n vsv.errMsg( \'Value "%25s" is not a list.\' %25 propertyValue)\r\n return True\r\n for item in propertyValue:\r\n if not isinstance( item, types.StringType):\r\n vsv.errMsg( \'Item ("%25s") in value "%25s" is not a string.\' %25 ( item, propertyValue))\r\n return True\r\n return False\r\n\r\n#######################################################\r\ndef InstanceOf_stringList_ValueTypeToXMLContentString( vsv, propertyInstance):\r\n return vsv.cPickleDumpObjectAsXMLContentString( propertyInstance._value)\r\n\r\n#######################################################\r\ndef XMLContentStringToInstanceOf_stringList_ValueType( vsv, string, propertyClass):\r\n return vsv.cPickleLoadObjectFromXMLContentString( string)\r\n\r\n\r\n##############################\r\n## Lists of Unicode strings ##\r\n##############################\r\n\r\n#######################################################\r\ndef ValueIsNotOfType_unicodeStringList_( vsv, propertyValue, propertyClass, propertyInstance = None):\r\n if not isinstance( propertyValue, types.ListType):\r\n vsv.errMsg( \'Value "%25s" is not a list.\' %25 propertyValue)\r\n return True\r\n for item in propertyValue:\r\n if not isinstance( item, types.UnicodeType):\r\n vsv.errMsg( \'Item ("%25s") in value "%25s" is not a Unicode string.\' %25 ( item, propertyValue))\r\n return True\r\n return False\r\n\r\n\r\n\r\n##################################\r\n## Lists of raw strings ##\r\n##################################\r\n\r\n#######################################################\r\ndef InstanceOf_rawStringList_ValueTypeToXMLContentString( vsv, propertyInstance):\r\n return repr( propertyInstance._value)\r\n\r\n#######################################################\r\ndef XMLContentStringToInstanceOf_rawStringList_ValueType( vsv, string, propertyClass):\r\n exec \'stringList = %25s\' %25 ( string)\r\n return stringList\r\n\r\n##################################\r\n## Lists of raw Unicode strings ##\r\n##################################\r\n\r\n#######################################################\r\ndef InstanceOf_rawUnicodeStringList_ValueTypeToXMLContentString( vsv, propertyInstance):\r\n return vsv.pickleStringXMLEscapify( repr( propertyInstance._value))\r\n\r\n#######################################################\r\ndef XMLContentStringToInstanceOf_rawUnicodeStringList_ValueType( vsv, string, propertyClass):\r\n exec \'unicodeStringList = %25s\' %25 ( vsv.pickleStringXMLUnescapify( string))\r\n return unicodeStringList\r\n\r\n'%0ap1%0a.S'%3c?xml version="1.0" encoding="ASCII"?%3e\n%3c!-- %3c!DOCTYPE VersavantTMA SYSTEM "http://www.versavant.org/dtds/TMAConfigFile.dtd"%3e--%3e\n%3c!--\n#####################################################################\n#####################################################################\n## Copyright 2005 Steven R. Newcomb ##\n## ##\n## This software is licensed under the Apache License, Version 2.0 ##\n## (the "License"); you may not use this file except in compliance ##\n## with the License. Copies of the License are available at ##\n## http://www.apache.org/licenses/LICENSE-2.0 ##\n## ##\n## Unless required by applicable law or agreed to in writing, ##\n## software distributed under the License is distributed on an "AS ##\n## IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either ##\n## express or implied. See the License for the specific language ##\n## governing permissions and limitations under the License. ##\n## ##\n## Copies of the source code and the license are available at ##\n## http://www.versavant.org ##\n#####################################################################\n#####################################################################\n--%3e\n%3c!DOCTYPE VersavantTMA SYSTEM "../versavantTMA.dtd"%3e\n%3cVersavantTMA\nVersavantTMADTDVersion="1"\n\n %3e%3cDesc%3eUniverse of Discourse (UoD) for EMAIL subjects.%3c/Desc\n\n %3e%3cValueType ValueTypeName="rawProxyIdList"\n %3e%3cDesc%3eGeneral-purpose list-of-subject-proxies value type.%3c/Desc\n %3e%3cValueIsNotOfType__\n functionModuleFilePath="${VSVEXECDIR}/Lib/VTproxyIdList.py"\n functionName="ValueIsNotOfType_proxyIdList_"\n /%3e%3cInstanceOf__ValueTypeToXMLContentString\n functionModuleFilePath="${VSVEXECDIR}/Lib/VTproxyIdList.py"\n functionName="InstanceOf_proxyIdListRaw_ValueTypeToXMLContentString"\n /%3e%3cXMLContentStringToInstanceOf__ValueType\n functionModuleFilePath="${VSVEXECDIR}/Lib/VTproxyIdList.py"\n functionName="XMLContentStringToInstanceOf_proxyIdListRaw_ValueType"\n /%3e%3c/ValueType\n\n %3e%3cValueType ValueTypeName="rawUnicodeString"\n %3e%3cDesc%3eGeneral-purpose Unicode string value type.%3c/Desc\n %3e%3cValueIsNotOfType__\n functionModuleFilePath="${VSVEXECDIR}/Lib/VTstring.py"\n functionName="ValueIsNotOfType_rawUnicodeString_"\n /%3e%3cInstanceOf__ValueTypeToXMLContentString\n functionModuleFilePath="${VSVEXECDIR}/Lib/VTstring.py"\n functionName="InstanceOf_rawUnicodeString_ValueTypeToXMLContentString"\n /%3e%3cXMLContentStringToInstanceOf__ValueType\n functionModuleFilePath="${VSVEXECDIR}/Lib/VTstring.py"\n functionName="XMLContentStringToInstanceOf_rawUnicodeString_ValueType"\n /%3e%3c/ValueType\n\n %3e%3cValueType ValueTypeName="rawUnicodeStringList"\n %3e%3cDesc%3eGeneral-purpose value type that is a list of raw Unicode strings.%3c/Desc\n %3e%3cValueIsNotOfType__\n functionModuleFilePath="${VSVEXECDIR}/Lib/VTstringList.py"\n functionName="ValueIsNotOfType_unicodeStringList_"\n /%3e%3cInstanceOf__ValueTypeToXMLContentString\n functionModuleFilePath="${VSVEXECDIR}/Lib/VTstringList.py"\n functionName="InstanceOf_rawUnicodeStringList_ValueTypeToXMLContentString"\n /%3e%3cXMLContentStringToInstanceOf__ValueType\n functionModuleFilePath="${VSVEXECDIR}/Lib/VTstringList.py"\n functionName="XMLContentStringToInstanceOf_rawUnicodeStringList_ValueType"\n /%3e%3c/ValueType\n\n %3e%3cPropertyClass PropertyClassName="emailAddresses" ValueType="rawUnicodeStringList"\n %3e%3cDesc%3eSIP for persons; each item is an email address for the person; if any email address matches, it\'s the same subject.%3c/Desc\n %3e%3cAdd__PropToOverheadDict\n functionModuleFilePath="${VSVEXECDIR}/Lib/PCstringSet.py"\n functionName="Add_stringSet_anyMatch_PropToOverheadDict"\n /%3e%3cRemove__PropFromOverheadDict\n functionModuleFilePath="${VSVEXECDIR}/Lib/PCstringSet.py"\n functionName="Remove_stringSet_anyMatch_PropFromOverheadDict"\n /%3e%3cMerge__PropertyValues\n functionModuleFilePath="${VSVEXECDIR}/Lib/PCstringSet.py"\n functionName="Merge_stringSet_PropertyValues"\n /%3e%3cMergeProxiesBecause__PropertyInstancesSpecifySameSubject\n functionModuleFilePath="${VSVEXECDIR}/Lib/PCstringSet.py"\n functionName="MergeProxiesBecause_stringSet_anyMatch_PropertyInstancesSpecifySameSubject"\n /%3e%3cValuesOf__PropertyInstancesAreSignificantlyDifferent\n functionModuleFilePath="${VSVEXECDIR}/Lib/PCstringSet.py"\n functionName="ValuesOf_stringSet_PropertyInstancesAreSignificantlyDifferent"\n /%3e%3cProxiesWith__ValueNotSignificantlyDifferentFrom\n functionModuleFilePath="${VSVEXECDIR}/Lib/PCstringSet.py"\n functionName="ProxiesOfSubjectIdentifiedBy_stringSet_anyMatch_Value"\n /%3e%3c/PropertyClass\n\n %3e%3cPropertyClass PropertyClassName="subjectLine" ValueType="rawUnicodeString"\n %3e%3cDesc%3eSIP for subject lines; values are email "Subject:s".%3c/Desc\n %3e%3cAdd__PropToOverheadDict\n functionModuleFilePath="${VSVEXECDIR}/Lib/PCstring.py"\n functionName="Add_string_PropToOverheadDict"\n /%3e%3cRemove__PropFromOverheadDict\n functionModuleFilePath="${VSVEXECDIR}/Lib/PCstring.py"\n functionName="Remove_string_PropFromOverheadDict"\n /%3e%3cMerge__PropertyValues\n functionModuleFilePath="${VSVEXECDIR}/Lib/PCstring.py"\n functionName="Merge_string_PropertyValues"\n /%3e%3cMergeProxiesBecause__PropertyInstancesSpecifySameSubject\n functionModuleFilePath="${VSVEXECDIR}/Lib/PCstring.py"\n functionName="MergeProxiesBecause_string_PropertyInstancesSpecifySameSubject"\n /%3e%3cValuesOf__PropertyInstancesAreSignificantlyDifferent\n functionModuleFilePath="${VSVEXECDIR}/Lib/PCstring.py"\n functionName="ValuesOf_string_PropertyInstancesAreSignificantlyDifferent"\n /%3e%3cProxiesWith__ValueNotSignificantlyDifferentFrom\n functionModuleFilePath="${VSVEXECDIR}/Lib/PCstring.py"\n functionName="ProxiesOfSubjectIdentifiedBy_string_Value"\n /%3e%3c/PropertyClass\n\n %3e%3cPropertyClass PropertyClassName="date" ValueType="rawProxyIdList"\n %3e%3cDesc%3eOP for emails; value is a reference to the proxy for the date of the email.%3c/Desc\n %3e%3cAdd__PropToOverheadDict\n functionModuleFilePath="${VSVEXECDIR}/Lib/PCproxyIdSet.py"\n functionName="Add_proxyIdSet_PropToOverheadDict"\n /%3e%3cRemove__PropFromOverheadDict\n functionModuleFilePath="${VSVEXECDIR}/Lib/PCproxyIdSet.py"\n functionName="Remove_proxyIdSet_PropFromOverheadDict"\n /%3e%3cMerge__PropertyValues\n functionModuleFilePath="${VSVEXECDIR}/Lib/PCproxyIdSet.py"\n functionName="Merge_accumulatingProxyIdSet_PropertyValues"\n /%3e%3cValuesOf__PropertyInstancesAreSignificantlyDifferent\n functionModuleFilePath="${VSVEXECDIR}/Lib/PCproxyIdSet.py"\n functionName="ValuesOf_proxyIdSet_PropertyInstancesAreSignificantlyDifferent"\n /%3e%3cProxiesWith__ValueNotSignificantlyDifferentFrom\n functionModuleFilePath="${VSVEXECDIR}/Lib/PCproxyIdSet.py"\n functionName="ProxiesOfSubjectIdentifiedBy_proxyIdSet_Value"\n /%3e%3cUpdateProxyReferencesIn__Value\n functionModuleFilePath="${VSVEXECDIR}/Lib/PCproxyIdSet.py"\n functionName="UpdateProxyReferencesIn_proxyIdSet_Value"\n /%3e%3c/PropertyClass\n\n%3e%3c/VersavantTMA%3e\n'%0ap1%0a.S'#####################################################################\r\n#####################################################################\r\n## Copyright 2005 Steven R. Newcomb ##\r\n## ##\r\n## This software is licensed under the Apache License, Version 2.0 ##\r\n## (the "License"); you may not use this file except in compliance ##\r\n## with the License. Copies of the License are available at ##\r\n## http://www.apache.org/licenses/LICENSE-2.0 ##\r\n## ##\r\n## Unless required by applicable law or agreed to in writing, ##\r\n## software distributed under the License is distributed on an "AS ##\r\n## IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either ##\r\n## express or implied. See the License for the specific language ##\r\n## governing permissions and limitations under the License. ##\r\n## ##\r\n## Copies of the source code and the license are available at ##\r\n## http://www.versavant.org ##\r\n#####################################################################\r\n#####################################################################\r\n\r\n####################################\r\ncvsRevision = "$Revision: 1.8 $" ##\r\n####################################\r\n\r\n\r\nimport sys, pdb\r\n\r\n\r\n#######################################\r\n## proxyIdSet PC implementation ##\r\n#######################################\r\n\r\n## These functions are useful as implementations of SIPs or OPs whose\r\n## values are lists of references to proxies. Obviously, the name\r\n## "proxyIdSet" only applies to these (library) functions; TMA\r\n## designers can use any name(s) for such properties.\r\n\r\n#######################################################\r\ndef Add_proxyIdSet_PropToOverheadDict( vsv, propertyInstance, overheadDict, proxyIdMap):\r\n\r\n if proxyIdMap:\r\n value = %5b%5d\r\n for proxyId in propertyInstance._value:\r\n value.append( proxyIdMap%5b proxyId%5d)\r\n propertyInstance._value = value\r\n\r\n workDict = {}\r\n for proxyId in propertyInstance._value:\r\n workDict%5b proxyId%5d = None\r\n propertyInstance.listOfIdsOfReferencedProxies = propertyInstance._value = workDict.keys()\r\n\r\n hashablePropertyValue = propertyInstance.hashablePropertyValue = frozenset( propertyInstance._value)\r\n\r\n if overheadDict.has_key( hashablePropertyValue):\r\n if overheadDict%5b hashablePropertyValue%5d.has_key( propertyInstance.proxyId):\r\n vsv.errMsg( \'ProxyId %25s is already listed in the overheadDict of property class for the value (%25s)\' %25 (\r\n propertyInstance.proxyId, propertyInstance._value))\r\n sys.exit( 1)\r\n overheadDict%5b hashablePropertyValue%5d%5b propertyInstance.proxyId%5d = None\r\n else:\r\n overheadDict%5b hashablePropertyValue%5d = { propertyInstance.proxyId: None}\r\n\r\n vsv.addNewProxyReferencesToReferencedProxiesDict( propertyInstance)\r\n\r\n#######################################################\r\ndef Remove_proxyIdSet_PropFromOverheadDict( vsv, propertyInstance, overheadDict):\r\n hashablePropertyValue = propertyInstance.hashablePropertyValue\r\n if not overheadDict.has_key( hashablePropertyValue):\r\n vsv.errMsg( \'No entry in overheadDict of property class for the value (%25s) of property %25s\' %25 (\r\n propertyInstance._value,\r\n vsv.catKey( propertyInstance.topicMap.topicMapName, propertyInstance.propertyInstanceKey)))\r\n sys.exit( 1)\r\n if propertyInstance.proxyId not in overheadDict%5b hashablePropertyValue%5d:\r\n vsv.errMsg( \'ProxyId %25s not found in the overheadDict of property class for the value (%25s) of property %25s\' %25 (\r\n propertyInstance.proxyId,\r\n propertyInstance._value,\r\n vsv.catKey( propertyInstance.topicMap.topicMapName, propertyInstance.propertyInstanceKey)))\r\n sys.exit( 1)\r\n\r\n del overheadDict%5b hashablePropertyValue%5d%5b propertyInstance.proxyId%5d\r\n if not len( overheadDict%5b hashablePropertyValue%5d):\r\n del overheadDict%5b hashablePropertyValue%5d\r\n\r\n vsv.removeOldProxyReferencesFromReferencedProxiesDict( propertyInstance)\r\n\r\n#######################################################\r\ndef ValueIsInvalidFor_proxyIdSet_Property( vsv, propertyValue, propertyClass, propertyInstance = None):\r\n ## the value type validator does everything necessary\r\n return False\r\n\r\n#######################################################\r\ndef Merge_proxyIdSet_PropertyValues( vsv, value1, value2):\r\n if value1 == value2:\r\n return value1\r\n else:\r\n return None ## merge is unsuccessful\r\n\r\n#######################################################\r\ndef Merge_accumulatingProxyIdSet_PropertyValues( vsv, value1, value2):\r\n wkdict = {}\r\n for proxyId in value1:\r\n wkdict%5b proxyId%5d = None\r\n for proxyId in value2:\r\n wkdict%5b proxyId%5d = None\r\n return wkdict.keys()\r\n\r\n#######################################################\r\ndef ValuesOf_proxyIdSet_PropertyInstancesAreSignificantlyDifferent( vsv, value1, value2):\r\n if frozenset( value1) != frozenset( value2): ## ignore differences in sequence and ignore redundant entries\r\n return True\r\n return False\r\n\r\n#######################################################\r\ndef MergeProxiesBecause_proxyIdSet_PropertyInstancesSpecifySameSubject( vsv, propertyClass):\r\n for key in propertyClass.overheadDict:\r\n if len( propertyClass.overheadDict%5b key%5d) %3e 1:\r\n vsv.mergeListOfProxies( propertyClass, key, propertyClass.overheadDict%5b key%5d.keys())\r\n\r\n#######################################################\r\ndef ProxiesOfSubjectIdentifiedBy_proxyIdSet_Value( vsv, propertyClass, value):\r\n hashablePropertyValue = frozenset( value)\r\n if propertyClass.overheadDict.has_key( hashablePropertyValue):\r\n return propertyClass.overheadDict%5b hashablePropertyValue%5d.keys()\r\n else:\r\n return %5b%5d ## empty list -- no match\r\n\r\n#######################################################\r\ndef UpdateProxyReferencesIn_proxyIdSet_Value( vsv, propertyInstance, proxyIdToReplace, replacementProxyId):\r\n value = propertyInstance._value\r\n if proxyIdToReplace not in value:\r\n vsv.errMsg( \'proxyIdToReplace "%25s" not found in the value of %25s\' %25 (\r\n proxyIdToReplace,\r\n vsv.catKey( propertyInstance.topicMap.topicMapName, propertyInstance.propertyInstanceKey)))\r\n sys.exit( 1)\r\n\r\n propertyClass = propertyInstance.propertyClass\r\n \r\n\r\n ## Remove old value from the "overhead" data for this property class\r\n if propertyClass.Remove__PropFromOverheadDictFArgString:\r\n execStr = \'propertyClass.Remove__PropFromOverheadDictF( vsv, propertyInstance, propertyClass.overheadDict, %25s)\' %25 (\r\n propertyClass.Remove__PropFromOverheadDictFArgString)\r\n exec execStr\r\n else:\r\n propertyClass.Remove__PropFromOverheadDictF( vsv, propertyInstance, propertyClass.overheadDict)\r\n\r\n ## Replace the proxyIdToReplace with the replacementProxyId\r\n oldValue = value%5b:%5d\r\n del value%5b:%5d\r\n for proxyId in oldValue:\r\n if proxyId == proxyIdToReplace:\r\n proxyId = replacementProxyId\r\n if proxyId not in value:\r\n value.append( proxyId)\r\n \r\n ## Expose the list of proxy references that appear in the value as a list of proxyIds\r\n propertyInstance.listOfIdsOfReferencedProxies = value\r\n ## happens to be a list, so use the same list\r\n\r\n\r\n ## Add new value to the "overhead" data for this property class\r\n if propertyClass.Add__PropToOverheadDictFArgString:\r\n execStr = \'propertyClass.Add__PropToOverheadDictF( vsv, propertyInstance, propertyClass.overheadDict, None, %25s)\' %25 (\r\n propertyClass.Add__PropToOverheadDictFArgString)\r\n exec execStr\r\n else:\r\n propertyClass.Add__PropToOverheadDictF( vsv, propertyInstance, propertyClass.overheadDict, None)\r\n\r\n'%0ap1%0a.S'#####################################################################\r\n#####################################################################\r\n## Versavant Topic Map Application Bus / Subject Addressing Engine ##\r\n## Copyright 2005 Steven R. Newcomb ##\r\n## ##\r\n## This software is licensed under the Apache License, Version 2.0 ##\r\n## (the "License"); you may not use this file except in compliance ##\r\n## with the License. Copies of the License are available at ##\r\n## http://www.apache.org/licenses/LICENSE-2.0 ##\r\n## ##\r\n## Unless required by applicable law or agreed to in writing, ##\r\n## software distributed under the License is distributed on an "AS ##\r\n## IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either ##\r\n## express or implied. See the License for the specific language ##\r\n## governing permissions and limitations under the License. ##\r\n## ##\r\n## Copies of the source code and the license are available at ##\r\n## http://www.versavant.org ##\r\n#####################################################################\r\n#####################################################################\r\n\r\n####################################\r\ncvsRevision = "$Revision: 1.9 $" ##\r\n####################################\r\n\r\n######################################################################################\r\n## A simple property class implementation for properties whose values are strings. ##\r\n######################################################################################\r\n\r\n#######################################################\r\ndef Add_string_PropToOverheadDict( vsv, propertyInstance, overheadDict, proxyIdMap):\r\n valueHash = propertyInstance.hashablePropertyValue = propertyInstance._value\r\n if overheadDict.has_key( valueHash):\r\n overheadDict%5b valueHash%5d.append( propertyInstance.proxyId)\r\n else:\r\n overheadDict%5b valueHash%5d = %5b propertyInstance.proxyId%5d\r\n\r\n\r\n#######################################################\r\ndef Remove_string_PropFromOverheadDict( vsv, propertyInstance, overheadDict):\r\n valueHash = propertyInstance.hashablePropertyValue\r\n overheadDict%5b valueHash%5d.remove( propertyInstance.proxyId)\r\n if not len( overheadDict%5b valueHash%5d):\r\n del overheadDict%5b valueHash%5d ## be a good citizen and clean up after yourself\r\n\r\n\r\n#######################################################\r\ndef Merge_string_PropertyValues( vsv, value1, value2):\r\n if value1 == value2:\r\n return value1\r\n else:\r\n return None ## the merge failed.\r\n\r\n#######################################################\r\ndef BOGUS_Merge_string_PropertyValues( vsv, value1, value2):\r\n return value1\r\n\r\n#######################################################\r\ndef ValuesOf_string_PropertyInstancesAreSignificantlyDifferent( vsv, value1, value2):\r\n if value1 == value2:\r\n return False\r\n else:\r\n return True \r\n\r\n#######################################################\r\ndef ProxiesOfSubjectIdentifiedBy_string_Value( vsv, propertyClass, value):\r\n if propertyClass.overheadDict.has_key( value):\r\n return propertyClass.overheadDict%5b value%5d\r\n else:\r\n return %5b%5d ## empty list -- no match\r\n\r\n#######################################################\r\ndef MergeProxiesBecause_string_PropertyInstancesSpecifySameSubject( vsv, propertyClass):\r\n ## Declare this one if and only if your property class is for SIPs\r\n ## (subject identity properties).\r\n\r\n for hashablePropertyValue in propertyClass.overheadDict:\r\n if len( propertyClass.overheadDict%5b hashablePropertyValue%5d) %3e 1:\r\n vsv.mergeListOfProxies( propertyClass, hashablePropertyValue, propertyClass.overheadDict%5b hashablePropertyValue%5d)\r\n \r\n'%0ap1%0a.S'#####################################################################\r\n#####################################################################\r\n## Versavant Topic Map Application Bus / Subject Addressing Engine ##\r\n## Copyright 2005 Steven R. Newcomb ##\r\n## ##\r\n## This software is licensed under the Apache License, Version 2.0 ##\r\n## (the "License"); you may not use this file except in compliance ##\r\n## with the License. Copies of the License are available at ##\r\n## http://www.apache.org/licenses/LICENSE-2.0 ##\r\n## ##\r\n## Unless required by applicable law or agreed to in writing, ##\r\n## software distributed under the License is distributed on an "AS ##\r\n## IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either ##\r\n## express or implied. See the License for the specific language ##\r\n## governing permissions and limitations under the License. ##\r\n## ##\r\n## Copies of the source code and the license are available at ##\r\n## http://www.versavant.org ##\r\n#####################################################################\r\n#####################################################################\r\n\r\n####################################\r\ncvsRevision = "$Revision: 1.8 $" ##\r\n####################################\r\n\r\n#######################################################################\r\n## This property class assumes a value type of lists whose items are ##\r\n## strings. However, they are treated as a set, not a list; their ##\r\n## order is not significant and redundant items will be ignored. ##\r\n## The value type implementation found in ##\r\n## versavant/Lib/VTstringSet.py can be used. ##\r\n## ##\r\n## * Subject sameness is having all the same items in both values. ##\r\n## ##\r\n## * If you desire any two values to be regarded as having the same ##\r\n## subject if they have one or more items in common, use the ##\r\n## variant functions with "anyMatch" in their names. ##\r\n#######################################################################\r\n\r\n###\r\nimport pdb, traceback\r\n###\r\n\r\n#######################################################\r\n## Subject sameness is sameness of the whole sets:\r\ndef Add_stringSet_PropToOverheadDict( vsv, propertyInstance, overheadDict, proxyIdMap):\r\n hashableValue = propertyInstance.hashablePropertyValue = frozenset( propertyInstance._value)\r\n if overheadDict.has_key( hashableValue):\r\n overheadDict%5b hashableValue%5d.append( propertyInstance.proxyId)\r\n else:\r\n overheadDict%5b hashableValue%5d = %5b propertyInstance.proxyId%5d\r\n\r\n#######################################################\r\n## Subject sameness is sameness of any item in the sets (intersection of sets is non-empty):\r\ndef Add_stringSet_anyMatch_PropToOverheadDict( vsv, propertyInstance, overheadDict, proxyIdMap):\r\n\r\n value = propertyInstance._value\r\n for item in value:\r\n if overheadDict.has_key( item):\r\n overheadDict%5b item%5d.append( propertyInstance.proxyId)\r\n else:\r\n overheadDict%5b item%5d = %5b propertyInstance.proxyId%5d\r\n\r\n\r\n#######################################################\r\ndef Remove_stringSet_PropFromOverheadDict( vsv, propertyInstance, overheadDict):\r\n## Subject sameness is sameness of the whole sets:\r\n hashableValue = propertyInstance.hashablePropertyValue\r\n overheadDict%5b hashableValue%5d.remove( propertyInstance.proxyId)\r\n if not len( overheadDict%5b hashableValue%5d):\r\n del overheadDict%5b hashableValue%5d\r\n\r\n#######################################################\r\ndef Remove_stringSet_anyMatch_PropFromOverheadDict( vsv, propertyInstance, overheadDict):\r\n## Subject sameness is sameness of any item in the sets (intersection of sets is non-empty):\r\n\r\n value = propertyInstance._value\r\n for item in value:\r\n try: ## because this is an anymatch situation, it may already have been removed.\r\n overheadDict%5b item%5d.remove( propertyInstance.proxyId)\r\n except:\r\n pass\r\n try:\r\n if not len( overheadDict%5b item%5d):\r\n try:\r\n del overheadDict%5b item%5d\r\n except:\r\n pass\r\n except:\r\n pass\r\n\r\n#######################################################\r\n## This works either way.\r\ndef Merge_stringSet_PropertyValues( vsv, value1, value2):\r\n newList = %5b%5d\r\n for stringItem in value1:\r\n if stringItem not in newList:\r\n newList.append( stringItem)\r\n for stringItem in value2:\r\n if stringItem not in newList:\r\n newList.append( stringItem)\r\n return newList\r\n\r\n#######################################################\r\n## This works either way.\r\ndef ValuesOf_stringSet_PropertyInstancesAreSignificantlyDifferent( vsv, value1, value2):\r\n if frozenset( value1) == frozenset( value2):\r\n return False\r\n else:\r\n return True \r\n\r\n#######################################################\r\ndef ProxiesOfSubjectIdentifiedBy_stringSet_Value( vsv, propertyClass, value):\r\n## Subject sameness is sameness of the whole set:\r\n fset = frozenset( value)\r\n if propertyClass.overheadDict.has_key( fset):\r\n return propertyClass.overheadDict%5b fset%5d\r\n else:\r\n return %5b%5d ## empty list -- no match\r\n\r\n#######################################################\r\ndef ProxiesOfSubjectIdentifiedBy_stringSet_anyMatch_Value( vsv, propertyClass, value):\r\n## Subject sameness is sameness of any item in the sets (intersection of sets is non-empty):\r\n proxyIdList = %5b%5d\r\n for item in value:\r\n if propertyClass.overheadDict.has_key( item):\r\n for proxyId in propertyClass.overheadDict%5b item%5d:\r\n if proxyId not in proxyIdList:\r\n proxyIdList.append( proxyId)\r\n return proxyIdList\r\n\r\n#######################################################\r\ndef MergeProxiesBecause_stringSet_PropertyInstancesSpecifySameSubject( vsv, propertyClass):\r\n## Subject sameness is sameness of the whole set:\r\n ## Declare this one if and only if your property class is for SIPs\r\n ## (subject identity properties).\r\n for hashablePropertyValue in propertyClass.overheadDict:\r\n if len( propertyClass.overheadDict%5b hashablePropertyValue%5d) %3e 1:\r\n vsv.mergeListOfProxies( propertyClass, hashablePropertyValue, propertyClass.overheadDict%5b hashablePropertyValue%5d)\r\n \r\n#######################################################\r\ndef MergeProxiesBecause_stringSet_anyMatch_PropertyInstancesSpecifySameSubject( vsv, propertyClass):\r\n## Subject sameness is sameness of any item in the sets (intersection of sets is non-empty):\r\n ## Declare this one if and only if your property class is for SIPs\r\n ## (subject identity properties).\r\n itemList = propertyClass.overheadDict.keys() ## stabilize what we\'re doing\r\n for item in itemList:\r\n if len( propertyClass.overheadDict%5b item%5d) %3e 1:\r\n vsv.mergeListOfProxies( propertyClass, item, propertyClass.overheadDict%5b item%5d)\r\n foundThingsToMerge = True\r\n\r\n\r\n'%0ap1%0a.S'#####################################################################\r\n#####################################################################\r\n## Versavant Topic Map Application Bus / Subject Addressing Engine ##\r\n## Copyright 2005 Steven R. Newcomb ##\r\n## ##\r\n## This software is licensed under the Apache License, Version 2.0 ##\r\n## (the "License"); you may not use this file except in compliance ##\r\n## with the License. Copies of the License are available at ##\r\n## http://www.apache.org/licenses/LICENSE-2.0 ##\r\n## ##\r\n## Unless required by applicable law or agreed to in writing, ##\r\n## software distributed under the License is distributed on an "AS ##\r\n## IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either ##\r\n## express or implied. See the License for the specific language ##\r\n## governing permissions and limitations under the License. ##\r\n## ##\r\n## Copies of the source code and the license are available at ##\r\n## http://www.versavant.org ##\r\n#####################################################################\r\n#####################################################################\r\n\r\n####################################\r\ncvsRevision = "$Revision: 1.10 $" ##\r\n####################################\r\n\r\n\r\n#############################################\r\n## "proxyIdList" value type implementation ##\r\n#############################################\r\n\r\n## This value type is useful for storing references to proxies,\r\n## regardless of whether they are treated by the property classes that\r\n## use this value type are lists or sets. For example, you should use\r\n## this "proxyIdList" value type for both "proxyIdSet"-type property\r\n## classes and "proxyIdList"-type property classes. At this level,\r\n## it doesn\'t matter.\r\n\r\n## Values are lists of proxyIds, i.e., proxy.proxyId values, which are\r\n## always strings of decimal digits that begin with two zeroes.\r\n\r\n## When you create other value types that contain proxy references,\r\n## you can use this implementation as a guide. It\'s tricky to\r\n## manage proxy references, not only because they die when merged, but\r\n## also because they can\'t possibly retain their original IDs when\r\n## they are imported.\r\n\r\n## NOTE: During importation of instances of this value type from XML,\r\n## some recordkeeping is done in vsv.currentTopicMapHoldingDict%5b\r\n## \'IoMapsDict\'%5d%5b (TMA name)%5d%5b propertyClassName%5d. \r\n\r\nimport types, traceback\r\n\r\n#######################################################\r\ndef ValueIsNotOfType_proxyIdList_(vsv, propertyValue, propertyClass, propertyInstance = None, **args):\r\n propertyClassName = propertyClass.propertyClassName\r\n topicMap = propertyClass.topicMap\r\n TMA = propertyClass.TMA\r\n TMAName = TMA.TMAName\r\n\r\n if not ( isinstance( propertyValue, types.ListType) or isinstance( propertyValue, types.TupleType)):\r\n traceback.print_stack()\r\n if propertyInstance:\r\n vsv.errMsg( \'Value "%25s" of property %25s is neither list nor tuple.\' %25 ( propertyValue, propertyInstance.propertyInstanceKey))\r\n else:\r\n vsv.errMsg( \'Value "%25s" of a prospective %25s property is neither list nor tuple.\' %25 ( propertyValue, vsv.catKey( TMAName, propertyClassName)))\r\n return True\r\n\r\n for proxyId in propertyValue:\r\n if not isinstance(proxyId, types.StringType):\r\n if propertyInstance:\r\n vsv.errMsg( \'At least one item ("%25s") in the value of property %25s is not a string.\' %25 ( proxyId, propertyInstance.propertyInstanceKey))\r\n else:\r\n vsv.errMsg( \'At least one item ("%25s") in the value of a presumptive %25s property is not a string.\' %25 ( proxyId, vsv.catKey( TMAName, propertyClassName)))\r\n return True\r\n if not vsv.proxyIdStrValidatorRE.match( proxyId):\r\n if propertyInstance:\r\n vsv.errMsg( \'An item ("%25s") in the value of property %25s does not look like a proxy identifier string.\' %25 ( proxyId, propertyInstance.propertyInstanceKey))\r\n else:\r\n vsv.errMsg( \'An item ("%25s") in the value of a presumptive %25s property does not look like a proxy identifier string.\' %25 ( proxyId, vsv.catKey( TMAName, propertyClassName)))\r\n return True\r\n\r\n proxy = vsv.isProxyId( proxyId, topicMap)\r\n if not proxy:\r\n if proxyId not in vsv.currentTopicMapHoldingDict%5b \'IoMapsDict\'%5d%5b \'TMAs\'%5d%5b propertyInstance.TMAName%5d%5b propertyClassName%5d:\r\n ## We\'re probably in the process of importing a topic map, and these are\r\n ## references to proxies that don\'t exist yet because they haven\'t been imported\r\n ## yet. The above check is supposed to calm our fears that this proxy reference\r\n ## is invalid, giving us reason to believe that it will soon be valid, even\r\n ## though it\'s not quite valid yet.\r\n\r\n if propertyInstance:\r\n errString = \'An item ("%25s") in the list is not the ID of any proxy in topic map "%25s".\' %25 ( proxyId, propertyInstance.topicMap.topicMapName)\r\n else:\r\n errString = \'An item ("%25s") in the list is not the ID of any proxy in any open topic map.\' %25 ( proxyId)\r\n vsv.errMsg( errString)\r\n return True\r\n if proxy:\r\n if proxy.forwardTo:\r\n vsv.errMsg( \'An item ("%25s") in the list that is the value of property %25s is the ID of a dead proxy. Only the IDs of living proxies are permitted.\' %25 ( proxyId, propertyInstance.topicMap.topicMapName))\r\n return True\r\n\r\n return False ## all\'s well, presumably. \r\n\r\n#######################################################\r\ndef ValueIsNotOfType_proxyIdAndNoneList_(vsv, propertyValue, propertyClass, propertyInstance = None, **args):\r\n propertyClassName = propertyClass.propertyClassName\r\n topicMap = propertyClass.topicMap\r\n TMA = propertyClass.TMA\r\n TMAName = TMA.TMAName\r\n\r\n if not ( isinstance( propertyValue, types.ListType) or isinstance( propertyValue, types.TupleType)):\r\n traceback.print_stack()\r\n if propertyInstance:\r\n vsv.errMsg( \'Value "%25s" of property %25s is neither list nor tuple.\' %25 ( propertyValue, propertyInstance.propertyInstanceKey))\r\n else:\r\n vsv.errMsg( \'Value "%25s" of a prospective %25s property is neither list nor tuple.\' %25 ( propertyValue, vsv.catKey( TMAName, propertyClassName)))\r\n return True\r\n\r\n for proxyId in propertyValue:\r\n\r\n if not ( isinstance( proxyId, types.StringType) or isinstance( proxyId, types.NoneType)):\r\n if propertyInstance:\r\n vsv.errMsg( \'At least one item ("%25s") in the value of property %25s is neither string nor None.\' %25 ( proxyId, propertyInstance.propertyInstanceKey))\r\n else:\r\n vsv.errMsg( \'At least one item ("%25s") in the value of a presumptive %25s property is neither string nor None.\' %25 ( proxyId, vsv.catKey( TMAName, propertyClassName)))\r\n return True\r\n\r\n if proxyId != None:\r\n if not vsv.proxyIdStrValidatorRE.match( proxyId):\r\n if propertyInstance:\r\n vsv.errMsg( \'A string ("%25s") in the value of property %25s does not look like a proxy identifier string.\' %25 ( proxyId, propertyInstance.propertyInstanceKey))\r\n else:\r\n vsv.errMsg( \'An string ("%25s") in the value of a presumptive %25s property does not look like a proxy identifier string.\' %25 ( proxyId, vsv.catKey( TMAName, propertyClassName)))\r\n return True\r\n\r\n if not topicMap.proxies.has_key( proxyId):\r\n if proxyId not in vsv.currentTopicMapHoldingDict%5b \'IoMapsDict\'%5d%5b \'TMAs\'%5d%5b propertyInstance.TMAName%5d%5b propertyClassName%5d:\r\n ## We\'re probably in the process of importing a topic map, and these are\r\n ## references to proxies that don\'t exist yet because they haven\'t been imported\r\n ## yet. The above check is supposed to calm our fears that this proxy reference\r\n ## is invalid, giving us reason to believe that it will soon be valid, even\r\n ## though it\'s not quite valid yet.\r\n\r\n if propertyInstance:\r\n errString = \'An item ("%25s") in the list is not the ID of any proxy in topic map "%25s".\' %25 ( proxyId, propertyInstance.topicMap.topicMapName)\r\n else:\r\n errString = \'An item ("%25s") in the list is not the ID of any proxy in any open topic map.\' %25 ( proxyId)\r\n vsv.errMsg( errString)\r\n return True\r\n else:\r\n proxy = topicMap.proxies%5b proxyId%5d\r\n if proxy.forwardTo:\r\n vsv.errMsg( \'An item ("%25s") in the list that is the value of property %25s is the ID of a dead proxy. Only the IDs of living proxies are permitted.\' %25 ( proxyId, propertyInstance.topicMap.topicMapName))\r\n return True\r\n\r\n return False ## all\'s well, presumably. \r\n\r\n#######################################################\r\ndef InstanceOf_proxyIdList_ValueTypeToXMLContentString(vsv, propertyInstance):\r\n return vsv.cPickleDumpObjectAsXMLContentString( propertyInstance._value)\r\n\r\n#######################################################\r\ndef XMLContentStringToInstanceOf_proxyIdList_ValueType(vsv, string, propertyClass, **args):\r\n ## Import a list of proxy references, adjusting them as necessary to\r\n ## the new proxyIds of the imported proxies to which they refer.\r\n\r\n oldProxyIdList = vsv.cPickleLoadObjectFromXMLContentString( string)\r\n\r\n mem2xmlProxyIdDict = vsv.currentTopicMapHoldingDict%5b \'IoMapsDict\'%5d%5b \'ProxyIds.mem2xml\'%5d\r\n ## This dictionary allows us to look up the in-xml element id of a\r\n ## proxy, given the proxy\'s proxyId as it was in the topic map\r\n ## from which the proxy was exported as xml.\r\n\r\n firstImportedProxyId = vsv.firstImportedProxyId\r\n ## This is an integer which, if we were to convert it into a\r\n ## string of decimal digits with 2 prepended zero characters,\r\n ## would be the proxyId of the first (the first, that is, not\r\n ## counting the proxies created in order to register the TMAs\r\n ## of the xml topic map being imported) in-memory proxy to be\r\n ## imported into the being-imported-into topic map from the\r\n ## xml topic map that we\'re importing.\r\n\r\n propertyClassName = propertyClass.propertyClassName\r\n TMAName = propertyClass.TMA.TMAName\r\n\r\n newProxyIdList = %5b%5d\r\n\r\n for oldProxyId in oldProxyIdList:\r\n xmlProxyNum = mem2xmlProxyIdDict%5b int( oldProxyId)%5d\r\n newProxyNum = (xmlProxyNum + firstImportedProxyId) - 1\r\n newProxyId = \'00%25s\' %25 ( newProxyNum)\r\n newProxyIdList.append( newProxyId)\r\n\r\n appDict = vsv.currentTopicMapHoldingDict%5b \'IoMapsDict\'%5d%5b \'TMAs\'%5d%5b TMAName%5d\r\n if not appDict.has_key( propertyClassName):\r\n appDict%5b propertyClassName%5d = %5b newProxyId%5d\r\n else:\r\n if newProxyId not in appDict%5b propertyClassName%5d:\r\n appDict%5b propertyClassName%5d.append( newProxyId)\r\n ## vsv.IoMapsDict%5b args%5b \'TMAName\'%5d%5d%5b propertyClassName%5d will be consulted by\r\n ## the ValueIsNotOfType__() function in order to avoid a logical logjam over this.\r\n ## The logical logjam is that we\'re referring to proxies that haven\'t been imported\r\n ## yet, and the ValueIsNotOfType__() function checks to see that the proxy references are valid.\r\n ## This gives the ValueIsNotOfType__() function something to fall back on, as it checks.\r\n ## See that function, above, for more.\r\n\r\n return newProxyIdList\r\n\r\n#######################################################\r\ndef InstanceOf_proxyIdListRaw_ValueTypeToXMLContentString(vsv, propertyInstance):\r\n return repr( propertyInstance._value)\r\n\r\n#######################################################\r\ndef XMLContentStringToInstanceOf_proxyIdListRaw_ValueType(vsv, string, propertyClass, **args):\r\n ## Import a list of proxy references, adjusting them as necessary to\r\n ## the new proxyIds of the imported proxies to which they refer.\r\n\r\n exec \'oldProxyIdList = %25s\' %25 ( string)\r\n\r\n mem2xmlProxyIdDict = vsv.currentTopicMapHoldingDict%5b \'IoMapsDict\'%5d%5b \'ProxyIds.mem2xml\'%5d\r\n ## This dictionary allows us to look up the in-xml element id of a\r\n ## proxy, given the proxy\'s proxyId as it was in the topic map\r\n ## from which the proxy was exported as xml.\r\n\r\n firstImportedProxyId = vsv.firstImportedProxyId\r\n ## This is an integer which, if we were to convert it into a\r\n ## string of decimal digits with 2 prepended zero characters,\r\n ## would be the proxyId of the first (the first, that is, not\r\n ## counting the proxies created in order to register the TMAs\r\n ## of the xml topic map being imported) in-memory proxy to be\r\n ## imported into the being-imported-into topic map from the\r\n ## xml topic map that we\'re importing.\r\n\r\n propertyClassName = propertyClass.propertyClassName\r\n TMAName = propertyClass.TMA.TMAName\r\n\r\n newProxyIdList = %5b%5d\r\n\r\n for oldProxyId in oldProxyIdList:\r\n if oldProxyId == None:\r\n newProxyIdList.append( None)\r\n else:\r\n xmlProxyNum = mem2xmlProxyIdDict%5b int( oldProxyId)%5d\r\n newProxyNum = (xmlProxyNum + firstImportedProxyId) - 1\r\n newProxyId = \'00%25s\' %25 ( newProxyNum)\r\n newProxyIdList.append( newProxyId)\r\n\r\n appDict = vsv.currentTopicMapHoldingDict%5b \'IoMapsDict\'%5d%5b \'TMAs\'%5d%5b TMAName%5d\r\n if not appDict.has_key( propertyClassName):\r\n appDict%5b propertyClassName%5d = %5b newProxyId%5d\r\n else:\r\n if newProxyId not in appDict%5b propertyClassName%5d:\r\n appDict%5b propertyClassName%5d.append( newProxyId)\r\n ## vsv.IoMapsDict%5b args%5b \'TMAName\'%5d%5d%5b propertyClassName%5d will be consulted by\r\n ## the ValueIsNotOfType__() function in order to avoid a logical logjam over this.\r\n ## The logical logjam is that we\'re referring to proxies that haven\'t been imported\r\n ## yet, and the ValueIsNotOfType__() function checks to see that the proxy references are valid.\r\n ## This gives the ValueIsNotOfType__() function something to fall back on, as it checks.\r\n ## See that function, above, for more.\r\n\r\n return newProxyIdList\r\n\r\n#######################################################\r\ndef InstanceOf_proxyIdListRaw_ValueTypeToXMLContentString(vsv, propertyInstance):\r\n return repr( propertyInstance._value)\r\n\r\n#######################################################\r\ndef XMLContentStringToInstanceOf_proxyIdOrNoneListRaw_ValueType(vsv, string, propertyClass, **args):\r\n ## Import a list of proxy references, adjusting them as necessary to\r\n ## the new proxyIds of the imported proxies to which they refer.\r\n\r\n exec \'oldProxyIdList = %25s\' %25 ( string)\r\n\r\n mem2xmlProxyIdDict = vsv.currentTopicMapHoldingDict%5b \'IoMapsDict\'%5d%5b \'ProxyIds.mem2xml\'%5d\r\n ## This dictionary allows us to look up the in-xml element id of a\r\n ## proxy, given the proxy\'s proxyId as it was in the topic map\r\n ## from which the proxy was exported as xml.\r\n\r\n firstImportedProxyId = vsv.firstImportedProxyId\r\n ## This is an integer which, if we were to convert it into a\r\n ## string of decimal digits with 2 prepended zero characters,\r\n ## would be the proxyId of the first (the first, that is, not\r\n ## counting the proxies created in order to register the TMAs\r\n ## of the xml topic map being imported) in-memory proxy to be\r\n ## imported into the being-imported-into topic map from the\r\n ## xml topic map that we\'re importing.\r\n\r\n propertyClassName = propertyClass.propertyClassName\r\n TMAName = propertyClass.TMA.TMAName\r\n\r\n newProxyIdList = %5b%5d\r\n\r\n for oldProxyId in oldProxyIdList:\r\n if oldProxyId != None:\r\n xmlProxyNum = mem2xmlProxyIdDict%5b int( oldProxyId)%5d\r\n newProxyNum = (xmlProxyNum + firstImportedProxyId) - 1\r\n newProxyId = \'00%25s\' %25 ( newProxyNum)\r\n newProxyIdList.append( newProxyId)\r\n\r\n appDict = vsv.currentTopicMapHoldingDict%5b \'IoMapsDict\'%5d%5b \'TMAs\'%5d%5b TMAName%5d\r\n if not appDict.has_key( propertyClassName):\r\n appDict%5b propertyClassName%5d = %5b newProxyId%5d\r\n else:\r\n if newProxyId not in appDict%5b propertyClassName%5d:\r\n appDict%5b propertyClassName%5d.append( newProxyId)\r\n ## vsv.IoMapsDict%5b args%5b \'TMAName\'%5d%5d%5b propertyClassName%5d will be consulted by\r\n ## the ValueIsNotOfType__() function in order to avoid a logical logjam over this.\r\n ## The logical logjam is that we\'re referring to proxies that haven\'t been imported\r\n ## yet, and the ValueIsNotOfType__() function checks to see that the proxy references are valid.\r\n ## This gives the ValueIsNotOfType__() function something to fall back on, as it checks.\r\n ## See that function, above, for more.\r\n\r\n else:\r\n newProxyIdList.append( None)\r\n\r\n return newProxyIdList\r\n\r\n'%0ap1%0a.S'#####################################################################\r\n#####################################################################\r\n## Versavant Topic Map Application Bus / Subject Addressing Engine ##\r\n## Copyright 2005 Steven R. Newcomb ##\r\n## ##\r\n## This software is licensed under the Apache License, Version 2.0 ##\r\n## (the "License"); you may not use this file except in compliance ##\r\n## with the License. Copies of the License are available at ##\r\n## http://www.apache.org/licenses/LICENSE-2.0 ##\r\n## ##\r\n## Unless required by applicable law or agreed to in writing, ##\r\n## software distributed under the License is distributed on an "AS ##\r\n## IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either ##\r\n## express or implied. See the License for the specific language ##\r\n## governing permissions and limitations under the License. ##\r\n## ##\r\n## Copies of the source code and the license are available at ##\r\n## http://www.versavant.org ##\r\n#####################################################################\r\n#####################################################################\r\n\r\n####################################\r\ncvsRevision = "$Revision: 1.7 $" ##\r\n####################################\r\n\r\n\r\n################################################################\r\n## This simple value type is for strings. ##\r\n## They will be stored in pickled form ##\r\n## in the XML file. (See below for raw storage and unicode.) ##\r\n################################################################\r\n\r\nimport types\r\n\r\n#######################################################\r\ndef ValueIsNotOfType_string_( vsv, propertyValue, propertyClass, propertyInstance = None):\r\n if not ( isinstance( propertyValue, types.StringType) or isinstance( propertyValue, types.UnicodeType)):\r\n vsv.errMsg( \'Value "%25s" is neither a string nor a unicode; it\\\'s a %25s.\' %25 ( propertyValue, type( propertyValue)))\r\n return True\r\n return False\r\n\r\n#######################################################\r\ndef InstanceOf_string_ValueTypeToXMLContentString( vsv, propertyInstance):\r\n return vsv.cPickleDumpObjectAsXMLContentString( propertyInstance._value)\r\n\r\n#######################################################\r\ndef XMLContentStringToInstanceOf_string_ValueType( vsv, string, propertyClass):\r\n return vsv.cPickleLoadObjectFromXMLContentString( string)\r\n\r\n\r\n#######################################################\r\ndef InstanceOf_stringRaw_ValueTypeToXMLContentString( vsv, propertyInstance):\r\n return propertyInstance._value.replace( \'%3c\', \'%25.LT.%25\').replace( \'%3e\', \'%25.GT.%25\')\r\n\r\n#######################################################\r\ndef XMLContentStringToInstanceOf_stringRaw_ValueType( vsv, string, propertyClass):\r\n return string.replace( \'%25.LT.%25\', \'%3c\').replace( \'%25.GT.%25\', \'%3e\')\r\n\r\n######################################################################\r\n## Use these for string values that need to be directly editable in ##\r\n## the interchangeable XML file. This avoids pickling/unpickling, ##\r\n## allowing the strings to appear "in the raw" in the file. ##\r\n######################################################################\r\ndef ValueIsNotOfType_rawString_( vsv, propertyValue, propertyClass, propertyInstance = None):\r\n if not isinstance( propertyValue, types.StringType):\r\n vsv.errMsg( \'Value "%25s" is not a string, it is a %25s.\' %25 ( propertyValue, type( propertyValue)))\r\n return True\r\n return False\r\n\r\n#######################################################\r\ndef InstanceOf_rawString_ValueTypeToXMLContentString( vsv, propertyInstance):\r\n return propertyInstance._value.replace( \'%26\', \'%26amp;\').replace( \'%3c\', \'%26lt;\').replace( \'%3e\', \'%26gt;\').encode( \'utf-8\')\r\n\r\n#######################################################\r\ndef XMLContentStringToInstanceOf_rawString_ValueType( vsv, string, propertyClass):\r\n return string.replace( \'%26lt;\', \'%3c\').replace( \'%26gt;\', \'%3e\').replace( \'%26amp;\', \'%26\').encode( \'ASCII\')\r\n\r\n\r\n\r\n\r\n## Unicode version, with pickling. ##\r\n#######################################################\r\ndef ValueIsNotOfType_unicodeString_( vsv, propertyValue, propertyClass, propertyInstance = None):\r\n if not isinstance( propertyValue, types.UnicodeType):\r\n vsv.errMsg( \'Value "%25s" is not a Unicode string.\' %25 ( propertyValue))\r\n return True\r\n return False\r\n\r\n#######################################################\r\ndef InstanceOf_unicodeString_ValueTypeToXMLContentString( vsv, propertyInstance):\r\n return vsv.cPickleDumpObjectAsXMLContentString( propertyInstance._value)\r\n\r\n#######################################################\r\ndef XMLContentStringToInstanceOf_unicodeString_ValueType( vsv, string, propertyClass):\r\n return vsv.cPickleLoadObjectFromXMLContentString( string)\r\n\r\n\r\n## Unicode version, no pickling (raw). ##\r\n######################################################################\r\n## Use these for string values that need to be directly editable in ##\r\n## the interchangeable XML file. This avoids pickling/unpickling, ##\r\n## allowing the strings to appear "in the raw" in the file. ##\r\n######################################################################\r\ndef ValueIsNotOfType_rawUnicodeString_( vsv, propertyValue, propertyClass, propertyInstance = None):\r\n if not ( isinstance( propertyValue, types.UnicodeType) or isinstance( propertyValue, types.StringType)):\r\n vsv.errMsg( \'Value "%25s" is neither a %3ctype \\\'unicode\\\'%3e nor a %3ctype \\\'str\\\'%3e; it\\\'s a %25s.\' %25 ( propertyValue, type( propertyValue)))\r\n return True\r\n return False\r\n\r\n#######################################################\r\ndef InstanceOf_rawUnicodeString_ValueTypeToXMLContentString( vsv, propertyInstance):\r\n## return propertyInstance._value.replace( u\'%26\', u\'VSV-ENTITY-amp\').replace( u\'%3c\', u\'%26lt;\').replace( u\'%3e\', u\'%26gt;\')\r\n return vsv.pickleStringXMLEscapify( propertyInstance._value)\r\n\r\n#######################################################\r\ndef XMLContentStringToInstanceOf_rawUnicodeString_ValueType( vsv, string, propertyClass):\r\n## return string.replace( u\'%26lt;\', u\'%3c\').replace( u\'%26gt;\', u\'%3e\').replace( u\'VSV-ENTITY-amp\', u\'%26\')\r\n return vsv.pickleStringXMLUnescapify( string)\r\n\r\n'%0ap1%0a.S'#####################################################################\r\n#####################################################################\r\n## Versavant Topic Map Application Bus / Subject Addressing Engine ##\r\n## Copyright 2005 Steven R. Newcomb ##\r\n## ##\r\n## This software is licensed under the Apache License, Version 2.0 ##\r\n## (the "License"); you may not use this file except in compliance ##\r\n## with the License. Copies of the License are available at ##\r\n## http://www.apache.org/licenses/LICENSE-2.0 ##\r\n## ##\r\n## Unless required by applicable law or agreed to in writing, ##\r\n## software distributed under the License is distributed on an "AS ##\r\n## IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either ##\r\n## express or implied. See the License for the specific language ##\r\n## governing permissions and limitations under the License. ##\r\n## ##\r\n## Copies of the source code and the license are available at ##\r\n## http://www.versavant.org ##\r\n#####################################################################\r\n#####################################################################\r\n\r\n####################################\r\ncvsRevision = "$Revision: 1.7 $" ##\r\n####################################\r\n\r\n\r\n##############################################\r\n## This value type is for lists of strings. ##\r\n##############################################\r\n\r\nimport types\r\n\r\n#######################################################\r\ndef ValueIsNotOfType_stringList_( vsv, propertyValue, propertyClass, propertyInstance = None):\r\n if not isinstance( propertyValue, types.ListType):\r\n vsv.errMsg( \'Value "%25s" is not a list.\' %25 propertyValue)\r\n return True\r\n for item in propertyValue:\r\n if not isinstance( item, types.StringType):\r\n vsv.errMsg( \'Item ("%25s") in value "%25s" is not a string.\' %25 ( item, propertyValue))\r\n return True\r\n return False\r\n\r\n#######################################################\r\ndef InstanceOf_stringList_ValueTypeToXMLContentString( vsv, propertyInstance):\r\n return vsv.cPickleDumpObjectAsXMLContentString( propertyInstance._value)\r\n\r\n#######################################################\r\ndef XMLContentStringToInstanceOf_stringList_ValueType( vsv, string, propertyClass):\r\n return vsv.cPickleLoadObjectFromXMLContentString( string)\r\n\r\n\r\n##############################\r\n## Lists of Unicode strings ##\r\n##############################\r\n\r\n#######################################################\r\ndef ValueIsNotOfType_unicodeStringList_( vsv, propertyValue, propertyClass, propertyInstance = None):\r\n if not isinstance( propertyValue, types.ListType):\r\n vsv.errMsg( \'Value "%25s" is not a list.\' %25 propertyValue)\r\n return True\r\n for item in propertyValue:\r\n if not isinstance( item, types.UnicodeType):\r\n vsv.errMsg( \'Item ("%25s") in value "%25s" is not a Unicode string.\' %25 ( item, propertyValue))\r\n return True\r\n return False\r\n\r\n\r\n\r\n##################################\r\n## Lists of raw strings ##\r\n##################################\r\n\r\n#######################################################\r\ndef InstanceOf_rawStringList_ValueTypeToXMLContentString( vsv, propertyInstance):\r\n return repr( propertyInstance._value)\r\n\r\n#######################################################\r\ndef XMLContentStringToInstanceOf_rawStringList_ValueType( vsv, string, propertyClass):\r\n exec \'stringList = %25s\' %25 ( string)\r\n return stringList\r\n\r\n##################################\r\n## Lists of raw Unicode strings ##\r\n##################################\r\n\r\n#######################################################\r\ndef InstanceOf_rawUnicodeStringList_ValueTypeToXMLContentString( vsv, propertyInstance):\r\n return vsv.pickleStringXMLEscapify( repr( propertyInstance._value))\r\n\r\n#######################################################\r\ndef XMLContentStringToInstanceOf_rawUnicodeStringList_ValueType( vsv, string, propertyClass):\r\n exec \'unicodeStringList = %25s\' %25 ( vsv.pickleStringXMLUnescapify( string))\r\n return unicodeStringList\r\n\r\n'%0ap1%0a.S'uod1'%0ap1%0a.S'uod1.xml'%0ap1%0a.S'Universe of Discourse (UoD) for EMAIL subjects.'%0ap1%0a.N.(dp1%0a.(dp1%0aS'emailID'%0ap2%0aNsS'inReplyTo'%0ap3%0aNsS'sender'%0ap4%0aNsS'emailSubjectLines'%0ap5%0aNsS'subjectLine'%0ap6%0aNsS'previousInThread'%0ap7%0aNsS'content'%0ap8%0aNsS'firstEmail'%0ap9%0aNsS'nextInThread'%0ap10%0aNsS'date'%0ap11%0aNsS'emails'%0ap12%0aNsS'personNames'%0ap13%0aNsS'threadStart'%0ap14%0aNs.N.(dp1%0aS'rawUnicodeStringList'%0ap2%0aNsS'rawProxyIdList'%0ap3%0aNsS'rawUnicodeString'%0ap4%0aNs.S'uod1,,rawProxyIdList'%0ap1%0a.N.S''%0a.S'001_VTproxyIdList.py'%0ap1%0a.S'001_VTproxyIdList'%0ap1%0a.S'InstanceOf_proxyIdListRaw_ValueTypeToXMLContentString'%0ap1%0a.S'General-purpose list-of-subject-proxies value type.'%0ap1%0a.S'rawProxyIdList'%0ap1%0a.S'uod1'%0ap1%0a.N.S''%0a.S'001_VTproxyIdList.py'%0ap1%0a.S'001_VTproxyIdList'%0ap1%0a.S'ValueIsNotOfType_proxyIdList_'%0ap1%0a.N.S''%0a.S'001_VTproxyIdList.py'%0ap1%0a.S'001_VTproxyIdList'%0ap1%0a.S'XMLContentStringToInstanceOf_proxyIdListRaw_ValueType'%0ap1%0a.S'uod1,,rawUnicodeString'%0ap1%0a.N.S''%0a.S'001_VTstring.py'%0ap1%0a.S'001_VTstring'%0ap1%0a.S'InstanceOf_rawUnicodeString_ValueTypeToXMLContentString'%0ap1%0a.S'General-purpose Unicode string value type.'%0ap1%0a.S'rawUnicodeString'%0ap1%0a.S'uod1'%0ap1%0a.N.S''%0a.S'001_VTstring.py'%0ap1%0a.S'001_VTstring'%0ap1%0a.S'ValueIsNotOfType_rawUnicodeString_'%0ap1%0a.N.S''%0a.S'001_VTstring.py'%0ap1%0a.S'001_VTstring'%0ap1%0a.S'XMLContentStringToInstanceOf_rawUnicodeString_ValueType'%0ap1%0a.S'uod1,,rawUnicodeStringList'%0ap1%0a.N.S''%0a.S'001_VTstringList.py'%0ap1%0a.S'001_VTstringList'%0ap1%0a.S'InstanceOf_rawUnicodeStringList_ValueTypeToXMLContentString'%0ap1%0a.S'General-purpose value type that is a list of raw Unicode strings.'%0ap1%0a.S'rawUnicodeStringList'%0ap1%0a.S'uod1'%0ap1%0a.N.S''%0a.S'001_VTstringList.py'%0ap1%0a.S'001_VTstringList'%0ap1%0a.S'ValueIsNotOfType_unicodeStringList_'%0ap1%0a.N.S''%0a.S'001_VTstringList.py'%0ap1%0a.S'001_VTstringList'%0ap1%0a.S'XMLContentStringToInstanceOf_rawUnicodeStringList_ValueType'%0ap1%0a.S'uod1,,personNames'%0ap1%0a.N.S''%0a.S'001_PCstringSet.py'%0ap1%0a.S'001_PCstringSet'%0ap1%0a.S'Add_stringSet_anyMatch_PropToOverheadDict'%0ap1%0a.N.S''%0a.S'001_PCstringSet.py'%0ap1%0a.S'001_PCstringSet'%0ap1%0a.S'MergeProxiesBecause_stringSet_anyMatch_PropertyInstancesSpecifySameSubject'%0ap1%0a.N.S''%0a.S'001_PCstringSet.py'%0ap1%0a.S'001_PCstringSet'%0ap1%0a.S'Merge_stringSet_PropertyValues'%0ap1%0a.S"SIP for persons; each item is a name for the person; if any name matches, it's the same subject."%0ap1%0a.S'rawUnicodeStringList'%0ap1%0a.N.S''%0a.S'001_PCstringSet.py'%0ap1%0a.S'001_PCstringSet'%0ap1%0a.S'ProxiesOfSubjectIdentifiedBy_stringSet_anyMatch_Value'%0ap1%0a.N.S''%0a.S'001_PCstringSet.py'%0ap1%0a.S'001_PCstringSet'%0ap1%0a.S'Remove_stringSet_anyMatch_PropFromOverheadDict'%0ap1%0a.N.S''%0a.S'001_PCstringSet.py'%0ap1%0a.S'001_PCstringSet'%0ap1%0a.S'ValuesOf_stringSet_PropertyInstancesAreSignificantlyDifferent'%0ap1%0a.N.S'personNames'%0ap1%0a.N.N.S'uod1'%0ap1%0a.N.N.S'uod1,,emails'%0ap1%0a.N.S''%0a.S'001_PCproxyIdSet.py'%0ap1%0a.S'001_PCproxyIdSet'%0ap1%0a.S'Add_proxyIdSet_PropToOverheadDict'%0ap1%0a.N.S''%0a.S'001_PCproxyIdSet.py'%0ap1%0a.S'001_PCproxyIdSet'%0ap1%0a.S'Merge_accumulatingProxyIdSet_PropertyValues'%0ap1%0a.S'Set of emails.'%0ap1%0a.S'rawProxyIdList'%0ap1%0a.N.S''%0a.S'001_PCproxyIdSet.py'%0ap1%0a.S'001_PCproxyIdSet'%0ap1%0a.S'ProxiesOfSubjectIdentifiedBy_proxyIdSet_Value'%0ap1%0a.N.S''%0a.S'001_PCproxyIdSet.py'%0ap1%0a.S'001_PCproxyIdSet'%0ap1%0a.S'Remove_proxyIdSet_PropFromOverheadDict'%0ap1%0a.N.S''%0a.S'001_PCproxyIdSet.py'%0ap1%0a.S'001_PCproxyIdSet'%0ap1%0a.S'UpdateProxyReferencesIn_proxyIdSet_Value'%0ap1%0a.N.S''%0a.S'001_PCproxyIdSet.py'%0ap1%0a.S'001_PCproxyIdSet'%0ap1%0a.S'ValuesOf_proxyIdSet_PropertyInstancesAreSignificantlyDifferent'%0ap1%0a.N.S'emails'%0ap1%0a.N.N.S'uod1'%0ap1%0a.S'uod1,,emailSubjectLines'%0ap1%0a.N.S''%0a.S'001_PCproxyIdSet.py'%0ap1%0a.S'001_PCproxyIdSet'%0ap1%0a.S'Add_proxyIdSet_PropToOverheadDict'%0ap1%0a.N.S''%0a.S'001_PCproxyIdSet.py'%0ap1%0a.S'001_PCproxyIdSet'%0ap1%0a.S'Merge_accumulatingProxyIdSet_PropertyValues'%0ap1%0a.S'Set of email subject lines.'%0ap1%0a.S'rawProxyIdList'%0ap1%0a.N.S''%0a.S'001_PCproxyIdSet.py'%0ap1%0a.S'001_PCproxyIdSet'%0ap1%0a.S'ProxiesOfSubjectIdentifiedBy_proxyIdSet_Value'%0ap1%0a.N.S''%0a.S'001_PCproxyIdSet.py'%0ap1%0a.S'001_PCproxyIdSet'%0ap1%0a.S'Remove_proxyIdSet_PropFromOverheadDict'%0ap1%0a.N.S''%0a.S'001_PCproxyIdSet.py'%0ap1%0a.S'001_PCproxyIdSet'%0ap1%0a.S'UpdateProxyReferencesIn_proxyIdSet_Value'%0ap1%0a.N.S''%0a.S'001_PCproxyIdSet.py'%0ap1%0a.S'001_PCproxyIdSet'%0ap1%0a.S'ValuesOf_proxyIdSet_PropertyInstancesAreSignificantlyDifferent'%0ap1%0a.N.S'emailSubjectLines'%0ap1%0a.N.N.S'uod1'%0ap1%0a.S'uod1,,emailID'%0ap1%0a.N.S''%0a.S'001_PCstring.py'%0ap1%0a.S'001_PCstring'%0ap1%0a.S'Add_string_PropToOverheadDict'%0ap1%0a.N.S''%0a.S'001_PCstring.py'%0ap1%0a.S'001_PCstring'%0ap1%0a.S'MergeProxiesBecause_string_PropertyInstancesSpecifySameSubject'%0ap1%0a.N.S''%0a.S'001_PCstring.py'%0ap1%0a.S'001_PCstring'%0ap1%0a.S'Merge_string_PropertyValues'%0ap1%0a.S'SIP for emails; values are email "Message-ID:s".'%0ap1%0a.S'rawUnicodeString'%0ap1%0a.N.S''%0a.S'001_PCstring.py'%0ap1%0a.S'001_PCstring'%0ap1%0a.S'ProxiesOfSubjectIdentifiedBy_string_Value'%0ap1%0a.N.S''%0a.S'001_PCstring.py'%0ap1%0a.S'001_PCstring'%0ap1%0a.S'Remove_string_PropFromOverheadDict'%0ap1%0a.N.S''%0a.S'001_PCstring.py'%0ap1%0a.S'001_PCstring'%0ap1%0a.S'ValuesOf_string_PropertyInstancesAreSignificantlyDifferent'%0ap1%0a.N.S'emailID'%0ap1%0a.N.N.S'uod1'%0ap1%0a.N.N.S'uod1,,sender'%0ap1%0a.N.S''%0a.S'001_PCproxyIdSet.py'%0ap1%0a.S'001_PCproxyIdSet'%0ap1%0a.S'Add_proxyIdSet_PropToOverheadDict'%0ap1%0a.N.S''%0a.S'001_PCproxyIdSet.py'%0ap1%0a.S'001_PCproxyIdSet'%0ap1%0a.S'Merge_proxyIdSet_PropertyValues'%0ap1%0a.S'Reference to a sender (a person) of an email.'%0ap1%0a.S'rawProxyIdList'%0ap1%0a.N.S''%0a.S'001_PCproxyIdSet.py'%0ap1%0a.S'001_PCproxyIdSet'%0ap1%0a.S'ProxiesOfSubjectIdentifiedBy_proxyIdSet_Value'%0ap1%0a.N.S''%0a.S'001_PCproxyIdSet.py'%0ap1%0a.S'001_PCproxyIdSet'%0ap1%0a.S'Remove_proxyIdSet_PropFromOverheadDict'%0ap1%0a.N.S''%0a.S'001_PCproxyIdSet.py'%0ap1%0a.S'001_PCproxyIdSet'%0ap1%0a.S'UpdateProxyReferencesIn_proxyIdSet_Value'%0ap1%0a.N.S''%0a.S'001_PCproxyIdSet.py'%0ap1%0a.S'001_PCproxyIdSet'%0ap1%0a.S'ValuesOf_proxyIdSet_PropertyInstancesAreSignificantlyDifferent'%0ap1%0a.N.S'sender'%0ap1%0a.N.N.S'uod1'%0ap1%0a.S'uod1,,subjectLine'%0ap1%0a.N.S''%0a.S'001_PCproxyIdSet.py'%0ap1%0a.S'001_PCproxyIdSet'%0ap1%0a.S'Add_proxyIdSet_PropToOverheadDict'%0ap1%0a.N.S''%0a.S'001_PCproxyIdSet.py'%0ap1%0a.S'001_PCproxyIdSet'%0ap1%0a.S'Merge_accumulatingProxyIdSet_PropertyValues'%0ap1%0a.S'Reference to proxy for a subject line.'%0ap1%0a.S'rawProxyIdList'%0ap1%0a.N.S''%0a.S'001_PCproxyIdSet.py'%0ap1%0a.S'001_PCproxyIdSet'%0ap1%0a.S'ProxiesOfSubjectIdentifiedBy_proxyIdSet_Value'%0ap1%0a.N.S''%0a.S'001_PCproxyIdSet.py'%0ap1%0a.S'001_PCproxyIdSet'%0ap1%0a.S'Remove_proxyIdSet_PropFromOverheadDict'%0ap1%0a.N.S''%0a.S'001_PCproxyIdSet.py'%0ap1%0a.S'001_PCproxyIdSet'%0ap1%0a.S'UpdateProxyReferencesIn_proxyIdSet_Value'%0ap1%0a.N.S''%0a.S'001_PCproxyIdSet.py'%0ap1%0a.S'001_PCproxyIdSet'%0ap1%0a.S'ValuesOf_proxyIdSet_PropertyInstancesAreSignificantlyDifferent'%0ap1%0a.N.S'subjectLine'%0ap1%0a.N.N.S'uod1'%0ap1%0a.S'uod1,,inReplyTo'%0ap1%0a.N.S''%0a.S'001_PCproxyIdSet.py'%0ap1%0a.S'001_PCproxyIdSet'%0ap1%0a.S'Add_proxyIdSet_PropToOverheadDict'%0ap1%0a.N.S''%0a.S'001_PCproxyIdSet.py'%0ap1%0a.S'001_PCproxyIdSet'%0ap1%0a.S'Merge_proxyIdSet_PropertyValues'%0ap1%0a.S'Reference to the email, if any, to which this email is a reply.'%0ap1%0a.S'rawProxyIdList'%0ap1%0a.N.S''%0a.S'001_PCproxyIdSet.py'%0ap1%0a.S'001_PCproxyIdSet'%0ap1%0a.S'ProxiesOfSubjectIdentifiedBy_proxyIdSet_Value'%0ap1%0a.N.S''%0a.S'001_PCproxyIdSet.py'%0ap1%0a.S'001_PCproxyIdSet'%0ap1%0a.S'Remove_proxyIdSet_PropFromOverheadDict'%0ap1%0a.N.S''%0a.S'001_PCproxyIdSet.py'%0ap1%0a.S'001_PCproxyIdSet'%0ap1%0a.S'UpdateProxyReferencesIn_proxyIdSet_Value'%0ap1%0a.N.S''%0a.S'001_PCproxyIdSet.py'%0ap1%0a.S'001_PCproxyIdSet'%0ap1%0a.S'ValuesOf_proxyIdSet_PropertyInstancesAreSignificantlyDifferent'%0ap1%0a.N.S'inReplyTo'%0ap1%0a.N.N.S'uod1'%0ap1%0a.S'uod1,,previousInThread'%0ap1%0a.N.S''%0a.S'001_PCproxyIdSet.py'%0ap1%0a.S'001_PCproxyIdSet'%0ap1%0a.S'Add_proxyIdSet_PropToOverheadDict'%0ap1%0a.N.S''%0a.S'001_PCproxyIdSet.py'%0ap1%0a.S'001_PCproxyIdSet'%0ap1%0a.S'Merge_proxyIdSet_PropertyValues'%0ap1%0a.S'Reference to the email that appears previous to this one in the same thread, if any.'%0ap1%0a.S'rawProxyIdList'%0ap1%0a.N.S''%0a.S'001_PCproxyIdSet.py'%0ap1%0a.S'001_PCproxyIdSet'%0ap1%0a.S'ProxiesOfSubjectIdentifiedBy_proxyIdSet_Value'%0ap1%0a.N.S''%0a.S'001_PCproxyIdSet.py'%0ap1%0a.S'001_PCproxyIdSet'%0ap1%0a.S'Remove_proxyIdSet_PropFromOverheadDict'%0ap1%0a.N.S''%0a.S'001_PCproxyIdSet.py'%0ap1%0a.S'001_PCproxyIdSet'%0ap1%0a.S'UpdateProxyReferencesIn_proxyIdSet_Value'%0ap1%0a.N.S''%0a.S'001_PCproxyIdSet.py'%0ap1%0a.S'001_PCproxyIdSet'%0ap1%0a.S'ValuesOf_proxyIdSet_PropertyInstancesAreSignificantlyDifferent'%0ap1%0a.N.S'previousInThread'%0ap1%0a.N.N.S'uod1'%0ap1%0a.S'uod1,,nextInThread'%0ap1%0a.N.S''%0a.S'001_PCproxyIdSet.py'%0ap1%0a.S'001_PCproxyIdSet'%0ap1%0a.S'Add_proxyIdSet_PropToOverheadDict'%0ap1%0a.N.S''%0a.S'001_PCproxyIdSet.py'%0ap1%0a.S'001_PCproxyIdSet'%0ap1%0a.S'Merge_proxyIdSet_PropertyValues'%0ap1%0a.S'Reference to the email that appears next in the same thread, if any.'%0ap1%0a.S'rawProxyIdList'%0ap1%0a.N.S''%0a.S'001_PCproxyIdSet.py'%0ap1%0a.S'001_PCproxyIdSet'%0ap1%0a.S'ProxiesOfSubjectIdentifiedBy_proxyIdSet_Value'%0ap1%0a.N.S''%0a.S'001_PCproxyIdSet.py'%0ap1%0a.S'001_PCproxyIdSet'%0ap1%0a.S'Remove_proxyIdSet_PropFromOverheadDict'%0ap1%0a.N.S''%0a.S'001_PCproxyIdSet.py'%0ap1%0a.S'001_PCproxyIdSet'%0ap1%0a.S'UpdateProxyReferencesIn_proxyIdSet_Value'%0ap1%0a.N.S''%0a.S'001_PCproxyIdSet.py'%0ap1%0a.S'001_PCproxyIdSet'%0ap1%0a.S'ValuesOf_proxyIdSet_PropertyInstancesAreSignificantlyDifferent'%0ap1%0a.N.S'nextInThread'%0ap1%0a.N.N.S'uod1'%0ap1%0a.S'uod1,,threadStart'%0ap1%0a.N.S''%0a.S'001_PCproxyIdSet.py'%0ap1%0a.S'001_PCproxyIdSet'%0ap1%0a.S'Add_proxyIdSet_PropToOverheadDict'%0ap1%0a.N.S''%0a.S'001_PCproxyIdSet.py'%0ap1%0a.S'001_PCproxyIdSet'%0ap1%0a.S'Merge_proxyIdSet_PropertyValues'%0ap1%0a.S'Reference to the email starting this thread, if not the same as this email.'%0ap1%0a.S'rawProxyIdList'%0ap1%0a.N.S''%0a.S'001_PCproxyIdSet.py'%0ap1%0a.S'001_PCproxyIdSet'%0ap1%0a.S'ProxiesOfSubjectIdentifiedBy_proxyIdSet_Value'%0ap1%0a.N.S''%0a.S'001_PCproxyIdSet.py'%0ap1%0a.S'001_PCproxyIdSet'%0ap1%0a.S'Remove_proxyIdSet_PropFromOverheadDict'%0ap1%0a.N.S''%0a.S'001_PCproxyIdSet.py'%0ap1%0a.S'001_PCproxyIdSet'%0ap1%0a.S'UpdateProxyReferencesIn_proxyIdSet_Value'%0ap1%0a.N.S''%0a.S'001_PCproxyIdSet.py'%0ap1%0a.S'001_PCproxyIdSet'%0ap1%0a.S'ValuesOf_proxyIdSet_PropertyInstancesAreSignificantlyDifferent'%0ap1%0a.N.S'threadStart'%0ap1%0a.N.N.S'uod1'%0ap1%0a.S'uod1,,content'%0ap1%0a.N.S''%0a.S'001_PCstring.py'%0ap1%0a.S'001_PCstring'%0ap1%0a.S'Add_string_PropToOverheadDict'%0ap1%0a.N.S''%0a.S'001_PCstring.py'%0ap1%0a.S'001_PCstring'%0ap1%0a.S'BOGUS_Merge_string_PropertyValues'%0ap1%0a.S'Entire content of email.'%0ap1%0a.S'rawUnicodeString'%0ap1%0a.N.S''%0a.S'001_PCstring.py'%0ap1%0a.S'001_PCstring'%0ap1%0a.S'ProxiesOfSubjectIdentifiedBy_string_Value'%0ap1%0a.N.S''%0a.S'001_PCstring.py'%0ap1%0a.S'001_PCstring'%0ap1%0a.S'Remove_string_PropFromOverheadDict'%0ap1%0a.N.S''%0a.S'001_PCstring.py'%0ap1%0a.S'001_PCstring'%0ap1%0a.S'ValuesOf_string_PropertyInstancesAreSignificantlyDifferent'%0ap1%0a.N.S'content'%0ap1%0a.N.N.S'uod1'%0ap1%0a.S'uod1,,date'%0ap1%0a.N.S''%0a.S'001_PCstring.py'%0ap1%0a.S'001_PCstring'%0ap1%0a.S'Add_string_PropToOverheadDict'%0ap1%0a.N.S''%0a.S'001_PCstring.py'%0ap1%0a.S'001_PCstring'%0ap1%0a.S'MergeProxiesBecause_string_PropertyInstancesSpecifySameSubject'%0ap1%0a.N.S''%0a.S'001_PCstring.py'%0ap1%0a.S'001_PCstring'%0ap1%0a.S'Merge_string_PropertyValues'%0ap1%0a.S'SIP for dates; values are date strings normalized to YYYY/MM/DD.'%0ap1%0a.S'rawUnicodeString'%0ap1%0a.N.S''%0a.S'001_PCstring.py'%0ap1%0a.S'001_PCstring'%0ap1%0a.S'ProxiesOfSubjectIdentifiedBy_string_Value'%0ap1%0a.N.S''%0a.S'001_PCstring.py'%0ap1%0a.S'001_PCstring'%0ap1%0a.S'Remove_string_PropFromOverheadDict'%0ap1%0a.N.S''%0a.S'001_PCstring.py'%0ap1%0a.S'001_PCstring'%0ap1%0a.S'ValuesOf_string_PropertyInstancesAreSignificantlyDifferent'%0ap1%0a.N.S'date'%0ap1%0a.N.N.S'uod1'%0ap1%0a.N.N.S'uod1,,firstEmail'%0ap1%0a.N.S''%0a.S'001_PCproxyIdSet.py'%0ap1%0a.S'001_PCproxyIdSet'%0ap1%0a.S'Add_proxyIdSet_PropToOverheadDict'%0ap1%0a.N.S''%0a.S'001_PCproxyIdSet.py'%0ap1%0a.S'001_PCproxyIdSet'%0ap1%0a.S'MergeProxiesBecause_proxyIdSet_PropertyInstancesSpecifySameSubject'%0ap1%0a.N.S''%0a.S'001_PCproxyIdSet.py'%0ap1%0a.S'001_PCproxyIdSet'%0ap1%0a.S'Merge_proxyIdSet_PropertyValues'%0ap1%0a.S'SIP for threads; value is a reference to the proxy for the first email in the thread.'%0ap1%0a.S'rawProxyIdList'%0ap1%0a.N.S''%0a.S'001_PCproxyIdSet.py'%0ap1%0a.S'001_PCproxyIdSet'%0ap1%0a.S'ProxiesOfSubjectIdentifiedBy_proxyIdSet_Value'%0ap1%0a.N.S''%0a.S'001_PCproxyIdSet.py'%0ap1%0a.S'001_PCproxyIdSet'%0ap1%0a.S'Remove_proxyIdSet_PropFromOverheadDict'%0ap1%0a.N.S''%0a.S'001_PCproxyIdSet.py'%0ap1%0a.S'001_PCproxyIdSet'%0ap1%0a.S'UpdateProxyReferencesIn_proxyIdSet_Value'%0ap1%0a.N.S''%0a.S'001_PCproxyIdSet.py'%0ap1%0a.S'001_PCproxyIdSet'%0ap1%0a.S'ValuesOf_proxyIdSet_PropertyInstancesAreSignificantlyDifferent'%0ap1%0a.N.S'firstEmail'%0ap1%0a.N.N.S'uod1'%0ap1%0a.N.N.S'uod2'%0ap1%0a.S'uod2.xml'%0ap1%0a.S'Universe of Discourse (UoD) for EMAIL subjects.'%0ap1%0a.N.(dp1%0a.(dp1%0aS'date'%0ap2%0aNsS'emailAddresses'%0ap3%0aNsS'subjectLine'%0ap4%0aNs.N.(dp1%0aS'rawUnicodeStringList'%0ap2%0aNsS'rawProxyIdList'%0ap3%0aNsS'rawUnicodeString'%0ap4%0aNs.S'uod2,,rawProxyIdList'%0ap1%0a.N.S''%0a.S'001_VTproxyIdList.py'%0ap1%0a.S'001_VTproxyIdList'%0ap1%0a.S'InstanceOf_proxyIdListRaw_ValueTypeToXMLContentString'%0ap1%0a.S'General-purpose list-of-subject-proxies value type.'%0ap1%0a.S'rawProxyIdList'%0ap1%0a.S'uod2'%0ap1%0a.N.S''%0a.S'001_VTproxyIdList.py'%0ap1%0a.S'001_VTproxyIdList'%0ap1%0a.S'ValueIsNotOfType_proxyIdList_'%0ap1%0a.N.S''%0a.S'001_VTproxyIdList.py'%0ap1%0a.S'001_VTproxyIdList'%0ap1%0a.S'XMLContentStringToInstanceOf_proxyIdListRaw_ValueType'%0ap1%0a.S'uod2,,rawUnicodeString'%0ap1%0a.N.S''%0a.S'001_VTstring.py'%0ap1%0a.S'001_VTstring'%0ap1%0a.S'InstanceOf_rawUnicodeString_ValueTypeToXMLContentString'%0ap1%0a.S'General-purpose Unicode string value type.'%0ap1%0a.S'rawUnicodeString'%0ap1%0a.S'uod2'%0ap1%0a.N.S''%0a.S'001_VTstring.py'%0ap1%0a.S'001_VTstring'%0ap1%0a.S'ValueIsNotOfType_rawUnicodeString_'%0ap1%0a.N.S''%0a.S'001_VTstring.py'%0ap1%0a.S'001_VTstring'%0ap1%0a.S'XMLContentStringToInstanceOf_rawUnicodeString_ValueType'%0ap1%0a.S'uod2,,rawUnicodeStringList'%0ap1%0a.N.S''%0a.S'001_VTstringList.py'%0ap1%0a.S'001_VTstringList'%0ap1%0a.S'InstanceOf_rawUnicodeStringList_ValueTypeToXMLContentString'%0ap1%0a.S'General-purpose value type that is a list of raw Unicode strings.'%0ap1%0a.S'rawUnicodeStringList'%0ap1%0a.S'uod2'%0ap1%0a.N.S''%0a.S'001_VTstringList.py'%0ap1%0a.S'001_VTstringList'%0ap1%0a.S'ValueIsNotOfType_unicodeStringList_'%0ap1%0a.N.S''%0a.S'001_VTstringList.py'%0ap1%0a.S'001_VTstringList'%0ap1%0a.S'XMLContentStringToInstanceOf_rawUnicodeStringList_ValueType'%0ap1%0a.S'uod2,,emailAddresses'%0ap1%0a.N.S''%0a.S'001_PCstringSet.py'%0ap1%0a.S'001_PCstringSet'%0ap1%0a.S'Add_stringSet_anyMatch_PropToOverheadDict'%0ap1%0a.N.S''%0a.S'001_PCstringSet.py'%0ap1%0a.S'001_PCstringSet'%0ap1%0a.S'MergeProxiesBecause_stringSet_anyMatch_PropertyInstancesSpecifySameSubject'%0ap1%0a.N.S''%0a.S'001_PCstringSet.py'%0ap1%0a.S'001_PCstringSet'%0ap1%0a.S'Merge_stringSet_PropertyValues'%0ap1%0a.S"SIP for persons; each item is an email address for the person; if any email address matches, it's the same subject."%0ap1%0a.S'rawUnicodeStringList'%0ap1%0a.N.S''%0a.S'001_PCstringSet.py'%0ap1%0a.S'001_PCstringSet'%0ap1%0a.S'ProxiesOfSubjectIdentifiedBy_stringSet_anyMatch_Value'%0ap1%0a.N.S''%0a.S'001_PCstringSet.py'%0ap1%0a.S'001_PCstringSet'%0ap1%0a.S'Remove_stringSet_anyMatch_PropFromOverheadDict'%0ap1%0a.N.S''%0a.S'001_PCstringSet.py'%0ap1%0a.S'001_PCstringSet'%0ap1%0a.S'ValuesOf_stringSet_PropertyInstancesAreSignificantlyDifferent'%0ap1%0a.N.S'emailAddresses'%0ap1%0a.N.N.S'uod2'%0ap1%0a.N.N.S'uod2,,subjectLine'%0ap1%0a.N.S''%0a.S'001_PCstring.py'%0ap1%0a.S'001_PCstring'%0ap1%0a.S'Add_string_PropToOverheadDict'%0ap1%0a.N.S''%0a.S'001_PCstring.py'%0ap1%0a.S'001_PCstring'%0ap1%0a.S'MergeProxiesBecause_string_PropertyInstancesSpecifySameSubject'%0ap1%0a.N.S''%0a.S'001_PCstring.py'%0ap1%0a.S'001_PCstring'%0ap1%0a.S'Merge_string_PropertyValues'%0ap1%0a.S'SIP for subject lines; values are email "Subject:s".'%0ap1%0a.S'rawUnicodeString'%0ap1%0a.N.S''%0a.S'001_PCstring.py'%0ap1%0a.S'001_PCstring'%0ap1%0a.S'ProxiesOfSubjectIdentifiedBy_string_Value'%0ap1%0a.N.S''%0a.S'001_PCstring.py'%0ap1%0a.S'001_PCstring'%0ap1%0a.S'Remove_string_PropFromOverheadDict'%0ap1%0a.N.S''%0a.S'001_PCstring.py'%0ap1%0a.S'001_PCstring'%0ap1%0a.S'ValuesOf_string_PropertyInstancesAreSignificantlyDifferent'%0ap1%0a.N.S'subjectLine'%0ap1%0a.N.N.S'uod2'%0ap1%0a.N.N.S'uod2,,date'%0ap1%0a.N.S''%0a.S'001_PCproxyIdSet.py'%0ap1%0a.S'001_PCproxyIdSet'%0ap1%0a.S'Add_proxyIdSet_PropToOverheadDict'%0ap1%0a.N.S''%0a.S'001_PCproxyIdSet.py'%0ap1%0a.S'001_PCproxyIdSet'%0ap1%0a.S'Merge_accumulatingProxyIdSet_PropertyValues'%0ap1%0a.S'OP for emails; value is a reference to the proxy for the date of the email.'%0ap1%0a.S'rawProxyIdList'%0ap1%0a.N.S''%0a.S'001_PCproxyIdSet.py'%0ap1%0a.S'001_PCproxyIdSet'%0ap1%0a.S'ProxiesOfSubjectIdentifiedBy_proxyIdSet_Value'%0ap1%0a.N.S''%0a.S'001_PCproxyIdSet.py'%0ap1%0a.S'001_PCproxyIdSet'%0ap1%0a.S'Remove_proxyIdSet_PropFromOverheadDict'%0ap1%0a.N.S''%0a.S'001_PCproxyIdSet.py'%0ap1%0a.S'001_PCproxyIdSet'%0ap1%0a.S'UpdateProxyReferencesIn_proxyIdSet_Value'%0ap1%0a.N.S''%0a.S'001_PCproxyIdSet.py'%0ap1%0a.S'001_PCproxyIdSet'%0ap1%0a.S'ValuesOf_proxyIdSet_PropertyInstancesAreSignificantlyDifferent'%0ap1%0a.N.S'date'%0ap1%0a.N.N.S'uod2'%0ap1%0a.20051201054431.GD4129@mando.rho.priv.atDate: Thu, 1 Dec 2005 15:44:31 +1000%0aSubject: %5bsc34wg3%5d TMDM minor suggestion%0aMessage-ID: %3c20051201054431.GD4129@mando.rho.priv.at%3e%0a%0aLarsbot, Graham,%0a%0aIn the following minor nagging points re the current TMDM. Mostly%0asuggestions in respect to formulation.%0a%0aI promise, I will never look at the doc again :-))%0a%0a\rho%0a%0a-----------------------------------------------------------------------------%0a%0aThis is against the version 2005-10-28:%0a%0a- Page V:%0a%0aNot sure whether part 6 (and 7) are already on the table?%0a%0ahttp://y12web2.y12.doe.gov/sgml/sc34/document/0680.htm#is13250-6%0a%0a- 4.1%0a%0a"The names of these properties..."%0a%0ato what does 'these' refer to?%0a%0a- 4.1%0a%0a"...as associated type..." wording is using terms (assocation, type) in a%0adifferent meaning than later. Might be a bit misleading.%0a%0a- 4.1%0a%0a'null' is not defined yet.%0a%0a- 4.1 3rd para%0a%0asuggest: .... are - strictly speaking - redun..%0a%0a- 4.1 4th para%0a%0asuggest: ...infoset formalism for the purpose of illus...%0a%0a- 4.3 Set:%0a%0asuggest: ...contain no two elements...%0a%0a- 4.3 Null:%0a%0asuggest: consistent writing of Null (capitalized, different font?)%0a%0a- 4.4 Datatypes%0a%0a"...only ... are strings and Null".%0a%0aI thought IRIs are now there and XML, as defined in the same section. I%0aassume something else was planned to say here, but I do not quite get what.%0a%0a- 5.1%0a%0a"Topic map constructs .......any number of item identifiers."%0a%0asuggest simplification/correction:%0a%0a"Every information item has at least one item identifer (see merging)".%0a%0a- 5.1 Constraint%0a%0a"...to have strings..."%0a%0acorrect to "values"?%0a%0aThe constraint is confusing for me. First it is an error, if there are%0aequal identifiers. Then, it could be, because of topics. But then they%0ahave to be merged, and then the fact of two equal identifiers does not%0aexist anymore.%0a%0a- 5.3.1 typos%0a%0a"....are statements, where_as the assignment__s of ...are not ..."%0a%0a- 5.3.2%0a%0a"....represented by a topic _to a human being_."%0a%0aSuggest to drop the human thing. Have to work with so many aliens here.%0a%0a- 5.3.2 Note 1%0a%0a"der_ference"%0a%0a- 5.3.2 Note 1%0a%0aSuggest s/does not exist/is not accessible/%0a%0a- 5.3.2 Example%0a%0aSuggest to add a trailing slash to the IRI%0a%0a- 5.3.2%0a%0a"Note the uncertainty...."%0a%0aSuggest to make a NOTE.%0a%0a- 5.3.3 Scope%0a%0a"..unconstrained scope.... is represented by the empty set"%0a%0aSo be it, but what it means is that implementations have to%0abe extremely careful when they handle scope: If they do set%0aintersection operations (for whatever reason) and if they end%0aup with an empty set then BEWARE(!) this all of a sudden would%0abe unconstrained-scopishly true!%0a%0aNot overly natural, but I lack a better idea at the moment.%0a%0a- 5.3.3 Scope Example%0a%0aSuggest comma after Davies%0a%0aSuggest to drop the third example. It did not tell me ANYTHING.%0aIt is a typical show-off. :-)%0a%0a- 5.3.4 Reification Note 1%0a%0aSuggest to add a reference to it. Sowa?%0a%0a- 5.3.4%0a%0a" ... to topic map constructs such as ...."%0a%0aSuggest to delete things after 'such as'.%0a%0a- 5.3.4%0a%0a"is present in a structured form"%0a%0aSuggest: explicit form%0a%0aSuggest to drop everything after "that can be ....."%0a%0a- 5.3.5 Topic properties%0a%0aad equality rule: I would think that people may wonder how it might%0ago about that two topics at some point share a common item identifier.%0aThis is probably only during merging, yes?%0a%0aI suspect that we should say something before that a TMDM instance%0ais not necessarily 'completely merged' and that section X describes%0athis process in detail.%0a%0aIt is just that I had to sit back and wonder.%0a%0a- 5.3.5 Topic properties%0a%0aEquality rule again.%0a%0aThis seems to be the ONLY place where the name space of %5bsubject identifiers%5d and%0athat of %5bitem identifiers%5d seem to interact. I am a bit puzzled by this.%0a%0a- 5.3.5 Note 1%0a%0aSuggest "...should not be used" -%3e "must not be ...."%0a%0aSuggest to make the whole note only one paragraph.%0a%0a- 5.4 topic names Note 1%0a%0aIf a name is a special occurrence and an occurrence is a special association, should%0awe not make this more explicit in some Annex?%0a%0a- 5.4 topic names %5b reifier %5d%0a%0aSuggest "if present" -%3e "if not NULL"%0a%0a%0a- 5.6 Occurrence%0a%0aI have a question: if I create an occurrence of%0atype 'homepage' for a topic 'robert'%0a%0arobert%0aoc (homepage): http://nowhere.com/%0a%0aIs then 'homepage' automatically, implicitely a subtype%0aof 'psi.topicmaps.org/occurrence' ?%0a%0a- 6.1 Merging%0a%0a"...but the rules given here are insufficient...."%0a%0aSounds a bit cryptic. To explain this more, one would have%0ato say something about 'redundancy'. Maybe drop everything%0aafter "but"?%0a%0a"Any change..."%0a%0aIf TMDM instances are allowed to be 'redundant', then why%0ais the 'change' necessary to trigger merging?%0a%0aSuggest: "..a set" -%3e "any set"%0a%0a6.2 ad 1)%0a%0aIs it necessary to say "Create a new topic item with item identifier C"?%0a%0a6.2 ad 8)%0a%0aI note that the original topics are not removed?%0a%0a6.3 ad 6)%0a%0aSuggest:%0a%0a"..non-null values, the _respective_ topic items shall..."%0a%0aSuggest:%0a%0a"..from the merged set _is then_ the value...."%0a%0a7.2%0a%0aSuggest: "topic type is know _to be_ an instance .."%0a%0a7.2%0a%0aIs the note that type-instance is not transitive any relevant%0ato TMDM? (Same question for subtype-supertype transitivity).%0a%0a7.3%0a%0aSuggest: "....relationship implies ..."%0a%0a7.5%0a%0aMost of the Usage sections are empty. Looks a bit odd.%0a%0aFrom: sc34wg3@isotopicmaps.org (Lars Marius Garshol)['0021440']['0021214']['00152']2005/12/01['00150']['00150']['0019296']m3vey31e9p.fsf@ontopia.netDate: Mon, 05 Dec 2005 21:26:42 +0100%0aSubject: %5bsc34wg3%5d XTM 1.1 schema%0aMessage-ID: %3cm3vey31e9p.fsf@ontopia.net%3e%0a%0aI forgot to attach this to the previous email. We put together a rough%0adraft of a possible XTM 1.1 RELAX-NG schema in order to show what the%0aresult would look like. We thought of doing up an example to show how%0amuch simpler the result is, but the fact is that most actual XTM 1.0%0awould still be valid; it's only all the bizarre things you could do in%0aXTM 1.0 that are no longer allowed, and doing examples of those is a%0abit harder.%0a%0aAnyway, here is the schema. It's considerably simpler than the%0aprevious draft.%0a%0a%0a# ===========================================================================%0a#%0a# XML Topic Maps 1.1%0a#%0a# Proposal based on initial editors' meeting.%0a#%0a# ===========================================================================%0a%0a# --- Common declarations%0a%0adefault namespace = "http://www.topicmaps.org/xtm/"%0anamespace xtm = "http://www.topicmaps.org/xtm/"%0a%0adatatypes xsd = "http://www.w3.org/2001/XMLSchema-datatypes"%0a%0astart = topicMap%0a%0aid = attribute id { xsd:ID }%0a%0ahref = attribute href { xsd:anyURI }%0a%0aany-markup = (text | element * - xtm:* { attribute * { text }*, any-markup* })*%0a%0a%0a# --- The schema%0a%0atopicMap = element topicMap { id?, version,%0a(topic | association | mergeMap)* }%0a%0aversion = attribute version { "1.1" }%0a%0atopic = element topic { id, instanceOf*, subjectIdentity?,%0a(topicName | occurrence)* }%0a%0asubjectIdentity = element subjectIdentity { id?,%0a(reifies | subjectLocator | subjectIdentifier | itemIdentity)* }%0a%0atopicName = element topicName { id?, instanceOf?, scope?, value, variant* }%0a%0avalue = element value { text }%0a%0avariant = element variant { id?, scope, (resourceRef | resourceData) }%0a%0ascope = element scope { topicRef+ }%0a%0ainstanceOf = element instanceOf { topicRef }%0a%0aoccurrence = element occurrence { id?,%0ainstanceOf?, scope?, ( resourceRef | resourceData ) }%0a%0adatatype = attribute datatype { xsd:anyURI }%0a%0a# tighten so only any-markup when datatype is XML%0aresourceData = element resourceData { datatype?, any-markup }%0a%0aassociation = element association { id?, instanceOf?, scope?, role+ }%0a%0arole = element role { id?, instanceOf?, topicRef }%0a%0atopicRef = element topicRef { href }%0aresourceRef = element resourceRef { href }%0asubjectLocator = element subjectLocator { href }%0asubjectIdentifier = element subjectIdentifier { href }%0areifies = element reifies { href } # really href???%0aitemIdentity = element itemIdentity { href }%0a%0amergeMap = element mergeMap { href }%0a%0a# --- End of schema%0a%0a--%0aLars Marius Garshol, Ontopian %3cURL: http://www.ontopia.net %3e%0aGSM: +47 98 21 55 50 %3cURL: http://www.garshol.priv.no %3e%0a%0a%0aFrom: sc34wg3@isotopicmaps.org (Patrick Durusau)['0021454']['00161']['0020268']XTM 1.1 schema['00160']['00160']43961381.8050601@durusau.netDate: Tue, 06 Dec 2005 17:41:05 -0500%0aSubject: %5bsc34wg3%5d XTM 1.1 issues: reification%0aMessage-ID: %3c43961381.8050601@durusau.net%3e%0a%0aLars,%0a%0aResponding to only part of your excellent post on the XTM 1.1 issues:%0a%0a%3e--- Reification%0a%3e%0a%3eThe reification processing in the current XTM draft is very heavy,%0a%3ebasically because reification is explicit in the model, but not in the%0a%3esyntax, so you have to wait until the entire document is read before%0a%3ejoining up the reification connections.%0a%3e%0a%3eThe solution is to make it explicit in the syntax. We thought of four%0a%3ealternatives:%0a%3e%0a%3e 1) -reifier- attribute on anything that can be reified%0a%3e cut ID from everything, except %3ctopic%3e%0a%3e%0a%3e bad: have to add everywhere, not consistent with general XTM 1.0%0a%3e syntax design%0a%3e%0a%3e 2) %3creifier%3e sub-element on anything that can be reified with%0a%3e %3ctopicRef%3e inside%0a%3e%0a%3e bad: have to add everywhere%0a%3e very intrusive%0a%3e becomes very ugly indeed inside %3ctopicMap%3e%0a%3e%0a%3e 3) -reifies- attribute on %3ctopic%3e%0a%3e%0a%3e bad: not consistent with general XTM 1.0 syntax design%0a%3e%0a%3e 4) %3creifies%3e sub-element on %3csubjectIdentity%3e, with xlink:href%0a%3e %3creificationRef%3e? %3creifiedRef%3e? %3creifiesRef%3e? %3csubjectRef%3e?%0a%3e%0a%3e favourite: %3creificationRef%3e%0a%3e bad: can't think of a good name%0a%3e bad: means when you process the topic you don't know what%0a%3e it reifies, so you have to remember until you find the thing%0a%3e%0a%3eThe editors haven't really landed here, but are proceeding with 4) as%0a%3ea working hypothesis for the moment. However, suggestions further down%0a%3eimply that 1) might be made to work better.%0a%3e%0a%3e%0a%3e%0aI have a suggestion for reification in the model that might help with%0athis issue in XTM 1.1.%0a%0aWhat if topics were not required for reification?%0a%0aI realize that is a serious departure from prior treatment of%0areification, but the model already specifies, even in the absence of a%0areifying topic, how to merge the various information items in the model.%0a%0aTokens in an information system always represent some subject. It is%0asimply the nature of tokens in an information system that they have%0ameaning to someone within a framework of tokens. But, standing alone,%0athey do not reify subjects.%0a%0aWhat is of the essence of reification is the occurrence of properties%0atogether that collectively enable an information item to represent a%0asubject. That is to say a subject is "reified" when it is represented by%0aproperties that serve together to identify a subject.%0a%0aAlthough as I mentioned this is a serious departure from the current%0astance on reification, it would avoid the various options you list for%0achanging XTM 1.1, none of which looks all that attractive.%0a%0aI think the division of labor as it were, between topics, associations%0a(relationships between topics), and occurrences (a specialized form of%0aassociation) still obtains with my proposal without the overhead of%0ahaving to track topics for reification connections.%0a%0aThere may be some serious flaw that I have not noticed in this proposal%0abut after reading your comments on changes needed to XTM 1.1 I thought%0ait would be worth suggesting.%0a%0aHope you are having a great day!%0a%0aPatrick%0a%0aPS: After NOON tomorrow I am going to be on the road and may or may not%0ahave regular email access until I get back in office on Saturday.%0a%0a--%0aPatrick Durusau%0aPatrick@Durusau.net%0aChair, V1 - Text Processing: Office and Publishing Systems Interface%0aCo-Editor, ISO 13250, Topic Maps -- Reference Model%0aMember, Text Encoding Initiative Board of Directors, 2003-2005%0a%0aTopic Maps: Human, not artificial, intelligence at work!%0a%0a%0a%0aFrom: sc34wg3@isotopicmaps.org (Lars Heuer)['0021442']['00166']['00167']XTM 1.1 issues: reification['00165']2005/12/06['00165']['00165']481155557.20051207132308@semagia.comDate: Wed, 7 Dec 2005 13:23:08 +0100%0aSubject: %5bsc34wg3%5d TMDM comments%0aMessage-ID: %3c481155557.20051207132308@semagia.com%3e%0a%0aHi there,%0a%0aI've some comments regarding TMDM dtd. 2005-10-28%0a%0aBest regards,%0aLars%0a%0a%0aComments against TMDM version 2005-10-28%0a%0aForeword%0a--------%0a"""%0aISO/IEC 13250 consists of the following parts, under the general title%0aTopic Maps:%0a%5b...%5d%0a"""%0a%0aIMO these references add no value to TMDM. There are already%0aproposals for Part 6 and Part 7 and possibly more parts will follow%0ain the future%0aReferences to all parts of ISO/IEC 13250 should be moved to an%0aadditional, informal document.%0a%0a%0a4.1 The metamodel - Introduction%0a--------------------------------%0aFigure 1 - The class hierarchy%0aAccording to the UML diagramm a Topic may be reified by another%0aTopic.%0aThat is simply not true.%0a%0aAdditionally the note states "%5b...%5d and because the value of the%0a%5breifier%5d property of topic items can be any topic map construct."%0a%0aThis is also not true.%0a%0aI know, the UML diagramms are not normative and there is a note that%0asays "prose rules" but I wonder why the UML diagramm and its%0anote is intentional wrong.%0a%0a5.3.4. 2nd note says: "One topic cannot reify another." since they%0ahave to merged because they represent the same subject. That is the%0atruth and the misleading information mentioned above should be%0aremoved.%0a%0a%0a5.3.2 Identifying subjects%0a--------------------------%0aThe note for subject locators states "%5b...%5d This of course raises the%0aquestion of when two information resources can be considered to be the%0asame. This part of ISO/IEC13250 makes no attempt to clarify this and%0aleaves it for individual locator notations to define."%0a%0aDo the "locator notations" define in which cases the information%0aresource should be considered the same? What about%0a"http://beatles.com/" and "http://www.beatles.com/"? Both refer to the%0asame information resource and that has nothing to do with the locator%0anotation.%0a%0a%0a5.3.3 Scope%0a-----------%0aExample 2:%0aNot a failure but I'd like to suggest to find a more pleasant example%0athan Word War II.%0aAdditionally this example seems to suggest that dates should be%0amodelled with occurrences ("This corresponds to creating %5b...%5d").%0aIt is also possible to create a topic that represents that date and%0aconnect it via a 'true' association with the WWII topic. ('true' since%0aoccurrence is a special kind of association).%0aI suggest to change it to something like "This may be modelled ..."%0a%0aExample 3:%0aIMO it would be nice to find an example that 99%25 (or more) of the%0areaders understand instead of that cryptic one.%0a%0a%0a5.3.5 Properties%0a----------------%0aEquality rule%0a%0aWouldn't a ", or" behind each list item make it more clear that only%0aone of these items has to be fulfilled to state that particular%0atopics are equal?%0a%0aBTW: The equality rules are not addressable (they do not occurr in the%0aTOC). I suggest to make the equality rule of each topic map construct%0aaddressable.%0a%0a%0a"""%0aNOTE:%0a%0aTopics may in addition to the properties defined above also have%0atypes, instances, supertypes, and subtypes, represented by means of%0aassociations using the subject identifiers defined in 7.2 and 7.3.%0a"""%0a%0aWhy "may have types"? Hasn't each topic at least one type%0a("http://psi.topicmaps..../subject")?%0a%0a%0a%0a6.2 Merging topic items%0a-----------------------%0a"The procedure for merging two topic items A and B (whose %5bparent%5d%0aproperties shall contain the same topic map item) %5b...%5d"%0a%0aWhy is the %5bparent%5d property mentioned here? The merging procedure%0adescribes merging of topic items in the _same_ topic map instance. The%0a%5bparent%5d propety _is_ the same.%0a%0aThe merging procedures 6.3 - 6.7 do not state that the %5bparent%5d%0aproperty shall contain the the same value.%0a%0aI suggest to remove the "(whose %5bparent%5d ...)" or to add this hint to%0aevery merging procedure (topic names, occurrences, associations ...)%0awith the appropriate %5bparent%5d property name.%0a%0a%0a--%0ahttp://semagia.com%0a%0a%0aFrom: sc34wg3@isotopicmaps.org (G. Ken Holman - ISO/IEC JTC 1/SC 34 Secretary)['0021267']['0020939']['00172']2005/12/07['00170']['00170']6.2.3.4.2.20051208205112.04ab5080@pop.storm.caDate: Thu, 08 Dec 2005 20:58:39 -0500%0aSubject: %5bsc34wg3%5d An article regarding unique IDs%0aMessage-ID: %3c6.2.3.4.2.20051208205112.04ab5080@pop.storm.ca%3e%0a%0aHello all,%0a%0aI subscribe to an email newsletter written by David Weinberger. He%0ais the author of a number of books including "Small Pieces Loosely%0aJoined: A Unified Theory of the Web" and "The Cluetrain Manifesto:%0aThe End of Business as Usual".%0a%0aAside from some very interesting and enjoyable humour, I believe he%0ahas an insightful perspective of the web, the technology of the web,%0aand the society of the web.%0a%0aThis month's issue has a very interesting article on unique identifiers:%0a%0ahttp://www.hyperorg.com/backissues/joho-dec05-05.html%0a%0aIn it I see references to unique identification projects of which%0aI've never heard.%0a%0aI've since written him to bring his attention to Published Subjects%0aso that perhaps he might include reference to them in the book he is writing.%0a%0aI thought I'd bring the article to WG3's attention in case any member%0awould also find his article of interest.%0a%0aAnd it's my chance to wish everyone a very enjoyable holiday, and a%0ahappy, healthy and successful new year!%0a%0a. . . . . . . . . . . Ken%0a--%0a%0aG. Ken Holman Crane Softwrights Ltd.%0aISO/IEC JTC 1/SC 34 Secretariat Standards Council of Canada%0aCommittee correspondence: mailto:jtc1sc34@scc.ca%0aCommittee website: http://www.jtc1sc34.org%0aCorporate correspondence: mailto:gkholman@CraneSoftwrights.com%0aCorporate website: http://www.CraneSoftwrights.com/a/%0a%0a%0aFrom: sc34wg3@isotopicmaps.org (Lars Heuer)['0018197']['00176']['00177']An article regarding unique IDs['00175']2005/12/08['00175']['00175']['0019350']['0019514']['0019176']['0019264']0CE25263F839BA44AFDDB7A786BAB8B70749DAEA@Y12MAIL01.y12.doe.govDate: Tue, 13 Dec 2005 08:32:13 -0500%0aSubject: %5bsc34wg3%5d XTM 1.1 issues: MergeMap%0aMessage-ID: %3c0CE25263F839BA44AFDDB7A786BAB8B70749DAEA@Y12MAIL01.y12.doe.gov%3e%0a%0aThis is a multi-part message in MIME format.%0a%0a------_=_NextPart_001_01C5FFE9.A1E447DD%0aContent-Type: text/plain;%0acharset=us-ascii%0aContent-Transfer-Encoding: quoted-printable%0a%0aMurray,=20%0a=20%0aThis is my position, too. I use it for modularization. I don't care what =%0ait's%0acalled; it might as well be %3cFileInclude%3e so far as I'm concerned.%0a=20%0aJim%0a=20%0a=20%0aJim,%0a%0aI don't think of %3cmergeMap%3e as authoring, but a component in =%0amodularization.%0aI'm certain that it can be valuable in authoring too, but to me its =%0aessential%0afunctionality is the ability to create ontological components that can =%0abe%0amixed and matched as needed. The ability to scope the merged Topics is =%0aalso%0aimportant in being able to extract the merged set from the soup one has%0acreated.%0a%0aIn my experience, the mergeMap feature in both XTM and LTM has proven%0ainvaluable, as I don't generally deliver a single Topic Map document, I%0adeliver a set of modules. As such, having an interchange syntax absent%0a%3cmergeMap%3e or #MERGEMAP would seriously hinder the ability to maintain =%0athe%0aset of Topic Maps as modules, as I'd then have to perform a pre-merge =%0afor%0adelivery and lose the modularity, a feature I'm sure is appreciated by =%0athose%0awho don't want the entirety of the package, or want to reuse various%0acomponents.%0a%0aIn summary, it helps keep the module soup organized in LTM and XTM. If =%0ayou%0alike your soup organized... I do. I would guess anyone using Topic Maps =%0afor%0aontology modelling work would too, as monolithic ontologies are pretty%0auseless.%0a%0aMurray%0a%0a......................................................................%0a%0aMurray Altheim http://www.altheim.com/murray/%0a%3chttp://www.altheim.com/murray/%3e=20%0a%0aStrategic Services Development Manager%0a%0aThe Open University Library and Learning Resources Centre%0a%0aThe Open University, Milton Keynes, Bucks, MK7 6AA, UK .%0a%0a%0a------_=_NextPart_001_01C5FFE9.A1E447DD%0aContent-Type: text/html;%0acharset=us-ascii%0aContent-Transfer-Encoding: quoted-printable%0a%0a%3c!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"%3e%0a%3cHTML%3e%3cHEAD%3e%3cTITLE%3e%3c/TITLE%3e%0a%3cMETA http-equiv=3DContent-Type content=3D"text/html; =%0acharset=3Dus-ascii"%3e%0a%3cMETA content=3D"MSHTML 6.00.2900.2769" name=3DGENERATOR%3e%3c/HEAD%3e%0a%3cBODY%3e%0a%3cDIV%3e%3c!-- Converted from text/plain format --%3e%3cFONT face=3DArial =%0acolor=3D#0000ff=20%0asize=3D2%3eMurray, %3c/FONT%3e%3c/DIV%3e%0a%3cDIV%3e%3cFONT face=3DArial color=3D#0000ff size=3D2%3e%3c/FONT%3e%26nbsp;%3c/DIV%3e%0a%3cDIV%3e%3cFONT face=3DArial color=3D#0000ff size=3D2%3eThis is my position, =%0atoo. I use it=20%0afor modularization. I don't care what it's called; it might as well be=20%0a%26lt;FileInclude%26gt; so far as I'm concerned.%3c/FONT%3e%3c/DIV%3e%0a%3cDIV%3e%3cFONT face=3DArial color=3D#0000ff size=3D2%3e%3c/FONT%3e%26nbsp;%3c/DIV%3e%0a%3cDIV%3e%3cFONT face=3DArial color=3D#0000ff size=3D2%3eJim%3c/FONT%3e%3c/DIV%3e%0a%3cDIV%3e%3cFONT face=3DArial color=3D#0000ff size=3D2%3e%3c/FONT%3e%26nbsp;%3c/DIV%3e%0a%3cDIV%3e%3cFONT face=3DArial color=3D#0000ff size=3D2%3e%3c/FONT%3e%26nbsp;%3c/DIV%3e%0a%3cDIV%3e%3cFONT size=3D2%3e%0a%3cP%3eJim,%3c/P%3e%0a%3cP%3eI don't think of %26lt;mergeMap%26gt; as authoring, but a component in=20%0amodularization. I'm certain that it can be valuable in authoring too, =%0abut to me=20%0aits essential functionality is the ability to create ontological =%0acomponents that=20%0acan be mixed and matched as needed. The ability to scope the merged =%0aTopics is=20%0aalso important in being able to extract the merged set from the soup one =%0ahas=20%0acreated.%3c/P%3e%0a%3cP%3eIn my experience, the mergeMap feature in both XTM and LTM has proven =%0a%0ainvaluable, as I don't generally deliver a single Topic Map document, I =%0adeliver=20%0aa set of modules. As such, having an interchange syntax absent =%0a%26lt;mergeMap%26gt;=20%0aor #MERGEMAP would seriously hinder the ability to maintain the set of =%0aTopic=20%0aMaps as modules, as I'd then have to perform a pre-merge for delivery =%0aand lose=20%0athe modularity, a feature I'm sure is appreciated by those who don't =%0awant the=20%0aentirety of the package, or want to reuse various components.%3c/P%3e%0a%3cP%3eIn summary, it helps keep the module soup organized in LTM and XTM. =%0aIf you=20%0alike your soup organized... I do. I would guess anyone using Topic Maps =%0afor=20%0aontology modelling work would too, as monolithic ontologies are pretty=20%0auseless.%3c/P%3e%0a%3cP%3eMurray%3c/P%3e%0a%3cP%3e......................................................................=%0a%3c/P%3e%0a%3cP%3eMurray Altheim %3c/FONT%3e%3cA =%0ahref=3D"http://www.altheim.com/murray/"%3e%3cU%3e%3cFONT=20%0acolor=3D#0000ff =%0asize=3D2%3ehttp://www.altheim.com/murray/%3c/U%3e%3c/FONT%3e%3c/A%3e%3c/P%3e%3cFONT=20%0asize=3D2%3e%0a%3cP%3eStrategic Services Development Manager%3c/P%3e%0a%3cP%3eThe Open University Library and Learning Resources Centre%3c/P%3e%0a%3cP%3eThe Open University, Milton Keynes, Bucks, MK7 6AA, UK=20%0a.%3c/P%3e%3c/FONT%3e%3c/DIV%3e%3c/BODY%3e%3c/HTML%3e%0a%0a------_=_NextPart_001_01C5FFE9.A1E447DD--%0a%0a%0aFrom: sc34wg3@isotopicmaps.org (Patrick Durusau)['0020648']['0020966']['0021328']['00202']439EE7E4.9070706@durusau.netDate: Tue, 13 Dec 2005 10:25:24 -0500%0aSubject: %5bsc34wg3%5d Topic maps by another name%0aMessage-ID: %3c439EE7E4.9070706@durusau.net%3e%0a%0aGreetings!%0a%0aCurious if anyone else has looked at the charter for the Rule%0aInterchange Format Working Group at the W3C?%0a%0aSection 1.1 Usage Senarios reads remarkably like topic map use cases.%0a%0aI am not sure why they want to re-invent topic maps but it certainly%0alooks like the what has been chartered.%0a%0aHmmm, imitation is the sincerest form of flattery. ;-)%0a%0aComments?%0a%0aHope everyone is having a great day!%0a%0aPatrick%0a%0a--%0aPatrick Durusau%0aPatrick@Durusau.net%0aChair, V1 - Text Processing: Office and Publishing Systems Interface%0aCo-Editor, ISO 13250, Topic Maps -- Reference Model%0aMember, Text Encoding Initiative Board of Directors, 2003-2005%0a%0aTopic Maps: Human, not artificial, intelligence at work!%0a%0a%0a%0aFrom: sc34wg3@isotopicmaps.org (M.Altheim)['0021442']['0020789']['0021328']['00207']['0019380']['0019927']['0019853']20B3EC6E-8E94-4B08-8B9A-4D13287F3B06@ontopia.netDate: Tue, 13 Dec 2005 20:50:07 +0100%0aSubject: %5bsc34wg3%5d XTM 1.1 issues%0aIn-Reply-To: %3c13134844.20051212173218@semagia.com%3e%0aReferences: %3cm3fyp72tea.fsf@ontopia.net%3e %3c13134844.20051212173218@semagia.com%3e%0aMessage-ID: %3c20B3EC6E-8E94-4B08-8B9A-4D13287F3B06@ontopia.net%3e%0a%0a* Lars Heuer%0a%3e%0a%3e Only some short comments... :)%0a%0aShort is good. :-)%0a%0a%3e Item identifiers do not add value to the other items.%0a%3e In fact item identifiers do no really add a value to topics, but it%0a%3e may be difficult to loose item identifiers in the TMDM for topics.%0a%0aThe benefit is that you can have identifiers that have no semantics%0aattached to them. Anyway, more on this in a later email.%0a%0a%3e +1%0a%3e For loosing the %3cmergeMap%3e element.%0a%3e This is nothing that should be into an interchange syntax.%0a%0aIt seems a bit difficult politically at the moment. Both editors%0asympathise very much with your point of view, but, well, it seems bad%0ato remove a feature people are actually using. We definitely don't%0awant people to go on using XTM 1.0 instead because it has features%0a1.1 doesn't. If this is to be successful 1.0 should disappear%0acompletely, the way HyTM so obligingly did.%0a%0a%3e I don't think that XTM should enforce %3cassociation%3es behind %3ctopic%3es.%0a%3e If an author wants assocs behind topics she can do it and ask her TM%0a%3e processor to put them behind the topics (if the TM proc. supports%0a%3e it).%0a%0aWe agree with you.%0a%0a%3e Sorry for not commenting on the topics, maybe I come back later on%0a%3e that (if it's not too late). :)%0a%0aThanks for what you sent. This was helpful. We'll be back with%0aanother draft soon.%0a%0a--%0aLars Marius Garshol, Ontopian http://www.ontopia.net%0a+47 98 21 55 50 http://%0awww.garshol.priv.no%0a%0a%0a%0a%0a%0a%0aFrom: sc34wg3@isotopicmaps.org (Lars Marius Garshol)['0019350']['0021454']['0021393']['0021328']['00227']06A631DF-0F61-4D8A-AC3D-76D9A351E42D@ontopia.netDate: Tue, 13 Dec 2005 21:00:14 +0100%0aSubject: %5bsc34wg3%5d XTM 1.1 issues: MergeMap%0aIn-Reply-To: %3c0CE25263F839BA44AFDDB7A786BAB8B70749DA1D@Y12MAIL01.y12.doe.gov%3e%0aReferences: %3c0CE25263F839BA44AFDDB7A786BAB8B70749DA1D@Y12MAIL01.y12.doe.gov%3e%0aMessage-ID: %3c06A631DF-0F61-4D8A-AC3D-76D9A351E42D@ontopia.net%3e%0a%0a* Mason, James David%0a%3e%0a%3e I can see how you consider it an authoring issue, but I don't see%0a%3e that as being in conflict with an interchange syntax.%0a%0aWell, if you take a strict view of what "interchange syntax" means%0athat to me really implies "format that allows model instances to be%0amoved from A to B". So any features that are not necessary for this%0a(like %3cmergeMap%3e) would not go in if the XTM 1.0 requirements were%0ataken literally.%0a%0a%3e My TM projects typically draw on many sources, and so may have%0a%3e dozens of individual TM files. I typically generate XTM from XSLT%0a%3e scripts (lots of sources, lots of scripts, each script doing a%0a%3e particular kind of thing to a source to generate a particular%0a%3e module). I want to be able to keep the modularization of my TM%0a%3e components and have some sort of "hub document" (to use HyTime%0a%3e terminology) to pull them together.%0a%0aYes, I think this is a quite common user requirement. I think that%0arequirement really is indicative of a failure of the tools to allow%0ausers to move beyond a module == file way of thinking and instead%0ainto one where they can create modules when they want them. (This is%0awhat's behind my latest blog entries on fragments.)%0a%0aHowever, I think we have to recognize that we are where we are, and%0athis is a feature we had in 1.0. This makes it hard to remove it in%0a1.1 if there are people who really want it, and I doubt very much%0athat you are alone in wanting this.%0a%0aThe editors have discussed this back and forth quite a bit, but%0aeventually fell down on the side of keeping %3cmergeMap/%3e.%0a%0a%3e Part of my practice goes back to SGML days, when I had modular DTDs%0a%3e and modular documents.%0a%0aI could write a lot about how I think SGML was bad for people in that%0ait made them think too much in terms of files, and how it's hurt both%0aXML and Topic Maps, but in one sense that's really not the point.%0aPeople want this, and one of the reasons they want this is that the%0atools aren't good enough yet. I can live with that (and try to change%0athe tools so that *next* time... :).%0a%0a%3e The SGML mechanisms (e.g.., entity declarations, followed by entity%0a%3e references or CONREF or application-specific use of attributes) are%0a%3e somewhat clumsy and not entirely well defined in the standard, so I%0a%3e liked this individual usage that was at least simple and consistent.%0a%0aSimple and consistent it is, once you remove the added themes. This%0ais why the editors feel they can live with it, even if it does make%0athings more complex.%0a%0a%3e I can easily be persuaded that %3cmergeMap%3e should be renamed; it's%0a%3e an entirely different use of "merge" from the merging of topics%0a%3e that is central to the topic-identity discussions.%0a%0aI think the name is fine. It's more the complexity, and the question%0aof what XTM is really meant to be. I always felt that the presence of%0athis feature (and inheritance of scope on nested %3cvariant%3es, and the%0aomissibility of role players) were really violations of the original%0arequirements. Changing the name doesn't change that. :)%0a%0a--%0aLars Marius Garshol, Ontopian http://www.ontopia.net%0a+47 98 21 55 50 http://%0awww.garshol.priv.no%0a%0a%0a%0a%0a%0a%0aFrom: sc34wg3@isotopicmaps.org (Lars Marius Garshol)['0019514']['0021454']['0020966']['0021328']['00233']F86D1960-B9E0-4AE9-91F6-0C3EEA01FA9B@ontopia.netDate: Tue, 13 Dec 2005 21:02:56 +0100%0aSubject: %5bsc34wg3%5d XTM 1.1 issues%0aIn-Reply-To: %3c0CE25263F839BA44AFDDB7A786BAB8B70749DA20@Y12MAIL01.y12.doe.gov%3e%0aReferences: %3c0CE25263F839BA44AFDDB7A786BAB8B70749DA20@Y12MAIL01.y12.doe.gov%3e%0aMessage-ID: %3cF86D1960-B9E0-4AE9-91F6-0C3EEA01FA9B@ontopia.net%3e%0a%0a* Mason, James David%0a%3e%0a%3e I'm not sure what you're thinking of doing in the new version, but%0a%3e I, for one, hate "badCamelCase": my fingers just won't work that%0a%3e way. I can't type a word with upper case in the middle but not at%0a%3e the start.%0a%0aOne editor wanted good-multiword-convention, whereas the other%0aclaimed that there was such a thing as GoodCamelCase. Having failed%0ato reach agreement on the intrinsic goodness of either of these, and%0abeing in any case reluctant to change the syntax more than necessary,%0athe editors agreed to leave the naming convention alone.%0a%0a:-)%0a%0a--%0aLars Marius Garshol, Ontopian http://www.ontopia.net%0a+47 98 21 55 50 http://%0awww.garshol.priv.no%0a%0a%0a%0a%0a%0a%0aFrom: sc34wg3@isotopicmaps.org (Lars Marius Garshol)['0019176']['0021454']['0021393']['0021328']['00239']['0019018']E9C57A93-6247-4BB8-9FFF-877F67D9B70F@ontopia.netDate: Tue, 13 Dec 2005 21:09:55 +0100%0aSubject: %5bsc34wg3%5d Topic maps by another name%0aIn-Reply-To: %3cD113318BC373924285F75C8AC010EC72013B5FC3@SHERWOOD.open.ac.uk%3e%0aReferences: %3cD113318BC373924285F75C8AC010EC72013B5FC3@SHERWOOD.open.ac.uk%3e%0aMessage-ID: %3cE9C57A93-6247-4BB8-9FFF-877F67D9B70F@ontopia.net%3e%0a%0a* M.Altheim%0a%3e%0a%3e To me, rule description languages operate at a level higher than%0a%3e Topic Maps' XTM syntax, higher than RDF syntax, higher than any%0a%3e TM or RDF schema language, and are up in the clouds of KR models%0a%3e where things like KIF live. To that effect, Topic Maps could%0a%3e provide a graph foundation for them, and a great basis upon which%0a%3e to build interchanges, certainly better than anything based in%0a%3e RDF in that respect. I don't see that we've yet built up the%0a%3e edifice of the Topic Maps tool belt to be able to express the%0a%3e kinds of rules that KIF or the W3C RIF charter suggests.%0a%0aI agree with nearly everything you write here, except about whether%0athe edifice is high enough. I'd guess tolog does what they want,%0aunless they want forward-chaining rules. And if they do, it's%0acertainly possible to specify that on top of what we have now.%0a%0a--%0aLars Marius Garshol, Ontopian http://www.ontopia.net%0a+47 98 21 55 50 http://%0awww.garshol.priv.no%0a%0a%0a%0a%0a%0a%0aFrom: sc34wg3@isotopicmaps.org (Murray Altheim)['0019380']['0021454']['0020789']['0021328']['00251']439F6435.4020708@open.ac.ukDate: Wed, 14 Dec 2005 00:15:49 +0000%0aSubject: %5bsc34wg3%5d XTM 1.1 issues: MergeMap%0aIn-Reply-To: %3cD86BC9AE-8B54-4AF5-87CA-0D9E0B21CC87@ontopia.net%3e%0aReferences: %3c0CE25263F839BA44AFDDB7A786BAB8B70749DA1D@Y12MAIL01.y12.doe.gov%3e %3c439E09F8.2060100@open.ac.uk%3e %3cD86BC9AE-8B54-4AF5-87CA-0D9E0B21CC87@ontopia.net%3e%0aMessage-ID: %3c439F6435.4020708@open.ac.uk%3e%0a%0aLars Marius Garshol wrote:%0a%3e * Murray Altheim%0a%3e%0a%3e%3eI don't think of %3cmergeMap%3e as authoring, but a component in%0a%3e%3emodularization.%0a%3e%0a%3e The point is that if you are modularizing in files it must be because%0a%3e you are authoring in files, at which point it does become an%0a%3e authoring issue. If you weren't authoring in files, why would you%0a%3e ever send anyone multiple files? You'd just create a file containing%0a%3e exactly what you wanted to send (by some suitable form of magic) and%0a%3e send that.%0a%0aUntil you or somebody provides me with a functional (and improved)%0aalternative to files that everybody else is also using, the file%0ametaphor is what I'll be using. Since there isn't any alternative%0aI'm not sure what the pejorative attitude regarding files is meant%0ato intend, i.e., it seems pointless to argue about the goodness or%0abadness of files when that is what we have.%0a%0a%3e%3e%5b...%5d%0a%3e%3eas I'd then have to perform a pre-merge for delivery and lose%0a%3e%3ethe modularity, a feature I'm sure is appreciated by those who%0a%3e%3edon't want the entirety of the package, or want to reuse various%0a%3e%3ecomponents.%0a%3e%0a%3e If they could extract the subsets they wanted, without these having%0a%3e to preexist in the form of files, this would not be an issue. Of%0a%3e course, I know they don't have an easy way to do this now, and that's%0a%3e why I'm for keeping this.%0a%0aAn *easy* way? I don't see any *other* way that is widely supported%0aby software and OS, so again, I guess I'm not getting your main point.%0a%0aThere is another point that is perhaps even more important and%0athat is that authoring or not, if I want modules I need to be%0aable to store them, send them, and make them available individually/%0aindependently. I want modules, plug and play. %3cmergeMap%3e provides%0athe little nobbies on the tops of the Lego bricks. Without the%0anobbies, my castle falls over.%0a%0aMurray%0a%0a......................................................................%0aMurray Altheim http://www.altheim.com/murray/%0aStrategic Services Development Manager%0aThe Open University Library and Learning Resources Centre%0aThe Open University, Milton Keynes, Bucks, MK7 6AA, UK .%0a%0aAs late as 1855, New York newspapers reported that Presbyterian,%0aBaptist and Methodist churches were closed on Dec. 25 because%0a"they do not accept the day as a Holy One." On the eve of the%0aCivil War, Christmas was recognized in just 18 states.%0ahttp://www.nytimes.com/2005/12/04/opinion/04sun3.html%0a%0a%0aFrom: sc34wg3@isotopicmaps.org (Robert Barta)['0019018']['0021445']['0020966']['0020445']['00257']['0019278']['0019546']20051214102645.GC6431@mando.rho.priv.atDate: Wed, 14 Dec 2005 20:26:45 +1000%0aSubject: %5bsc34wg3%5d XTM 1.1 issues: MergeMap%0aMessage-ID: %3c20051214102645.GC6431@mando.rho.priv.at%3e%0a%0aOn Wed, Dec 14, 2005 at 12:15:49AM +0000, Murray Altheim wrote:%0a%3e %3e* Murray Altheim%0a%3e %3e%0a%3e %3e%3eI don't think of %3cmergeMap%3e as authoring, but a component in%0a%3e %3e%3emodularization.%0a%3e %3e%0a%3e %3eThe point is that if you are modularizing in files it must be because%0a%3e %3eyou are authoring in files, at which point it does become an%0a%3e %3eauthoring issue. If you weren't authoring in files, why would you%0a%3e %3eever send anyone multiple files? You'd just create a file containing%0a%3e %3eexactly what you wanted to send (by some suitable form of magic) and%0a%3e %3esend that.%0a%3e%0a%3e Until you or somebody provides me with a functional (and improved)%0a%3e alternative to files that everybody else is also using, the file%0a%3e metaphor is what I'll be using.%0a%0aI think the 'file metaphor' is fine, especially for serialized topic%0amap content, such as one written in LTM or XTM. But it breaks down if%0aI start to hold my content in a dedicated TM database. I can still%0ause URIs, though:%0a%0atm:/users/rho/cv/%0a%0aIt also breaks down if I want to wrap a non-topic-map resource with a%0aTM wrapper (as in my favourite example of a DNS server 'seen' as topic%0amap):%0a%0adns:localhost/%0a%0aIf I want to 'merge' these two topic maps, where should I put it now?%0aMy reflex is to say "put it as an expression into a query language":%0a%0atm:/users/rho/cv/ + dns:localhost/%0a%0aAnd if it works for these, why not for the case of files:%0a%0amurray_likes.ltm + jim_likes.xtm%0a%0aSo %3cmergeMap%3e is an evolutionary crutch. It will probably stick with%0aus until proper tool support.%0a%0a\rho%0a%0aFrom: sc34wg3@isotopicmaps.org (M.Altheim)['0021440']['0020966']['0020445']['00275']['0019402']2066D1EC-D4A8-426A-A367-FFDDA9329265@ontopia.netDate: Wed, 14 Dec 2005 15:16:34 +0100%0aSubject: %5bsc34wg3%5d XTM 1.1 issues%0aIn-Reply-To: %3c20051214101549.GA6431@mando.rho.priv.at%3e%0aReferences: %3cm3fyp72tea.fsf@ontopia.net%3e %3c20051214101549.GA6431@mando.rho.priv.at%3e%0aMessage-ID: %3c2066D1EC-D4A8-426A-A367-FFDDA9329265@ontopia.net%3e%0a%0a* Robert Barta%0a%3e%0a%3e I support this view, namely that of XTM being an _interchange_ syntax,%0a%3e not an authoring syntax. This is a shift of focus away from the%0a%3e 2000iesh understanding, though, which some members will be reluctant%0a%3e to follow.%0a%0aWell, it was there in the requirements, right at the top of the XTM%0a1.0 document, even if it wasn't really followed. :)%0a%0a%3e %5b%3ctopicName%3e%5d%0a%3e%0a%3e Me too, although the separate %3cvalue%3e element is not overly lean.%0a%0aWe can't just dump the value into the content of the topicName%0aelement, as this causes difficulties with roundtripping of%0awhitespace, etc. So I can't really see a way to do without %3cvalue%3e,%0aregardless of what we call it. (Kal already suggested reusing%0a%3cresourceData%3e instead, but that has a datatype attribute, so that's%0aoff.)%0a%0a* Lars Marius Garshol%0a%3e%0a%3e This change, however, makes it difficult to write the XSLT translation%0a%3e stylesheet, though that's not really a valid argument against it. The%0a%3e translation is still very much possible, it just becomes hard to do in%0a%3e XSLT.%0a%0a* Robert Barta%0a%3e%0a%3e I thought it would get easier: fewer elements, one canonical place to%0a%3e find things...%0a%0aThis was referring specifically to the XSLT stylesheet for converting%0aXTM 1.0 documents to XTM 1.1 that the committee said we have to%0ainclude in the spec. I think I can see a way to do it, though, so we%0ashould be OK.%0a%0a%3e Hmmm, should item identifiers really be serialized? Is this role not%0a%3e completely covered with IDs on topics and the "reifier" attribute%0a%3e above?%0a%0aIt's not strictly speaking needed, but without it%0a%0a(1) Not all aspects of the model can be interchanged, and%0a%0a(2) It is impossible to use XTM 1.1 to support distributed editing%0ascenarios by passing fragments between client and server.%0a%0aWhether the latter falls under the interchange heading could be%0adiscussed at length, but what decided the editors was that without it%0athis can't be done at all within standard XTM 1.1.%0a%0a%3e I have critized %3cmergeMap%3e for many years exactly for the reasons you%0a%3e write, especially for interchange. Even for authoring, I am EXTREMELY%0a%3e reluctant to have such a "include" feature. It is NOT the right horse%0a%3e for the right course.%0a%0aI agree. An alternative (proposed by Kal) would be to create an extra%0aTopic Map Packaging syntax that can be used to define modules by%0ahaving references to the files to read in. We decided not to do this%0aas adding one more syntax this late in the process is not really a%0agood idea. It would also mean that the modules would not be self-%0acontained, in the sense that they would not declare themselves what%0athey needed.%0a%0aSo I think the reality is that %3cmergeMap%3e will stay with us for a while.%0a%0a%3e %5bxml:base%5d%0a%3e%0a%3e If%0a%3e%0a%3e - topicRefs only point to topics and are IDREF%0a%3e - and consequently EVERYTHING can be interpreted 'relative' (inside%0a%3e the document),%0a%3e%0a%3e then you might be able to remove it. But this has to be thought%0a%3e through.%0a%0aWell, we can have topicRef point using IRIs without supporting%0axml:base. Everything should work just as well without xml:base, I%0awould think. You just use normal relative IRIs, and make sure that%0ayou distribute all the files.%0a%0a%3e There are no badCamels and no GoodCamels (only the camel on the Perl%0a%3e book is a good camel) :-)%0a%0aI agree there are no good camels. :)%0a%0a%3e PS: Your cleanup efforts are MUCH appreciated.%0a%0aThanks for the comments. It really helps to get this kind of feedback.%0a%0a--%0aLars Marius Garshol, Ontopian http://www.ontopia.net%0a+47 98 21 55 50 http://%0awww.garshol.priv.no%0a%0a%0a%0aFrom: sc34wg3@isotopicmaps.org (Lars Marius Garshol)['0019278']['0021454']['0021393']['0020445']['00285']94AB8A1A-DAF9-4331-96C9-3B55B3B9D0DB@ontopia.netDate: Wed, 14 Dec 2005 15:25:30 +0100%0aSubject: %5bsc34wg3%5d XTM 1.1 issues%0aIn-Reply-To: %3cD113318BC373924285F75C8AC010EC72013B5FC6@SHERWOOD.open.ac.uk%3e%0aReferences: %3cD113318BC373924285F75C8AC010EC72013B5FC6@SHERWOOD.open.ac.uk%3e%0aMessage-ID: %3c94AB8A1A-DAF9-4331-96C9-3B55B3B9D0DB@ontopia.net%3e%0a%0a* M.Altheim%0a%3e%0a%3e Since you guys are in charge of the process and feel it within%0a%3e your rights and duty to make such substantive changes to XTM,%0a%3e such that to my eyes at least it doesn't look or act remotely%0a%3e like the syntax of the current markup language, why not call%0a%3e it something else? You've plainly got a much different agenda%0a%3e than we had in 2000, as things you call "errors" in XTM 1.0%0a%3e were deliberate design decisions, not errors at all, and things%0a%3e you seem to feel are "irritants" have seldom been for me (and%0a%3e apparently others, who've been able to successfully build Topic%0a%3e Map applications around the current XTM syntax).%0a%0aThere are a lot of things in XTM 1.0 that cause unintended%0adifficulties for implementors. The added themes feature on %3cmergeMap%3e%0ais one example of this, and the order of %3cinstanceOf%3e and%0a%3csubjectIdentity%3e within %3ctopic%3e is another. Removing these warts%0amakes it much easier to implement the syntax, which was one of the%0agoals of this project.%0a%0aAs for feeling it our duty to do this, well, both me and Graham%0astrongly opposed making any changes at all to XTM, but were%0aoverridden by the committee. So neither of us really disagree with%0ayou, but once the committee has made its decision we have no more%0apower to change it than you do, really. I've gone on record before%0asaying that stability is the most important thing, and I still think%0aso, but once you change the namespace URI you've changed everything%0aanyway, so...%0a%0a%3e In looking at the various changes that have been proposed, I can%0a%3e say that it's rather unlikely that I'd myself have much use for%0a%3e the new "XTM", as it doesn't suit many of my own needs and seems%0a%3e to have processing implications different from and far beyond what%0a%3e I've been doing for the past five years with XTM 1.0.%0a%0aThat's why we posted the list of *proposals* to this list, in order%0ato get feedback from the community so that we could ensure that we%0awould not cause difficulties for anyone by these changes. So if you%0aare against any of the proposed changes, please tell us, and we'll%0asee what we can do. I note that you're against removing %3cmergeMap%3e,%0aand that's one of the reasons it's now staying after all. If nobody%0ahad complained Graham and I would have happily ripped it out.%0a%0aBut what else is it you don't like? If you tell us now you can still%0ahope to affect the syntax, but time is running out.%0a%0a%3e ... in%0a%3e many cases you've even either changed or invented a different%0a%3e descriptive vocabulary than we used then.%0a%0aThat vocabulary has been developed over the last four and a half%0ayears (since Berlin in May 2001) as part of an open standards process%0awhere even non-members of the organization could contribute (and have%0acontributed!). The only thing we're doing is to bring the syntax into%0aline with the terminology that has been used in the model for the%0apast years. If you didn't like the model terminology, well, you've%0ahad years in which to tell us.%0a%0a--%0aLars Marius Garshol, Ontopian http://www.ontopia.net%0a+47 98 21 55 50 http://%0awww.garshol.priv.no%0a%0a%0a%0aFrom: sc34wg3@isotopicmaps.org (Martin Bryan)['0019402']['0021454']['0021393']['0020445']['00291']019b01c600ea$6ab71b10$0602a8c0@MAINFRAMEDate: Wed, 14 Dec 2005 20:10:21 -0000%0aSubject: %5bsc34wg3%5d XTM 1.1 issues%0aReferences: %3cD113318BC373924285F75C8AC010EC72013B5FC6@SHERWOOD.open.ac.uk%3e%0aMessage-ID: %3c019b01c600ea$6ab71b10$0602a8c0@MAINFRAME%3e%0a%0aMurray wrote%0a%0a%3eIn looking at the various changes that have been proposed, I can%0asay that it's rather unlikely that I'd myself have much use for%0athe new "XTM", as it doesn't suit many of my own needs and seems%0ato have processing implications different from and far beyond what%0aI've been doing for the past five years with XTM 1.0. I don't%0aclaim XTM 1.0 is perfect, but what you've been talking about%0adoesn't seem to be XTM at all, but some other, new language that%0ahas only peripheral connections to the work done in 2000, and in%0amany cases you've even either changed or invented a different%0adescriptive vocabulary than we used then. It certainly doesn't%0alook like an "XTM 1.1" anymore, maybe a "XTI", "TMI", "TMDML" or%0asomething else.%0a%0a%3eI think it's time to call your duck a dog, if it barks instead%0aof quacks.%0a%0aHyTM :-)%0a%0aBut then I thought that way about XTM as well :-(%0a%0aMartin Bryan%0a%0a%0aFrom: sc34wg3@isotopicmaps.org (Lars Heuer)['0021451']['0021393']['0020445']['00297']['0019601']['0019679']1971098028.20051215170736@semagia.comDate: Thu, 15 Dec 2005 17:07:36 +0100%0aSubject: %5bsc34wg3%5d Re: TMDM comments%0aIn-Reply-To: %3c7D1DA50B-D62C-450F-AE01-C9DB28570CEE@ontopia.net%3e%0aReferences: %3cBB0074F0-F3CC-4210-A6E3-2D62712E36CA@ontopia.net%3e%0a%3c583935459.20051215161908@semagia.com%3e%0a%3c7D1DA50B-D62C-450F-AE01-C9DB28570CEE@ontopia.net%3e%0aMessage-ID: %3c1971098028.20051215170736@semagia.com%3e%0a%0aHi Lars,%0a%0a%5b...%5d%0a%3e%3e Anyway I think it would be nice if such such an important thing is%0a%3e%3e directly addressable.%0a%0a%3e You mean if there was a direct link there? Hmmmmm. If I change the%0a%3e RELAX-NG schema, the stylesheet, and put in anchors, there would be%0a%3e points to link to, even if those points didn't appear in the ToC.%0a%3e Would that work for you?%0a%0aSure :)%0a%0aBest regards,%0aLars%0a--%0ahttp://semagia.com%0a%0a%0aFrom: sc34wg3@isotopicmaps.org (Lars Marius Garshol)['0019679']['0021267']['0020939']['0020444']['00314']['0019895']['0018611']['0019280']['0018745']['0019113']['0019055']43A2F00C.8080704@open.ac.ukDate: Fri, 16 Dec 2005 16:49:16 +0000%0aSubject: %5bsc34wg3%5d XTM 1.1 issues%0aIn-Reply-To: %3c149507000.20051216131419@semagia.com%3e%0aReferences: %3cD113318BC373924285F75C8AC010EC72013B5FC6@SHERWOOD.open.ac.uk%3e %3c1353365904.20051215175003@semagia.com%3e %3c43A1BB76.1080501@open.ac.uk%3e %3c149507000.20051216131419@semagia.com%3e%0aMessage-ID: %3c43A2F00C.8080704@open.ac.uk%3e%0a%0aLars Heuer wrote:%0a%3e Hi Murray,%0a%3e%0a%3e %5b...%5d%0a%3e%0a%3e%3e%3eAnyway, I think it is a failure to keep the mergeMap element in the%0a%3e%3e%3eXTM 1.1. This might belong to the upcoming CTM syntax which is%0a%3e%3e%3edesigned for _authoring_ topic maps, while XTM should be designed for%0a%3e%3e%3e_interchanging_ topic maps (XTM should be readable by humans, though).%0a%3e%0a%3e%3ePerhaps you have a limited view of interchange. I think of being%0a%3e%3eable to interchange either an entire vocabulary, or, when we talk%0a%3e%3eabout modularization, a subset of a vocabulary. When looking at%0a%3e%0a%3e Jep, I'd call my view a "different" view, not a "limited", but okay.%0a%3e :)%0a%0aWell, you defined a version of "interchange" that didn't include the%0ause case I had provided, so by definition your view is more limited%0athan mine. That's all I meant.%0a%0a%3e IMO the supplier of the topic map can extract a fragment from it (i.e.%0a%3e using TMQL or tolog) and send it to the client. Or the client extracts%0a%3e the fragments of interest by herself.%0a%0aThis is a more complicated scenario than I either imagined or was%0aproviding as my use case, which is merely the distribution of one%0aor more LTM or XTM files over the Web.%0a%0a%3e%3eprecisely the functionality necessary. At an application level, it%0a%3e%3epermits either a human or program to decide whether or not to%0a%3e%3etraverse the link bringing in the module. "Interchange" in this%0a%3e%0a%3e At application level the human or program decides to merge the topic%0a%3e map X with the topic map Y as \rho and LMG has pointed out. She can%0a%3e decide the merging of topic maps without a mergeMap element.%0a%3e %5b...%5d%0a%0aYes, in that scenario the mergeMap element is not required. In my%0ascenario it is. My scenario is simpler and therefore more likely%0ato be used by people. Your scenario is also proposing that merging%0aof individual Topic Maps happens only within an application, then%0athe already-merged result is serialized for interchange. My scenario%0ainvolves providing a set of Topic Map documents from which a user or%0aan application can pick and choose as necessary. Yes, my scenario%0ainvolves a file metaphor, the predominant one in use worldwide at%0athis time, and likely for at least the next decade.%0a%0a%3e %5b...%5d%0a%3e%0a%3e Anyway, it seems that the mergeMap element will stay, but I am not%0a%3e very happy with it.%0a%3e%0a%3e Summary: Murray is unhappy with XTM 1.1, Lars is happy with XTM 1.1%0a%3e but not with the mergeMap element. :)%0a%0aNo, I have not expressed that I am unhappy with XTM 1.1, only that%0ait is misnamed. I'm sure that given Lars Marius is an excellent%0aengineer, that it is very likely a very good serialization of the%0aTMDM model of Topic Maps. It's just not "XTM" anymore.%0a%0aMurray%0a%0a......................................................................%0aMurray Altheim http://www.altheim.com/murray/%0aStrategic Services Development Manager%0aThe Open University Library and Learning Resources Centre%0aThe Open University, Milton Keynes, Bucks, MK7 6AA, UK .%0a%0aAs late as 1855, New York newspapers reported that Presbyterian,%0aBaptist and Methodist churches were closed on Dec. 25 because%0a"they do not accept the day as a Holy One." On the eve of the%0aCivil War, Christmas was recognized in just 18 states.%0ahttp://www.nytimes.com/2005/12/04/opinion/04sun3.html%0a%0aFrom: sc34wg3@isotopicmaps.org (Murray Altheim)['0018745']['0021445']['0021393']['0021329']['00354']['0019674']['0019222']['0019004']['0018589']['0019553']['0019220']20051217002837.GB4167@mando.rho.priv.atDate: Sat, 17 Dec 2005 10:28:37 +1000%0aSubject: %5bsc34wg3%5d Re: TMDM minor suggestion%0aIn-Reply-To: %3cD7C71CF2-D51C-411D-AD9C-E3C18B6C8CE6@ontopia.net%3e%0aReferences: %3c1762DD9D-334D-41C9-B31F-E65269229919@ontopia.net%3e %3c20051214102328.GB6431@mando.rho.priv.at%3e %3cD7C71CF2-D51C-411D-AD9C-E3C18B6C8CE6@ontopia.net%3e%0aMessage-ID: %3c20051217002837.GB4167@mando.rho.priv.at%3e%0a%0aOn Thu, Dec 15, 2005 at 05:08:50PM +0100, Lars Marius Garshol wrote:%0a%3e %3e%5b6.2, point 8%5d%0a%3e %3e%0a%3e %3e2) and 3) only seem to replace the _involvement_ of A and B throughout%0a%3e %3ethe instance. But A and B as topic items still remain, or not? Maybe I%0a%3e %3ejust have another interpretation of 'replace'?%0a%3e%0a%3e Since they are replaced in the topic map.%5btopics%5d property in steps 2%0a%3e and 3 .....%0a%0aAaaaah! That was far too mechanicistic for me :-) But I see now.%0a%0a\rho%0a%0aFrom: sc34wg3@isotopicmaps.org (Robert Barta)['0019895']['0021440']['0021214']['0020441']['00395']20051217011404.GC4167@mando.rho.priv.atDate: Sat, 17 Dec 2005 11:14:04 +1000%0aSubject: %5bsc34wg3%5d Editors' drafts of TMDM and XTM 1.1%0aIn-Reply-To: %3c43A2F07F.4060203@open.ac.uk%3e%0aReferences: %3cB9F29515-3C91-40C6-A42D-3B258B632382@ontopia.net%3e %3c43A2F07F.4060203@open.ac.uk%3e%0aMessage-ID: %3c20051217011404.GC4167@mando.rho.priv.at%3e%0a%0a%3e Lars Marius Garshol wrote:%0a%3e %3eThe editors have now produced new drafts of TMDM and XTM 1.1 at%0a%3e %3e http://www.isotopicmaps.org/sam/%0a%0aOn Fri, Dec 16, 2005 at 04:51:11PM +0000, Murray Altheim wrote:%0a%3e I would hope that the ISO editors reconsider calling their%0a%3e markup language something other than "XTM", as by all counts%0a%3e (including your own remarks above) it no longer continues in%0a%3e any tradition (grammatically or semantically) with what XTM%0a%3e 1.0. It has redefined existing grammatical tokens, made funda-%0a%3e mental alterations to their meaning and behaviour, and added%0a%3e or subtracted enough of the language that any resemblance to%0a%3e XTM 1.0 is only peripheral, and perhaps misleading.%0a%0aHmmm, I cannot see that. In%0a%0ahttp://www.isotopicmaps.org/sam/sam-xtm/#xtm1.0-differences%0a%0athere are several replacements (without semantic impact) and the only%0asemantically relevant changes seem to be:%0a%0a- mergeMap no scoping (who really used it? Except you :-)%0a- datatypes added (we all want that, no?)%0a%0aEverything TAOish is all still there. So if a duck quacks like a duck,%0aI would still call it a duck. And not a dog. ;-%5d%0a%0aIOW, XTM 1.1 would be fine for me.%0a%0a\rho%0a%0aFrom: sc34wg3@isotopicmaps.org (Lars Marius Garshol)['0019674']['0021440']['0021383']['0020441']['00401']B41D6F3F-DFBA-48F9-9177-AB87914F4FB4@ontopia.netDate: Sat, 17 Dec 2005 14:02:28 +0100%0aSubject: %5bsc34wg3%5d XTM 1.1 issues%0aIn-Reply-To: %3c02e601c6027b$f4b31d90$0602a8c0@MAINFRAME%3e%0aReferences: %3cD113318BC373924285F75C8AC010EC72013B5FC6@SHERWOOD.open.ac.uk%3e %3c1353365904.20051215175003@semagia.com%3e %3c43A1BB76.1080501@open.ac.uk%3e %3c02e601c6027b$f4b31d90$0602a8c0@MAINFRAME%3e%0aMessage-ID: %3cB41D6F3F-DFBA-48F9-9177-AB87914F4FB4@ontopia.net%3e%0a%0a* Martin Bryan%0a%3e%0a%3e XTMDM would show its origins%0a%0aThat sounds rather bizarre to me. TMDM was constructed to be the%0amodel that was missing from XTM 1.0, and has taken a lot of flak over%0athe years for being too faithful to XTM 1.0. So now that we%0asynchronize XTM with the result of the model work over four and a%0ahalf years, you want us to name it after the model that was created%0afor XTM? If we wanted to change the name to show the origins, why not%0aXTMXTM?%0a%0aThe changes that have been made in the new XTM version are there for%0atwo reasons:%0a%0a(1) We've had five years of experience with XTM, and the result of%0athat%0ais that some of the things that seemed like a good idea in%0alate 2000%0ano longer do. (Like XLink support, which I argued strongly for%0aback%0athen.)%0a%0a(2) Developing the model has given us new insights into the%0aconcepts the%0asyntax is meant to be a representation of, simply because those%0aconcepts were not fully developed at the time the syntax was%0acreated.%0aNow that the concepts have been fully developed, we see that some%0athings in the syntax can be improved on, and so we're%0aimproving it%0anow. (This is why people were arguing so forcefully back in%0a2000 that%0athe model should have been developed first. Had that happened%0athe last%0afive years would probably have looked rather different.)%0a%0aTo me, this really is just another small step onwards from XTM 1.0. I%0acan't see any reason why we should change the name. If we'd come up%0awith something like TM/XML and proposed that as XTM 1.1 (or 2.0) I%0awould have understood the objections, but not with the current draft.%0a%0a%3e and show it was an extension to the original concept.%0a%0aWell, the extensions are types on names and datatypes. That's not%0amuch of an extension, is it?%0a%0a%3e Coming at things from the other direction, I'm struggling with%0a%3e subsetting%0a%3e ontologies that are ridiculously large (millions of RDF triples).%0a%3e If the%0a%3e ontology had been properly designed in a modular format things%0a%3e would have%0a%3e been infinitely easier. Long live modularization features.%0a%0aWell, %3cmergeMap%3e is staying, so they're not dying yet.%0a%0a(BTW: I've been able to convert that ontology to a topic map, but the%0auntimely demise of my previous laptop has prevented me from loading%0ait into the RDBMS backend so it could be visualized with a custom%0aNavigator application. Still hoping to be able to do that.)%0a%0a--%0aLars Marius Garshol, Ontopian http://www.ontopia.net%0a+47 98 21 55 50 http://www.garshol.priv.no%0a%0a%0a%0aFrom: sc34wg3@isotopicmaps.org (Lars Heuer)['0019220']['0021454']['0021393']['0020441']['00407']489479182.20051219174243@semagia.comDate: Mon, 19 Dec 2005 17:42:43 +0100%0aSubject: %5bsc34wg3%5d TMDM - Proposal for the removal of variant items%0aIn-Reply-To: %3cC37AF3A1-581F-417D-B54B-B594D0A7D6BC@ontopia.net%3e%0aReferences: %3c114969444.20051216155937@semagia.com%3e%0a%3cC37AF3A1-581F-417D-B54B-B594D0A7D6BC@ontopia.net%3e%0aMessage-ID: %3c489479182.20051219174243@semagia.com%3e%0a%0aHi Lars,%0a%0a%5b...%5d%0a%3e%3e Even if this proposal cannot be considered because of ISO regulations%0a%3e%3e (TMDM becomes FDIS) I'd like to bring it to your attention.%0a%0a%3e I'd certainly be interested to hear what people think of this.%0a%3e Personally, I am mostly neutral on this one.%0a%0aYes, comments, critiques etc. very much welcome. I am a bit%0aembarrassed, but I'd like to hear some opinions.%0a%0aBest regards,%0aLars%0a--%0ahttp://semagia.com%0a%0a%0aFrom: sc34wg3@isotopicmaps.org (Lars Marius Garshol)['0018589']['0021267']['0020705']['0020436']['00413']['0019083']37F03362-CD63-4A9A-8B87-A4A2EB681443@ontopia.netDate: Wed, 21 Dec 2005 08:55:03 +0100%0aSubject: %5bsc34wg3%5d TMDM is out for FDIS ballot%0aMessage-ID: %3c37F03362-CD63-4A9A-8B87-A4A2EB681443@ontopia.net%3e%0a%0aTMDM is now out for FDIS ballot, and XTM is out for review. The pages%0aon www.isotopicmaps.org have been updated, but the changes are%0aminuscule.%0a%0a--%0aLars Marius Garshol, Ontopian http://www.ontopia.net%0a+47 98 21 55 50 http://www.garshol.priv.no%0a%0a%0a%0aFrom: sc34wg3@isotopicmaps.org (Lars Heuer)['0021454']['00425']['0020563']TMDM is out for FDIS ballot['00424']['00424']1976944256.20051221123315@semagia.comDate: Wed, 21 Dec 2005 12:33:15 +0100%0aSubject: %5bsc34wg3%5d XTM 1.1 / TMDM item identifiers%0aMessage-ID: %3c1976944256.20051221123315@semagia.com%3e%0a%0aHi,%0a%0aIn the XTM 1.1 thread the idea to remove the %5bitem identifiers%5d%0aproperty (except from topics) was brought up.%0a%0aNow, the latest versions of XTM 1.1 / TMDM keep the %5bitem identifiers%5d%0aat all topic map constructs.%0a%0aI am curious why the decision was made to keep the %5bitem identifiers%5d.%0a%0aThanks and best regards,%0aLars%0a--%0ahttp://semagia.com%0a%0a%0aFrom: sc34wg3@isotopicmaps.org (Robert Barta)['0021267']['00430']['0020563']XTM 1.1 / TMDM item identifiers['00429']['00429']['0018703']['0018666']1AEFC4BF-5C1B-4A81-A529-43E926B62406@ontopia.netDate: Fri, 30 Dec 2005 15:48:08 +0100%0aSubject: %5bsc34wg3%5d Status of www.topicmaps.org ?%0aIn-Reply-To: %3cGOEIKOOAMJONEFCANOKCMEBJHIAA.bernard.vatant@mondeca.com%3e%0aReferences: %3cGOEIKOOAMJONEFCANOKCMEBJHIAA.bernard.vatant@mondeca.com%3e%0aMessage-ID: %3c1AEFC4BF-5C1B-4A81-A529-43E926B62406@ontopia.net%3e%0a%0a* Bernard Vatant%0a%3e%0a%3e What I get today is%0a%3e http://www.topicmaps.org redirects to OASIS Home Page%0a%3e http://www.topicmaps.org/xtm/1.0/ is 404 Not Found%0a%3e%0a%3e Can somebody explain?%0a%0aIt works fine now. I think it must have been a temporary sysadmin%0aproblem.%0a%0a--%0aLars Marius Garshol, Ontopian http://www.ontopia.net%0a+47 98 21 55 50 http://www.garshol.priv.no%0a%0a%0a['0018666']['0021454']['0020883']['00448']2005/12/30['00445']['00445']%5bu'Christian Wohlgensinger'%5d['0020649']['0019209']%5b%5d2001/12/04['0019209']['0019209']m3vgf5q49y.fsf@lambda.garshol.priv.noDate: 17 Dec 2001 16:01:45 +0100%0aSubject: %5bsc34wg3%5d Status of TM activities%0aIn-Reply-To: %3cBEEJLKMGLGMCEKOPHJKBKEOACBAA.wohlgensinger@mondax.com%3e%0aReferences: %3cBEEJLKMGLGMCEKOPHJKBKEOACBAA.wohlgensinger@mondax.com%3e%0aMessage-ID: %3cm3vgf5q49y.fsf@lambda.garshol.priv.no%3e%0a%0aHi Christian,%0a%0aThis request is not really appropriate for this list, which is an%0ainternal working list for WG3, so the question would have been better%0aplaced on the topicmapmail list that Michel Biezunski runs. In fact,%0ayou shouldn't even have been allowed to post this. I don't know why%0ayour posting went through. (All this just FYI.)%0a%0a* Christian Wohlgensinger%0a|%0a| Is it possible to get any update about the status of TopicMap%0a| related work within ISO?%0a| Are there any planed activities?%0a%0aThe Orlando meeting of SC34 WG3 defined a roadmap for its further%0awork, which is currently being reviewed by the individual WG3 members.%0aIt will be posted publicly once they've had some days to chew on it.%0aThat document should probably tell you what you need to know.%0a%0a| Will XTM (or a changed version of it) become an official ISO%0a| standard?%0a%0aThe DTD has already been included in the ISO standard (see the%0aannouncement by Michel Biezunski on topicmapmail). The roadmap will%0ashow how complete integration of XTM with the original ISO standard%0awill be done.%0a%0a| How about the liaison with OASIS?%0a%0aIt's now approved and operating.%0a%0a| Is there a timeline?%0a%0aNo official timeline, but we expect to have substantial drafts of the%0afirst two working documents mentioned in the roadmap by Barcelona.%0a%0a| I`m sure, that those information are of interest to any party%0a| investing in Topic Maps.%0a%0aAbsolutely, which is another reason to have this discussion on%0atopicmapmail. :-)%0a%0a--Lars M.%0a%0a%0aFrom: sc34wg3@isotopicmaps.org (Lars Marius Garshol)['0019209']['0021454']['0020649']['0020554']['00456']m3heqppxs1.fsf@lambda.garshol.priv.noDate: 17 Dec 2001 18:22:06 +0100%0aSubject: %5bsc34wg3%5d Comments to N0277%0aMessage-ID: %3cm3heqppxs1.fsf@lambda.garshol.priv.no%3e%0a%0aI've just read through the XTM 1.0 and HyTM syntax comparison thing,%0aand jotted down my comments on it. I've posted them here, as it seems%0alike there will be some back-and-forth, which is likely to be much%0afaster outside the national body comment ping-pong procedure.%0a%0aRough comments follow below.%0a%0a%0aWhat is the intended audience for this document? It's probably been%0amentioned somewhere, but I've missed or forgotten it. Maybe it would%0abe an idea to mention this in the document itself? This would make the%0adocument more self-documenting, and make it easier for people to link%0ato it appropriately.%0a%0aWhat is the section "Describing the semantics of both syntaxes"%0asupposed to do? I've read it twice, but am still not sure. Is it%0asupposed to say that "the new topic map standard will explain this in%0adetail, but here is a summary of the syntax differences"? Or is it%0ameant to say something else? Or should it just be cut?%0a%0aThe "The difference between topic map syntax and topic map%0ainformation" section should probably be updated to use the new%0aterminology adopted in Orlando. The term "topic map parser" sounds a%0abit troublesome. Perhaps it is best to remove it?%0a%0aThe document should perhaps also be updated to define and use the term%0a"HyTM syntax"?%0a%0aComments on the syntax section:%0a%0a- the differences in the structure of topic names is not mentioned%0a%0a- in HyTM associations consist of (role type, role player) assocrl%0aelements, while in XTM 1.0 they consist of (role spec, role%0aplayer+) member elements:%0a%0a- terminology differences member/role, role type/role spec%0a%0a- structural differences: single player vs multiple players%0a%0a- the term "theme" is not used in XTM 1.0%0a%0a- no added themes in XTM 1.0%0a%0a- no "TMBrid" in XTM 1.0%0a%0a- the terms "topic link" and "association link" are not used in XTM 1.0%0a%0a- no mnemonics in XTM 1.0 (topic / @linktype, occurs / @occrl ...)%0a%0a- no scope on topics in XTM 1.0%0a%0a- no mergeMap in HyTM%0a%0a- there was something about scope that ISO 13250:2000 got wrong,%0aaccording to SRN. I've forgotten what it was, but this may help SRN%0aremember. :-)%0a%0a--Lars M.%0a%0a['0021454']['00463']['0020554']Comments to N0277['00462']['00462']40E9279A.6030800@sbl-site.orgDate: Mon, 05 Jul 2004 06:04:10 -0400%0aSubject: %5bsc34wg3%5d New TMRM document posted%0aMessage-ID: %3c40E9279A.6030800@sbl-site.org%3e%0a%0aGreetings!%0a%0aIn preparation for the reference model workshop in Montreal, Steve%0aNewcomb and I have submitted: Narrative About the Topic Maps --%0aReference Model, document number 527.%0a%0aIt is quite short but in non-ISO style tries to summarize what we see as%0athe principles underlying the reference model and addressing what we see%0aas failures of explanation on our part in prior drafts of the TMRM.%0a%0aComments and suggestions are welcome. The more we can do online prior to%0aMontreal, the more focused and productive our time can be when we are at%0athe reference model workshop.%0a%0aNote that I will be traveling from 21 July until the meeting so posts on%0aor after that day may have responses delayed for a day or two. I should%0aarrive in Montreal late on the 29th of July (from Amsterdam) so may or%0amay not be coherent enough to informally discuss the reference model%0alate on the 30th in preparation for the workshop. I am staying at the%0amain hotel.%0a%0aHope everyone is at the start of a great week!%0a%0aPatrick%0a%0a--%0aPatrick Durusau%0aDirector of Research and Development%0aSociety of Biblical Literature%0aPatrick.Durusau@sbl-site.org%0aChair, V1 - Text Processing: Office and Publishing Systems Interface%0aCo-Editor, ISO 13250, Topic Maps -- Reference Model%0a%0aTopic Maps: Human, not artificial, intelligence at work!%0a%0a%0a%0aFrom: sc34wg3@isotopicmaps.org (Steven R. Newcomb)['0021442']['0020902']['00469']2004/07/05['00467']['00467']Extreme 2004['0019954']['0019954']1089322244.4525.10.camel@localhost.localdomainDate: 08 Jul 2004 17:30:44 -0400%0aSubject: %5bsc34wg3%5d Montreal%0aIn-Reply-To: %3c85r7rm8ggm.fsf@coolheads.com%3e%0aReferences: %3c85r7rm8ggm.fsf@coolheads.com%3e%0aMessage-ID: %3c1089322244.4525.10.camel@localhost.localdomain%3e%0a%0aUnfortunately, last minute work/official meetings%0awhere I need to be present oblige me to cancel my%0aparticipation to the TM workshop. I expect to be%0aactively involved in the forthcoming activities%0aand hope that the meeting in Montreal will be%0aexciting and fruitful. Sorry to not be there to share%0athese moments with you.%0a%0aMichel%0a--%0a==================================%0aMichel Biezunski%0aCoolheads Consulting%0a402 85th Street #5C%0aBrooklyn NY 11209%0aEmail: mb@coolheads.com%0aWeb : http://www.coolheads.com%0aVoice: (718) 921-0901%0a==================================%0a%0a%0a%0aFrom: sc34wg3@isotopicmaps.org (=?iso-8859-1?Q?Dipl.-Wirtsch.-Inf._Lutz_Maicher_=5BUniversit=E4t_Leipzi?= =?iso-8859-1?Q?g=5D?=)['0019954']['0021443']['0020746']['0020077']['00477']%5bu'Dipl.-Wirtsch.-Inf._Lutz_Maicher_%5bUniversit\xe4t_Leipzi g%5d'%5d['0020902']['0019980']%5b%5d['0019980']FOEHKIENIPCJNPNFKGJNIELJOIAA.pepper@ontopia.netDate: Mon, 12 Jul 2004 22:19:07 +0200%0aSubject: %5bsc34wg3%5d New TMRM document posted%0aIn-Reply-To: %3c00c101c4650c$edb43640$5c0d128b@Maicher%3e%0aMessage-ID: %3cFOEHKIENIPCJNPNFKGJNIELJOIAA.pepper@ontopia.net%3e%0a%0aHi Lutz,%0a%0a| I'm interested in this paper but unfortunately it isn't available at%0a| http://www.y12.doe.gov/sgml/sc34/document/0550.htm%0a%0aSince the secretariatet of SC34 moved to Ken Holman and%0aCanada, the definitive repository is now at%0a%0ahttp://www.jtc1sc34.org/repository/0550.htm%0a%0aJim Mason's site at Y12 is being maintained as an archive,%0abut (as far as I know) not be updated on a regular basis.%0a%0aBest regards,%0a%0aSteve%0a%0a--%0aSteve Pepper %3cpepper@ontopia.net%3e%0aChief Strategy Officer, Ontopia%0aConvenor, ISO/IEC JTC 1/SC 34/WG 3%0aEditor, XTM (XML Topic Maps 1.0)%0a%0a%0aFrom: sc34wg3@isotopicmaps.org (Mason, James David (MXM))['0019980']['0021450']['0020902']['00491']2004/07/12['00488']['00488']AE32EAF50E954049A0D50AE30327A21805F1D979@exchange10.y12.doe.govDate: Tue, 13 Jul 2004 08:53:47 -0400%0aSubject: %5bsc34wg3%5d New TMRM document posted%0aMessage-ID: %3cAE32EAF50E954049A0D50AE30327A21805F1D979@exchange10.y12.doe.gov%3e%0a%0aSorry. I was behind a few days on the mirror site. It's aligned with the%0aSecretariat site now.%0a%0aJim%0a%0a%3e -----Original Message-----%0a%3e From: sc34wg3-admin@isotopicmaps.org%0a%3e %5bmailto:sc34wg3-admin@isotopicmaps.org%5d On Behalf Of Steve Pepper%0a%3e Sent: Monday, July 12, 2004 4:19 PM%0a%3e To: sc34wg3@isotopicmaps.org%0a%3e Cc: maicher@informatik.uni-leipzig.de%0a%3e Subject: RE: %5bsc34wg3%5d New TMRM document posted%0a%3e%0a%3e%0a%3e Hi Lutz,%0a%3e%0a%3e | I'm interested in this paper but unfortunately it isn't%0a%3e available at%0a%3e | http://www.y12.doe.gov/sgml/sc34/document/0550.htm%0a%3e%0a%3e Since the secretariatet of SC34 moved to Ken Holman and%0a%3e Canada, the definitive repository is now at%0a%3e%0a%3e http://www.jtc1sc34.org/repository/0550.htm%0a%3e%0a%3e Jim Mason's site at Y12 is being maintained as an archive,%0a%3e but (as far as I know) not be updated on a regular basis.%0a%3e%0a%3e Best regards,%0a%3e%0a%3e Steve%0a%3e%0a%3e --%0a%3e Steve Pepper %3cpepper@ontopia.net%3e%0a%3e Chief Strategy Officer, Ontopia%0a%3e Convenor, ISO/IEC JTC 1/SC 34/WG 3%0a%3e Editor, XTM (XML Topic Maps 1.0)%0a%3e%0a%3e _______________________________________________%0a%3e sc34wg3 mailing list%0a%3e sc34wg3@isotopicmaps.org%0a%3e http://www.isotopicmaps.org/mailman/listinfo/sc34wg3%0a%3e%0a%0aFrom: sc34wg3@isotopicmaps.org (Robert Barta)['0020648']['0020902']['00496']2004/07/13['00494']['00494']['0019845']['0019003']20040714101736.GD20764@mandoDate: Wed, 14 Jul 2004 20:17:36 +1000%0aSubject: %5bsc34wg3%5d Re: FYI: Yet another TMRM Formalization (well, not really)%0aIn-Reply-To: %3c20040714092408.GA20764@mando%3e%0aReferences: %3c20040714092408.GA20764@mando%3e%0aMessage-ID: %3c20040714101736.GD20764@mando%3e%0a%0aOn Wed, Jul 14, 2004 at 07:24:08PM +1000, Robert Barta wrote:%0a%3e Hi all,%0a%3e%0a%3e FYI, this is our current working paper here to capture "the essence of%0a%3e TMs".%0a%0aUhm, a link would help here:%0a%0ahttp://astma.it.bond.edu.au/junk/tau-model.pdf%0a%0a\rho%0a%0a%0aFrom: sc34wg3@isotopicmaps.org (Jan Algermissen)['0019845']['0021440']['0021435']['0020489']['00509']['0019087']MDAEMON-F200407141523.AA2309971md50000069680@csw.co.ukDate: Wed, 14 Jul 2004 15:23:33 +0100%0aSubject: %5bsc34wg3%5d Re: FYI: Yet another TMRM Formalization (well, not really)%0aIn-Reply-To: %3c40F52387.B0D6088C@topicmapping.com%3e%0aMessage-ID: %3cMDAEMON-F200407141523.AA2309971md50000069680@csw.co.uk%3e%0a%0aJan said:%0a%0a%0a- Interestingly, what you describe is an *Application* of the RM. You%0adefine (although implicitly) a set of properties and a certain%0aassertion structure (also only a set of properties as in the%0aassertion structire propsed by the RM). In essence, you defnine%0aa TMA (and operations on the properties provided by this TMA).%0a%0aI say:%0a%0aJan, it would help me a lot if you showed exactly how this works. Not all%0athe detail, just enough so I can understand how you made the judgement.%0a%0aAnn W.%0a%0a%0a%0aFrom: sc34wg3@isotopicmaps.org (Jan Algermissen)['0019087']['0021227']['0021435']['0020489']['00520']['0019425']MDAEMON-F200407141603.AA0324596md50000069888@csw.co.ukDate: Wed, 14 Jul 2004 16:03:50 +0100%0aSubject: %5bsc34wg3%5d Re: FYI: Yet another TMRM Formalization (well, not really)%0aIn-Reply-To: %3c40F54AD7.CE4F0B6A@topicmapping.com%3e%0aMessage-ID: %3cMDAEMON-F200407141603.AA0324596md50000069888@csw.co.uk%3e%0a%0aYes it's helpful - thanks.%0a%0aAnn W.%0a%0a-----Original Message-----%0aFrom: sc34wg3-admin@isotopicmaps.org %5bmailto:sc34wg3-admin@isotopicmaps.org%5d%0aOn Behalf Of Jan Algermissen%0aSent: 14 July 2004 16:02%0aTo: sc34wg3@isotopicmaps.org%0aSubject: Re: %5bsc34wg3%5d Re: FYI: Yet another TMRM Formalization (well, not%0areally)%0a%0aAnn Wrightson wrote:%0a%3e%0a%3e Jan said:%0a%3e%0a%3e - Interestingly, what you describe is an *Application* of the RM. You%0a%3e define (although implicitly) a set of properties and a certain%0a%3e assertion structure (also only a set of properties as in the%0a%3e assertion structire propsed by the RM). In essence, you defnine%0a%3e a TMA (and operations on the properties provided by this TMA).%0a%3e%0a%3e I say:%0a%3e%0a%3e Jan, it would help me a lot if you showed exactly how this works. Not%0a%3e all the detail, just enough so I can understand how you made the%0ajudgement.%0a%0a%0aVery briefly (not much time, sorry):%0a%0aThe RM defines an abstract information structure: sets of property/value%0apairs (with typed values). Everything else is semantics and is inside a TMA%0a(or schema) definition (property A means this and that, property B means%0athis and that,...)%0a%0aThe RM itself defines the assertion structure in terms of properties (that%0ais the annex about all the SIDPs and OPs). In fact, the proposed assertion%0astructure is actually a 'core' TMA.%0a%0aRobert also (implicitly) defines roperties when he defines 'members' and how%0athey form assertions. He defines a property called 'Name' (including or%0aexcluding the 'literals', depending on their significance).%0a%0aThe nice thing about all this is that you get correct merging of assertions%0a'for free' since it is completely defined by the properties that form the%0aassertions (A-topics merge if their a-sidp values are equal).%0a%0aDoes that help?%0a%0aJan%0a%0a%0a%0a%0a%3e Ann W.%0a%3e%0a%3e _______________________________________________%0a%3e sc34wg3 mailing list%0a%3e sc34wg3@isotopicmaps.org%0a%3e http://www.isotopicmaps.org/mailman/listinfo/sc34wg3%0a%0a--%0aJan Algermissen http://www.topicmapping.com%0aConsultant %26 Programmer%09 http://www.gooseworks.org%0a_______________________________________________%0asc34wg3 mailing list%0asc34wg3@isotopicmaps.org%0ahttp://www.isotopicmaps.org/mailman/listinfo/sc34wg3%0a%0a%0a%0aFrom: sc34wg3@isotopicmaps.org (Martin Bryan)['0019425']['0021227']['0021435']['0020489']['00531']['0019372']40F5820E.EA36A155@topicmapping.comDate: Wed, 14 Jul 2004 20:57:18 +0200%0aSubject: %5bsc34wg3%5d Re: FYI: Yet another TMRM Formalization (well, not really)%0aReferences: %3c20040714092408.GA20764@mando%3e %3c20040714101736.GD20764@mando%3e %3c021001c469d3$186a92b0$0c01a8c0@MAINFRAME%3e%0aMessage-ID: %3c40F5820E.EA36A155@topicmapping.com%3e%0a%0aMartin Bryan wrote:%0a%3e%0a%3e Robert%0a%3e%0a%3e %3e http://astma.it.bond.edu.au/junk/tau-model.pdf%0a%5b...%5d%0a%3e How can a human specify an expression in the Map Path Language in a format%0a%3e that can be entered at a computer terminal using a standard QWERTY or AZERTY%0a%3e keyboard without invoking special character sets?%0a%0aAs a defense: relational algebra does not look that friendly either when discussed%0ain a book....but SQL does a pretty good job :-)%0a%0aJan%0a%0a%0a%3e Martin Brayn%0a%3e%0a%3e _______________________________________________%0a%3e sc34wg3 mailing list%0a%3e sc34wg3@isotopicmaps.org%0a%3e http://www.isotopicmaps.org/mailman/listinfo/sc34wg3%0a%0a--%0aJan Algermissen http://www.topicmapping.com%0aConsultant %26 Programmer%09 http://www.gooseworks.org%0a%0aFrom: sc34wg3@isotopicmaps.org (Robert Barta)['0021452']['0021435']['0020489']['00542']20040714210017.GA1060@mandoDate: Thu, 15 Jul 2004 07:00:17 +1000%0aSubject: %5bsc34wg3%5d FYI: Yet another TMRM Formalization (well, not really)%0aIn-Reply-To: %3c40F4FD9D.9183EE2E@topicmapping.com%3e%0aReferences: %3c20040714092408.GA20764@mando%3e %3c40F4FD9D.9183EE2E@topicmapping.com%3e%0aMessage-ID: %3c20040714210017.GA1060@mando%3e%0a%0aOn Wed, Jul 14, 2004 at 11:32:13AM +0200, Jan Algermissen wrote:%0a%3e Yep, gotta graph or tree? You gotta have a path language! I have one%0a%3e for the TMRM in my pocket as well, to be published later (once I%0a%3e have implemented it).%0a%0aJan,%0a%0aDont be shy, show it. Or at least let me have a glimpse on it.%0a%0a%3e What I'd like to also see here is OPERATORS! You got any of those? :-)%0a%0aMap operators or path operators?%0a%0aFor maps we restrict ourselves to '+', but, hey I am not modest:%0a%0ahttp://astma.it.bond.edu.au/astma-family.dbk?section=7%0a%0aFor paths I have (except the dreadful sorting) all I need to sustain%0aTMQL.%0a%0a\rho%0a%0aFrom: sc34wg3@isotopicmaps.org (Robert Barta)['0019003']['0021440']['0021435']['0020490']['00547']20040714220047.GB1060@mandoDate: Thu, 15 Jul 2004 08:00:47 +1000%0aSubject: %5bsc34wg3%5d Re: FYI: Yet another TMRM Formalization (well, not really)%0aIn-Reply-To: %3c40F52387.B0D6088C@topicmapping.com%3e%0aReferences: %3c20040714092408.GA20764@mando%3e %3c20040714101736.GD20764@mando%3e %3c40F52387.B0D6088C@topicmapping.com%3e%0aMessage-ID: %3c20040714220047.GB1060@mando%3e%0a%0aOn Wed, Jul 14, 2004 at 02:13:59PM +0200, Jan Algermissen wrote:%0a%3e Robert Barta wrote:%0a%3e %3e%0a%3e %3e On Wed, Jul 14, 2004 at 07:24:08PM +1000, Robert Barta wrote:%0a%3e %3e %3e Hi all,%0a%3e %3e %3e%0a%3e %3e %3e FYI, this is our current working paper here to capture "the essence of%0a%3e %3e %3e TMs".%0a%3e%0a%3e Robert,%0a%3e%0a%3e some comments/questions based on a short read:%0a%3e%0a%3e 1.1:%0a%3e - Do you mean that Tau has two elements, the set of names and the set of literals%0a%3e or that Tau is the union of them?%0a%0a\mathcal{I} is a 'mixed' set yes.%0a%0a%5b BTW this is not a tau, it is a calligraphic I. %5d%0a%0a%3e%0a%3e - Are the predefined identifiers (id, instance, class, superclass subclass)%0a%3e names or literals or a third kind?%0a%0a'Predefined Identifiers' are names. A literal would be a number (42) or%0aa quoted string ("Rumsti").%0a%0a%3e - In assume that all names come from a single namespace, right?%0a%0aFlat, yes.%0a%0a%3e What about the%0a%3e literals? If you use literals for the purpose of identity, all literals%0a%3e must also come from a single namespace, or they must carry around with them%0a%3e an implicit namespace. OTH, you say they don't, they are just numbers or%0a%3e quoted strings. So, how does "grroop" provide identity?%0a%0aLiterals have an identity. "grroop" is the same as "grroop" and%0adifferent from "Rumsti". If I need name spaces, then that would%0aeventually be mapped to a flat set anyway. So why make things%0acomplicated in the beginning?%0a%0a%3e - You say N is a collection, so can the same name be contained in N twice?%0a%0aIt says in the first sentence:%0a%0a"...two sets of objects: names and literals." So the collection N here is a set,%0aso it cant have two copies of the same thing.%0a%0a%3e What are the implications for Tau?%0a%0aNone.%0a%0a%3e - This is pretty close to RDF (single namespace for names (URIs) plus literals)%0a%3e OTH, RDF combines literals with domains to enable them to provide idetity.%0a%0aYes, in previous versions of this we even had one which was actually RDFish.%0a%0a%3e - Why are the names in a special collection they are also just literals, or?%0a%0aThe trick is that members contain a pair %3c r, p %3e. r is a name, p is either%0aa name or a literal. %3c basename, "Jan" %3e would be an example.%0a%0a%3e 1.3:%0a%3e%0a%3e - You write that "we do not want to build in any particular merging rules into%0a%3e our model at this stage,..."%0a%0a%3e You are proposing an assertion model that allows a single role to be played%0a%3e more than once%0a%0aYes.%0a%0a%3e (which is the only difference from the TMRM assertion model)%0a%0aNo.%0a%0a%3e and while this seems fine now%5b1%5d I promise you that the problems will%0a%3e immediately arise when you try to *implement* merging (which requires to%0a%3e detect assertion equality, which is hard to do efficiently in the case of%0a%3e multiple role players%5b2%5d).%0a%0a%3cevil-laughter%3eHar har har%3c/evil-laughter%3e.%0a%0aIn my opinion merging __on a formal basis__ should not be in a model%0awith this abstraction. If I want to merge%0a%0a"two people with the same birthdate and the same name and the%0asame country of origin, but only from middle east countries"%0a%0a%5b that actually happened, the man was arrested in the US %5d%0a%0athen this does belong to a TMCL.%0a%0aThis is NOT about efficient implementation. If I ask you to model the%0anatural numbers, {1, 2, 3, 4, .....} then you would have no idea how%0ato implement them unless you know what the agenda is: finding a%0aparticular prime. The agenda determines your choice for implementation.%0a%0a%3e I suggest to never set merging aside 'for the beginning'. I did this 3 or 4%0a%3e times only to find out my mistakes when I started to implement merging%0a%3e in the end!%0a%0aNegative, captain ;-)%0a%0aI am NOT talking about implementation. In my Perl programs merging is%0aat the core of the engine. Here I am talking about a formal model. I would%0anot hesitate a nanosecond to do merging with a (formalized) TMQL:%0a%0am3 := m1 + m2 # non-merged version%0aRETURN%0aMERGE-OPERATOR (m3, rule_1, rule_2, rule_3)%0a%0aby providing explicitely the rules when to merge.%0a%0aThis is in NO WAY efficient.%0a%0a%3e - I think the issues around merging and values (literals), and how to%0a%3e query for certain values are much more important than the assertion%0a%3e structure. How do you implement: "give me all literals which are%0a%3e numeric and %3e 4487" without a complete scan of all literals?%0a%0aAgain I stress that this is NO IMPLEMENTATION MODEL. It can serve as a%0aREFERENCE for other things.%0a%0aYou cannot implement natural numbers. You cannot write code that%0aincorporates the set of natural numbers. But natural numbers are a%0aVERY useful concept we use every day for reference.%0a%0aThat's how I see the role of a reference model. Not that I take it%0aas it is and write my TM database based on it.%0a%0aBut I can map TMQL (and maybe later TMCL) on it and have a sound%0abasis I can communicate with others like you: "This is what I mean%0aand not what the english prose text may appear to you".%0a%0a%3e If literals are not typed, access paths (indexes) cannot be implemented%0a%3e (besides hasing).%0a%0a"Hashing", I guess.%0a%0a%3e I really urge us not to ignore all the research that has been done in%0a%3e the RDBMS world for decades.%0a%0aShould this mean that you think that TMs should be based on RDBMs%0atheory? Then why do we have a TM paradigm by itself? Why not see this%0aas an interesting data structure where the only challenge is to%0asqueeze this in a set of tables?%0a%0aGood question, here is my view on things:%0a%0aSome "kind of data" is very tabular. Students who have IDs (no names,%0aplease), students enrolled in courses, students enrolled in courses in%0aspecial degrees....%0a%0aSome data is not so tabular. If you have that you can move into%0aOODBMS to give you more flexibility.%0a%0aIf your data has more variation, then you might want to use an%0aXML DB.%0a%0aIf your data has even more variations, then....you would put it%0ainto an RDF or TM DB.%0a%0aWhat is behind all that is a tradeoff between the entropical degree of%0a'structure': In a table the next row has EXACTLY the same structure as%0athe current row. No surprises here (hence 0 entropy).%0a%0aIn OODBMs different objects may be a bit different, but not much.%0a%0aIn XML one %3cchapter%3e may be quite a bit different from the other%0a%3cchapter%3e.%0a%0aAnd in "grey matter" information more surprises may happen.%0a%0aThis is a fundamental trade-off:%0a%0aSpeed vs. Flexibility%0a%0aIf I do not expect any surprises, I can exploit any structural%0ainformation completely. This is why RDBMS are so 'fast'. The higher%0ayou move up in the structure entropy, the more surprises, so there%0aare inherent limits on performance.%0a%0aA XML DB **CANNOT** be as fast as a RDBMS for the same kind of data.%0a%0a%3e - Interestingly, what you describe is an *Application* of the RM.%0a%0aUhm, hopefully not. :-)%0a%0a%3e You define (although implicitly) a set of properties and a certain%0a%3e assertion structure (also only a set of properties as in the%0a%3e assertion structire propsed by the RM). In essence, you defnine a%0a%3e TMA (and operations on the properties provided by this TMA).%0a%0aWe never talk about properties. What is not defined does not exist.%0a'Properties' are completely assimilated by assertions:%0a%0aa1 = { %3c object, xyz-007%3e, %3c basename, "Robert" %3e }%0a%0aa2 = { %3c object, xyz-007%3e, %3c shoesize, 2004 %3e }%0a%0a%3e While you say "with a faint similarity with TMRM", let me%0a%3e clarify that the purpose of the RM is to provide a means to%0a%3e express TMAs (such as yours, or the TMDM) and to enable%0a%3e interoperability between them.%0a%0aI never postulated this purpose, but now that you mention it, ....%0a%0a%3e In fact, the RM enables you%0a%3e to write a mapping TMA between yours and the TMDM.%0a%0aI cannot see this. I know that this was the intention, but the TMRM%0anever had any formalism, language, .... to actually express a TMA. It%0ahad only the framework. As I had mentioned earlier, this is like%0abuilding houses without a roof.%0a%0a%3e Rather simplified you can also put it that way: The RM enables%0a%3e the definition of TM schemas and your paper defines such a%0a%3e schema, just not in RM language (in essence: TMA == Schema).%0a%0aFor this argument I would see the \tau model at the same level as%0aTMRM. It does not predefine any 'application-specific' names and%0aalso not a single rule.%0a%0aMy thinking is that a TMA is nothing else as than a proper TMCL%0astatement. Here I would define%0a%0a- what kinds of things do I have,%0a- how are they structured (properties, ....)%0a- what is my understanding when two things are the same%0a- what app-specific rule must they follow....%0a%0aIf TMCL is based on something which is compatible with the \tau model,%0athen that would cover the TMA relationship you, Patrick and Steve,%0aet.al. envisioned.%0a%0aBut it would have a language and a sound formalism. That's the%0adifference for me. The TMRM, as it stands, is very difficult to digest%0afor outside people (withholding 3rd party comments here).%0a%0a%3e I hope this clarifies matters a bit. If my language sounds too%0a%3e offensive, please take my apologies, I do not mean to sound rude.%0a%3e I maybe just got carried away by the issues.%0a%0aAh, I *always* prefer men with passion and vision over those with%0aoverpolite poker faces. The latter always survive but they ruined%0athe planet.%0a%0a\rho%0a%0aFrom: sc34wg3@isotopicmaps.org (Robert Barta)['0019087']['0021440']['0021435']['0020490']['00553']20040714222216.GC1060@mandoDate: Thu, 15 Jul 2004 08:22:16 +1000%0aSubject: %5bsc34wg3%5d Re: FYI: Yet another TMRM Formalization (well, not really)%0aIn-Reply-To: %3c021001c469d3$186a92b0$0c01a8c0@MAINFRAME%3e%0aReferences: %3c20040714092408.GA20764@mando%3e %3c20040714101736.GD20764@mando%3e %3c021001c469d3$186a92b0$0c01a8c0@MAINFRAME%3e%0aMessage-ID: %3c20040714222216.GC1060@mando%3e%0a%0aOn Wed, Jul 14, 2004 at 07:48:03PM +0100, Martin Bryan wrote:%0a%3e Robert%0a%3e%0a%3e %3e http://astma.it.bond.edu.au/junk/tau-model.pdf%0a%3e%0a%3e How can the Tau model be implemented in a manner that a computer can%0a%3e understand?%0a%0aMartin,%0a%0aCounterquestion: How can the natural numbers be implemented such that%0aa computer can understand?%0a%0aThe \tau model is a formalism, nothing else. It is not meant to%0aimplemented as is, in the same way as relational databases do not%0aimplement tables with the relational algebra.%0a%0aWhat RDBMSes do is to incorporate 'knowledge about the relational%0aalgebra, at least to a certain extend. This is also the intention%0abehind the path language, namely that engines can use it to perform%0aoptimization steps during processing. The model is nothing else as a%0abasis to formulate the rules.%0a%0aWhether we use it to define what TMQL statements actually do (formal%0asemantics), we (Lars and \me) have still to decide.%0a%0a%3e How can a human specify an expression in the Map Path Language in a format%0a%3e that can be entered at a computer terminal using a standard QWERTY or AZERTY%0a%3e keyboard without invoking special character sets?%0a%0aFor example: Retrieve all author names from the map $m (whereever this comes from)%0a%0a($m / is-author-of / author/bn @uc)%0a%0a----^ take the map%0a%0a---------------------^ find all instances of this type (this give all association of this type)%0a%0a-----------------------------^ in these associations find the author role(s)%0a%0a-------------------------------^ get the basenames%0a%0a-----------------------------------^ but only those in the unconstrained scope%0a%0aIf you look at our official%0a%0ahttp://www.isotopicmaps.org/tmql/uc-solutions.html%0a%0athen you will find quite some examples with AsTMa? That one%0auses path expressions.%0a%0a%3e Martin Brayn%0a%0a\roh :-)%0a%0aFrom: sc34wg3@isotopicmaps.org (Patrick Durusau)['0019372']['0021440']['0021435']['0020490']['00559']['0019793']['0018597']['0019132']20040715212910.GA8630@namod.rho.priv.atDate: Fri, 16 Jul 2004 07:29:10 +1000%0aSubject: %5bsc34wg3%5d Re: FYI: Yet another TMRM Formalization (well, not really)%0aIn-Reply-To: %3c02f401c46a86$7d9e3a20$0c01a8c0@MAINFRAME%3e%0aReferences: %3c20040714092408.GA20764@mando%3e %3c20040714101736.GD20764@mando%3e %3c021001c469d3$186a92b0$0c01a8c0@MAINFRAME%3e %3c20040714222216.GC1060@mando%3e %3c02f401c46a86$7d9e3a20$0c01a8c0@MAINFRAME%3e%0aMessage-ID: %3c20040715212910.GA8630@namod.rho.priv.at%3e%0a%0aOn Thu, Jul 15, 2004 at 05:12:13PM +0100, Martin Bryan wrote:%0a%3e %3e Counterquestion: How can the natural numbers be implemented such that%0a%3e %3e a computer can understand?%0a%3e%0a%3e By humans adopting conventions that machines can interpret to%0a%3e determine the relevant values that can be used in binary arithematic%0a%3e to represent the number.%0a%0aMartin,%0a%0aBut there are MANY relevant values in the set of natural numbers.%0aA formal model ...%0a%0a%3e What I want are a set of machine processable identifiers for TM concepts%0a%3e that humans can enter safely by hand.%0a%0a...by itself may not be necessarily transferable into a computer,%0aunless you do it strictly symbolically. And it still has a value, in%0athat you can analyse the structure of your things.%0a%0aThis huge system 'number theory' talks about monstrous numbers and%0atheir properties. This is all symbolic math in the brains, almost no%0amachinery in place.%0a%0aBut all of it together is so strong that crypto technologies (RSA, EC,%0aDSA) are built on in and used in wars. The NSA has alledgedley 1000%0amathematicians employed. They are not doing data entry there....%0a%0a%3e %3e The \tau model is a formalism, nothing else. It is not meant to%0a%3e %3e implemented as is, in the same way as relational databases do not%0a%3e %3e implement tables with the relational algebra.%0a%3e%0a%3e But they do have a computable form.%0a%0aSaying the above, the \tau model also happens to be 'computable' in%0athe sense that it talks about finite sets of terms. An assertion is a%0afinite set and a map is a finite set of assertions.%0a%0aIf Jan would ask me again whether this is an 'implementation', I would%0aanswer, yes, but a slooooooooooow one.%0a%0a%3e %3e What RDBMSes do is to incorporate 'knowledge about the relational%0a%3e %3e algebra, at least to a certain extend. This is also the intention%0a%3e %3e behind the path language, namely that engines can use it to perform%0a%3e %3e optimization steps during processing. The model is nothing else as a%0a%3e %3e basis to formulate the rules.%0a%3e%0a%3e But until you take the next step the model will remain just that = a%0a%3e "theoretical" model which explains all and does f.all.%0a%0a'Just' is not a just characterisation. But this is more a question%0aabout the usefulness of theoretical models in general. Your mobile in%0ayour pocket, your combustion engine in your car, the plan you took%0alast month. Part of it is experiment, but lots only emerged on paper%0afirst.%0a%0a%3e %3e ($m / is-author-of / author/bn @uc)%0a%3e%0a%3e What if I, in my vast ignorance, misenter this as%0a%3e ($x/author/is-author-of/basename ^@unconstrained)%0a%0aThen your query processor will give you a more or less friendly%0afeedback, that%0a%0a(a) the query is not consistent with the map structure%0aif that is known to the processor, or%0a%0a(b) sorry, nothing of this kind can be found%0a%0aIn this sense the query language should behave like those for%0a%0arelational DBs%0aOO DBs%0ahierarchical DBs%0aXML DBs%0ayou-name-it DBs%0a%0aAll I know necessitate the 'programmer' to know something about the%0astructure (some call it schema) of the database. Either the human%0aknows this - and in projects where you NEED the control to guarantee a%0adegree of quality this will be the case - or the development%0ainfrastructure will help you.%0a%0aIn UNIX, for instance, there are many tools where you can use the%0a'TAB' key to get suggestions how to complete a command / xml-tag /%0asentence /...%0a%0a%3e My point is that information in natural languages can be entered in%0a%3e different orders to get the same result.%0a%0aTrue, but TMs is NOT about natural language processing. It is - as I%0aunderstand it - about 'shallow knowledge'. And that HAS a structure,%0aalbeit a weak one.%0a%0a%3e SQL only offers a limited functionality for doing this. By naming%0a%3e each field XML allows you to identify when the wrong information has%0a%3e been entered in the wrong order.%0a%0aXML does not help at all. Look at the snippet%0a%0a%3csomething%3e%0a%3cShoesize%3e123%3c/Shoesize%3e%0a%3cStudentNr%3e234%3c/StudentNr%3e%0a%3c/something%3e%0a%0aThat entity which puts in the information has to know what these%0athings 'mean'. Same for relational DBs, same for TM DBs.%0a%0a%3e At present your model seems to be suggesting I need to be sure that%0a%3e type a is used in map x, that the third part of the path is always%0a%3e an association, the fourth is a TM construct and the fifth is a%0a%3e qualification :-( But is this correct, fixed, inviolate,%0a%3e adequate....?%0a%0aThe *formal* model suggests that there are ALWAYS only assertions%0a(which are equivalent to associations, excluding scoping). So what the%0a'formal programmer' would have to know what roles and what kind of%0aassertions are involved to reach a particular information.%0a%0aIn the 'practical query language' we will use topics and associations%0abecause that is that what the people are familiar with. The *formal*%0amodel can be used to make it clear (more than prose can do) what a query%0aactually should accomplish for a given map.%0a%0aBut also on the practical level the 'programmer' HAS to know what%0atypes, roles, .... are relevant to reach particular information.%0a%0aIf he/she does not, then tools can easily extract this information%0aout of a map without knowing anyhing about it:%0a%0a- what topics are used only as type?%0a- what are only roles?%0a- what are instances%0a- is there a type hierarchy%0a- ....%0a%0aBasic ontology reengineering. Equipped with that knowlege and the%0aproper labeling the programmer can get as much information as he needs%0ato formulate the query.%0a%0a%3e Doubting TM (Thomas/Martin)%0a%0aWell, if you associate TMs with natural language processing, then I%0awould also doubt them.%0a%0a\rho%0a%0aFrom: sc34wg3@isotopicmaps.org (Robert Barta)['0019132']['0021440']['0021435']['0021339']['00580']20040715233327.GB8630@namod.rho.priv.atDate: Fri, 16 Jul 2004 09:33:27 +1000%0aSubject: %5bsc34wg3%5d Re: FYI: Yet another TMRM Formalization (well, not really)%0aIn-Reply-To: %3c40F66FEC.4444215D@topicmapping.com%3e%0aReferences: %3c20040714092408.GA20764@mando%3e %3c20040714101736.GD20764@mando%3e %3c40F52387.B0D6088C@topicmapping.com%3e %3c20040714220047.GB1060@mando%3e %3c40F66FEC.4444215D@topicmapping.com%3e%0aMessage-ID: %3c20040715233327.GB8630@namod.rho.priv.at%3e%0a%0aOn Thu, Jul 15, 2004 at 01:52:12PM +0200, Jan Algermissen wrote:%0a%3e Just to clarify:%0a%3e Your names *provide* identity and the literals *have* identity - yes?%0a%0aI quote:%0a%0a"..objects have no other properties than being distinguishable..."%0a%0aIf this is for you 'identity', then the answer is probably 'yes'.%0a%0a%3e %3e %3e - Why are the names in a special collection they are also just literals, or?%0a%3e %3e%0a%3e %3e The trick is that members contain a pair %3c r, p %3e. r is a name, p is either%0a%3e %3e a name or a literal. %3c basename, "Jan" %3e would be an example.%0a%3e%0a%3e Ok. Again, regarding the id (the identifier for assertions): is the set of ids%0a%3e a subset of N? IOW, do they share the same namespace?%0a%0aThe 'id' member is element of N x I, so the player is an element of I.%0a%0a%3e %3e %3e (which is the only difference from the TMRM assertion model)%0a%3e %3e%0a%3e %3e No.%0a%3e%0a%3e Why 'no'? Can you tell me what is different?%0a%0aYes, but not now. This is either done consistently or not at all. At%0athis stage I have only fragmentary notes on this and a proper answer%0aneeds much more time than I actually have.%0a%0aOn the top-level, there are not HUGE differences in the assertion part%0aitself. Where there are differences are specific constraints on roles%0a(\tau has none, TMRM has the rule that a particular role can only be%0aused in a particular 'kind' of assertion%5b or the roles define the kind%5d).%0a%0aThe big difference is that there is no SIDPs/OPs because there are no%0aproperties.%0a%0a%3e Note that the 'Assertion Type' in the RM is really just the group of%0a%3e roles.%0a%0aYes, this is a very convincing thing to me. Still, we left it out of%0athe model, because there is no need to put this in _at this stage_ and%0aif we want it later, we simply add it then.%0a%0a%3e %3e This is NOT about efficient implementation.%0a%3e%0a%3e Ok, let's put it the other way round: What is it about? What I mean is%0a%3e that any model we develop can only be evaluated against its suitability%0a%3e for the purpose Topic Maps aim to fullfil. There is really no use in%0a%3e providing models that express interpretations of 'Topic Maps'. First%0a%3e we need a clear statement what the purpose of Topic Maps is (what%0a%3e problem do they solve) and then we can discuss what models is suited%0a%3e best. And at this point, implementation efficiency is of critical%0a%3e importance - or are we doing this as a %3cquote%3escientific excercise%3c/quote%3e?%0a%0aJan, I think this is just rubbish. :-))%0a%0aWhatever the 'clear statement of what we want' might be, someone will%0ashoot it down. THIS is a completely academic exercise.%0a%0aTo develop a formal model on which I can base semantically query (or%0aconstraint) languages is no academic exercise.%0a%0a%3e %3e Again I stress that this is NO IMPLEMENTATION MODEL. It can serve as a%0a%3e %3e REFERENCE for other things.%0a%3e%0a%3e For what things?%0a%0aMaybe TMQL, maybe later TMCL.%0a%0a%3e To me (personally!) the role of the reference model is that it provides%0a%3e an abstract, self-contained, logical definition of the objects, operators%0a%3e and so forth that together constitute an abstract machine with which%0a%3e users interact when accessing data.%0a%0aWhat an academic statement. ;-)%0a%0a%3e %3e Should this mean that you think that TMs should be based on RDBMs%0a%3e %3e theory?%0a%3e%0a%3e NO! But I resist the idea of a general datatype 'string'. Why not%0a%3e use the notion of typed literals? What do you think why values in%0a%3e the relational model are typed and not only opaque strings?%0a%0aAs someone who has ported applications between different relational%0adatabase products %5bspit%5d I am not so overly fond of data typing in%0aRDBs.%0a%0a%5b Without making reference to the tau model %5d Strings are so powerful%0aBECAUSE they are opaque. And even if I choose to add 'data types' at%0asome stage, which should I use?%0a%0a%3e %3e This is a fundamental trade-off:%0a%3e %3e%0a%3e %3e Speed vs. Flexibility%0a%3e%0a%3e Ok, so why do we trade the speed for flexibility? (What are%0a%3e Topic Maps for that justifies this trade?)%0a%0aIt is the responsibility of the 'information officer' to figure out%0awhat content is to be covered and what paradigm does it follow.%0aTabular content is relational, objects are ...OO, tree-like data is%0aXMLish, weak-structured is RDFish/TMish, text is ...text.%0a%0aThen someone has to decide about the modalities of access (how to put%0adata in and out) and whether all of the content should be squeezed%0ainto one database (relational, .....) or whether it has to be kept in%0adifferent ones. THIS is where performance considerations kick in.%0a%0aIf you risk a glimpse at%0a%0ahttp://www.idealliance.org/papers/dx_xmle04/slides/barta/foilgrp03.html%0a%0ayou see that sometimes you can eat the cake AND have it.%0a%0a%3e %3e %3e In fact, the RM enables you%0a%3e %3e %3e to write a mapping TMA between yours and the TMDM.%0a%3e %3e%0a%3e %3e I cannot see this. I know that this was the intention, but the TMRM%0a%3e %3e never had any formalism, language, .... to actually express a TMA.%0a%3e%0a%3e Well, it has been left out on purpose. No problem to add it in. My position%0a%3e is that such a syntax depends on the overall technological environment%0a%3e that Topic Maps are deployed in. If we deploy them in an HyTime/XML/Web context,%0a%3e markup is likely to be the syntax of choice, but the RM does not constrain%0a%3e Topic Maps to a particluar technological environment. So why should it%0a%3e include a syntax?%0a%0aYou _precisely_ characterize the problem the current TMRM has manoevered%0aitself in.%0a%0a%3e It%0a%3e %3e had only the framework. As I had mentioned earlier, this is like%0a%3e %3e building houses without a roof.%0a%3e%0a%3e Hmm.. will you proposal include such a mechanism in the end?%0a%0aWe _all_ will have to contribute to TMCL. How far that will get%0adepends on ALL of us.%0a%0a%3e %3e For this argument I would see the \tau model at the same level as%0a%3e %3e TMRM. It does not predefine any 'application-specific' names and%0a%3e %3e also not a single rule.%0a%3e%0a%3e Well, it defines Names and Literals.....note that the RM works without%0a%3e doing so! It is one level of abstraction below.%0a%0aI cannot follow. Names are indistinguishable objects. How more fundamental%0ado you want to be?%0a%0a%3e %3e My thinking is that a TMA is nothing else as than a proper TMCL%0a%3e %3e statement. Here I would define%0a%3e %3e%0a%3e %3e - what kinds of things do I have,%0a%3e%0a%3e Why 'kinds'?%0a%0aI mean things like: "In my topic map I talk about coffee brands, chocolate%0abrands and its exorbitant prices downunder".%0a%0a%3e %3e - what app-specific rule must they follow....%0a%3e%0a%3e ??? what do you mean by app-specific?%0a%0aFor instance "every student who has failed on an exam for a particular%0acourse 3 times, is not allowed to continue the degree". This is not%0astructure, this is not about types. Such constraints can be%0aarbitrarily complex, how much TMCL will want to cover is a complexity%0atrade-off decision.%0a%0aMore 'constraints' you can find at%0a%0ahttp://astma.it.bond.edu.au/project-use-case.dbk%0a%0a%3e %3e If TMCL is based on something which is compatible with the \tau model,%0a%3e %3e then that would cover the TMA relationship you, Patrick and Steve,%0a%3e %3e et.al. envisioned.%0a%3e%0a%3e Do you have any idea how that will look like? Can you sketch what you mean?%0a%0aI think this was done a couple of times already on this list. I do not%0awant to preempt the work the TMCL people do.%0a%0a%3e %3e But it would have a language and a sound formalism. That's the%0a%3e %3e difference for me. The TMRM, as it stands, is very difficult to digest%0a%3e %3e for outside people (withholding 3rd party comments here).%0a%3e%0a%3e Yes, I agree that there needs work to be done on it.%0a%0aI should add that it is not the phrasing or an inappropriate structure%0aof the TMRM document which makes it difficult to digest (and difficult%0ato 'sell' intellectually). I think that you (and Patrick and Steve...)%0atried something which is extremely hard, namely to provide a%0aparametrized identity framework based on properties without actually%0asaying how this is supposed to be done. This makes it hard, hard to%0awrite and hard to read.%0a%0aOnce this is abandoned, you do not need properties at all in the model,%0aand then you maybe end up with something like the tau model :-)%0a%0a%3e Yes. I hope you have the time/energy to continue this argument, it is%0a%3e (at least to me) very revealing.%0a%0aI need another cup of coffee now :-)%0a%0a\rho%0a%0aFrom: sc34wg3@isotopicmaps.org (Patrick Durusau)['0018597']['0021440']['0021435']['0021339']['00586']['0018814']20040716041834.GB31418@mandoDate: Fri, 16 Jul 2004 14:18:34 +1000%0aSubject: %5bsc34wg3%5d Re: FYI: Yet another TMRM Formalization (well, not really)%0aIn-Reply-To: %3c40F65F0C.3000404@sbl-site.org%3e%0aReferences: %3c20040714092408.GA20764@mando%3e %3c20040714101736.GD20764@mando%3e %3c40F52387.B0D6088C@topicmapping.com%3e %3c20040714220047.GB1060@mando%3e %3c40F65F0C.3000404@sbl-site.org%3e%0aMessage-ID: %3c20040716041834.GB31418@mando%3e%0a%0aOn Thu, Jul 15, 2004 at 06:40:12AM -0400, Patrick Durusau wrote:%0a%3e %3eLiterals have an identity. "grroop" is the same as "grroop" and%0a%3e %3edifferent from "Rumsti". If I need name spaces, then that would%0a%3e %3eeventually be mapped to a flat set anyway. So why make things%0a%3e %3ecomplicated in the beginning?%0a%3e%0a%3e Namespaces would be handled in TMCL?%0a%0aPatrick,%0a%0aYes, no. I do not know. :-) If writing a TMCL document means to define%0a_what_ concepts I have and how they are related, then associating with%0athis TMCL statement a namespace would be a rather natural thing to do.%0a%0a%3e If yes, would you see the reference model as requiring namespaces to be%0a%3e specified in TMCL?%0a%0aNo.%0a%0aTo associate a namespace http://coffee.org/1.0/ with a TMCL document could be%0adone with a .... Topic Map. It is metadata (see below).%0a%0a%3e The reason I ask is ascertain where disclosure requirements reside in%0a%3e your proposal? I am assuming that from what you have said, those would%0a%3e be in TMCL, which looks like an unlikely location.%0a%0aIt would not be INSIDE a TMCL statement but would be an association%0abetween a TMCL document and the namespace:%0a%0a# in AsTMa=%0a%0acoffee-ontology is-a ontology%0abn: Coffee (not beer, Lars)%0aoc (namespace): http://coffee.org/1.0/%0a%0a%3e Reasoning that TMCL would give one the ability to impose whatever%0a%3e constraints are thought necessary but would not impose a requirement%0a%3e that particular constraints be expressed.%0a%0aI do not quite understand this sentence.%0a%0a%3e And if TMCL is the mechanism for such constraints, such as requiring%0a%3e namespaces, where is the requirement for namespaces expressed? (I am%0a%3e assuming that namespaces are necessary for the merging of topic maps%0a%3e governed by different TMCL expressed constraints. Or some similar%0a%3e mechanism.)%0a%0aWell, I would not adhoc see any necessity to provide a mechanism INSIDE%0aa TMCL statement to hold a namespace identifier, although adding one is%0anot a problem.%0a%0aI am not sure why you connect the merging of two maps with namespaces.%0aIf you have two maps which follow the SAME TMCL statements, then you%0amerge them simply, whereby the TMCL statements provide the application%0a(which cares, that is) with the information what should be regarded the%0asame or not.%0a%0aIf your two maps DO NOT follow the same TMCL statement, so that the%0amaps are incompatible, then one (or both) maps have to be transformed%0ainto forms which are compatible. Transformations (also virtual ones)%0ayou can do with TMQL.%0a%0aThat way the process is very controlled and controllable.%0a%0a%3e %3eThe trick is that members contain a pair %3c r, p %3e. r is a name, p is either%0a%3e %3ea name or a literal. %3c basename, "Jan" %3e would be an example.%0a%3e%0a%3e Can you say a bit more about the identity of the "p the player of the%0a%3e member?" Is its identity determined by a single identifier or can it be%0a%3e an arbitrary combination of identifiers? (members of your set "I")%0a%0aNo, this is ONE thing, not a set.%0a%0a%3e %3e%3e You are proposing an assertion model that allows a single role to be%0a%3e %3e%3e played%0a%3e %3e%3e more than once%0a%3e %3e%0a%3e %3e%0a%3e %3eYes.%0a%3e %3e%0a%3e%0a%3e Shouldn't your answer be maybe? ;-)%0a%0aMaybe. :-) As I mentioned to Jan already, we did not see the necessity%0ato hard-code this into the formalism. If we need it later (and I like the%0acleanness of the idea), then we can easily add it.%0a%0a%3e %3eI cannot see this. I know that this was the intention, but the TMRM%0a%3e %3enever had any formalism, language, .... to actually express a TMA. It%0a%3e %3ehad only the framework. As I had mentioned earlier, this is like%0a%3e %3ebuilding houses without a roof.%0a%3e %3e%0a%3e%0a%3e Same criticism applies here. You have an imagined future formalism,%0a%3e TMCL. Let's all concede that we need a formalism to express%0a%3e constraints/TMAs and roll on shall we?%0a%0aYup.%0a%0a%3e %3eMy thinking is that a TMA is nothing else as than a proper TMCL%0a%3e %3estatement. Here I would define%0a%3e %3e%0a%3e %3e - what kinds of things do I have,%0a%3e %3e - how are they structured (properties, ....)%0a%3e %3e - what is my understanding when two things are the same%0a%3e %3e - what app-specific rule must they follow....%0a%3e %3e%0a%3e %3eIf TMCL is based on something which is compatible with the \tau model,%0a%3e %3ethen that would cover the TMA relationship you, Patrick and Steve,%0a%3e %3eet.al. envisioned.%0a%3e %3e%0a%3e%0a%3e But at some point the rules for disclosure have to be defined. Reasoning%0a%3e that it is well and good for a TMCL statement to do as you suggest but%0a%3e at some point I need to know what I am required to state. If an external%0a%3e entity is going to be resolved by my SGML parser, there is a specific%0a%3e "disclosure" procedure I must follow in order for that to happen.%0a%0aI had to give up on this as I did not understand the problem/question.%0a%0a%3e %3eBut it would have a language and a sound formalism. That's the%0a%3e %3edifference for me. The TMRM, as it stands, is very difficult to digest%0a%3e %3efor outside people (withholding 3rd party comments here).%0a%3e %3e%0a%3e Did you find the more recent narrative any better?%0a%0aThis is on the top of the pile of my bedtime reading.%0a%0a%3e A couple of extra questions:%0a%3e%0a%3e 1. "literals"%0a%3e%0a%3e You don't say how the pairs of objects and literals arise. I assume that%0a%3e is intentional? (Thinking here of the TMRM's distinction between%0a%3e built-in versus conferred properties.)%0a%0aYes. This is a postulated set.%0a%0a%3e 2. Ordering%0a%3e%0a%3e In 2.1 Tuple Matrixes, second paragraph, you mention:%0a%3e%0a%3e "This covers another, important requirement for the language, namely%0a%3e that the results should be deliverable in a particular order."%0a%3e%0a%3e I am not claiming to have worked through the entire paper with paper and%0a%3e pencil but so far I don't see the rationale for that. Oh, is that to be%0a%3e covered in .6 Ordering? That is to say, not proceeding from ordering but%0a%3e a justification for ordering?%0a%0aYes, this is yet to be done. The background is that for practical%0aquerying a map you definitely WANT to have some control over the%0aresult order. At this stage I am not sure whether this should be in%0athe formalism or only in TMQL. So I left it out.%0a%0a%3e 3. Identity%0a%3e%0a%3e So, I take it that the \tau model does not constrain, although a TMCL%0a%3e statement might, a topic map from defining the identity of a topic from%0a%3e consisting of more or less than is expressed in the TMDM?%0a%0aA topic map cannot define any identity by itself (unless we use%0atrivially subject identifiers there). It is the ontology definition%0a(with TMCL or whatever) which introduces an identity concept *FOR A%0aPARTICULAR* application.%0a%0a%3e General comments:%0a%3e%0a%3e Despite your claims to "now for something completely different," I%0a%3e really don't see much that is inconsistent with my understanding of most%0a%3e of the TMRM.%0a%0aIn the announcement%0a%0ahttp://www.isotopicmaps.org/pipermail/sc34wg3/2004-July/002326.html%0a%0aI explicitely say that it is "quite TMRMish" but....%0a%0a%3e Expressed quite differently and some difference on%0a%3e emphasis, and you don't cover disclosure except implicitly, etc, but the%0a%3e basic concepts are quite close.%0a%0a...that are still major differences, yes.%0a%0a\rho%0a%0a%0aFrom: sc34wg3@isotopicmaps.org (Robert Barta)['0019793']['0021440']['0021435']['0021339']['00597']20040716072755.GF31418@mandoDate: Fri, 16 Jul 2004 17:27:55 +1000%0aSubject: %5bsc34wg3%5d Look Ma! No Properties!%0aIn-Reply-To: %3c40F71C6B.9020106@sbl-site.org%3e%0aReferences: %3c40F71C6B.9020106@sbl-site.org%3e%0aMessage-ID: %3c20040716072755.GF31418@mando%3e%0a%0aOn Thu, Jul 15, 2004 at 08:08:11PM -0400, Patrick Durusau wrote:%0a%0a%3e Ok, the \tau model has no properties.%0a%0aThe \tau model is based on assertions only. Properties are seen as%0aonly a special form of an assertion, yes.%0a%0a%3e I am assuming that even though you don't have properties in the \tau,%0a%3e you are not saying that at some less abstract level you would not have%0a%3e properties? Or are you?%0a%0aIt is perfectly possible, reasonable and to be expected that higher%0aabstractions define properties. In fact, in TMQL we will have to do%0athat for 'basenames, occurrences,...' just to be compatible with the%0aworld of TMDM.%0a%0aJust to make an example to avoid a too abstract discussion: Lets%0aassume we model students with their names, their shoesize and their%0astudent ID (SID). In the 'assembler-like' tau model we would only have%0aassertions:%0a%0a{ %3c name-haver: jack-learner %3e, %3c name : "Jack Learner" %3e },%0a{ %3c shoesize-haver: jack-learner %3e, %3c shoesize : 1234 %3e }%0a{ %3c sid-haver: jack-learner %3e, %3c SID : 12345678 %3e }%0a%0aOn a higher level a language (TMCL or whatever) might define (I am%0aparaphrasing AsTMa! in the absence of a better alternative):%0a%0aforall %5b $s is-a student %5d%0a=%3e exists %5b $s%0aname : *%0ashoesize : /\d+/%0aSID : /\d{8}/ %5d%0a%0a%5b Omitting some technicalities like name mapping and multi-valuedness. %5d%0a%0aThis will signal to a generalized TM processor (so not one which%0a'only' understands TMDMish things) that there are new properties%0a'name', 'shoesize' and 'SID' only applicable for things which are%0adirect or indirect instances of 'student'.%0a%0aRemarks on types above:%0a%0aAs we are ignorant on types (yet), I am simply using syntactic%0ameasures (in this case regular expressions like /\d+/ and /\d{8}/) to%0acharacterize what I want. That is good enough for many things, but%0aother people might need real data types.%0a%0aRemarks on identity:%0a%0aIf I would further indicate that the "SID property" is inducing%0aequivalences and that should trigger merging, then I would say%0asomething like%0a%0aforall %5b $s1%0aSID: $sid1 %5d%0a=%3e not exists %5b $s2%0aSID: $sid1 %5d%0a%0aThe machinery would conclude - trivially - that it is the SID property%0aalone that signals an identity.%0a%0aIf - for some weird reason - the shoesize and the first letter in the%0aname are involved, then we would write (brrrrr):%0a%0aforall %5b $s1%0aname : $name1%0ashoesize : $shoesize1%0aSID : $sid1 %5d%0a=%3e not exists %5b $s2%0aname : $name2 =~ /^$name1%5b0:1%5d/%0ashoesize : $shoesize1%0aSID : $sid1 %5d%0a%0aSo the SID AND the shoesize and the first letters have to be different%0aand - together - induce identity.%0a%0aMany more bizarre concepts of 'identity' are possible.%0a%0a%3e What is puzzling to a degree, assuming you have the time to address the%0a%3e first issue, is where are topics/subjects, etc.%0a%0aThe \tau model does not mention topics (= subject proxies in your%0adiction) because these collapse into identifiers. These identifiers%0aare involved in assertions.%0a%0aDoes this make things clearer?%0a%0a\rho%0a%0aFrom: sc34wg3@isotopicmaps.org (Jan Algermissen)['0018814']['0021440']['0021405']['0021339']['00603']['0019005']['0018895']['0019160']['0019528']['0018731']['0018630']20040716102539.GG31418@mandoDate: Fri, 16 Jul 2004 20:25:39 +1000%0aSubject: %5bsc34wg3%5d Re: FYI: Yet another TMRM Formalization (well, not really)%0aIn-Reply-To: %3c40F7884A.3A277F45@topicmapping.com%3e%0aReferences: %3c20040714092408.GA20764@mando%3e %3c20040714101736.GD20764@mando%3e %3c40F52387.B0D6088C@topicmapping.com%3e %3c20040714220047.GB1060@mando%3e %3c40F66FEC.4444215D@topicmapping.com%3e %3c20040715233327.GB8630@namod.rho.priv.at%3e %3c40F7884A.3A277F45@topicmapping.com%3e%0aMessage-ID: %3c20040716102539.GG31418@mando%3e%0a%0aOn Fri, Jul 16, 2004 at 09:48:26AM +0200, Jan Algermissen wrote:%0a%3e Robert Barta wrote:%0a%3e%0a%3e %3e %3e Ok. Again, regarding the id (the identifier for assertions): is the set of ids%0a%3e %3e %3e a subset of N? IOW, do they share the same namespace?%0a%3e %3e%0a%3e %3e The 'id' member is element of N x I, so the player is an element of I.%0a%3e%0a%3e Sorry, my question was wrong. I meant if the preefined identifiers are%0a%3e elements of N or of the set of Literals?%0a%0aJan,%0a%0aHmm, 'predefined identifiers' are .... identifiers. Since they are no%0aliteral (do not start with a number and are not quoted) they must be%0afrom N.%0a%0a%3e I'll rephrase my question: What do Topic Maps (aim to) achieve for%0a%3e data owners that cannot be done with technology/paradigms that already%0a%3e exist?%0a%0aAgain, I think that different content should be hosted in different%0akinds of databases. This, because we DEFINITELY want to use the speed%0aof relational databases (I mean, how old are they now? 40 years?), but%0aI also want to be able to host quite variable content. And for this%0avariable content I think the TMs (and RDF) paradigm can help.%0a%0a%3e As an aside: I must confess, that I (personally) currently cannot%0a%3e justify why the current RM's assertion model should be like it%0a%3e is. It could well be different (like the one of the older PMTM4)%0a%3e without any impact. I just do not know yet. But to have something%0a%3e in a proposal/draft/standard that is not derived from principles%0a%3e (from a mission statement if you want) is a very uncomfortable%0a%3e situation.%0a%0aI feel quite comfortable with the assertion model. It is a highly%0a'relativistic' model in that it concentrates only on the relationships%0aand it completely ignores the objects themselves. I find this very%0agood, I never trusted objects.%0a%0a%3e %3e %3e To me (personally!) the role of the reference model is that it provides%0a%3e %3e %3e an abstract, self-contained, logical definition of the objects, operators%0a%3e %3e %3e and so forth that together constitute an abstract machine with which%0a%3e %3e %3e users interact when accessing data.%0a%3e %3e%0a%3e %3e What an academic statement. ;-)%0a%3e%0a%3e Yes :-) It's of course a quote. OTH, I wanted to hear what you think%0a%3e about Topic Maps fullfilling this role.%0a%0aGiven enough alcohol I would even subscribe to that statement.%0a%0a%3e %3e %5b Without making reference to the tau model %5d Strings are so powerful%0a%3e %3e BECAUSE they are opaque. And even if I choose to add 'data types' at%0a%3e %3e some stage, which should I use?%0a%3e%0a%3e Ok, there you have a portion of the answer to my overall question. You say%0a%3e here (implicitly) that doing application integration accross RDBs is%0a%3e a pain, because the data types do not integrate well. Opaque strings%0a%3e will help.%0a%0aI did not claim that strings help with integrating application integration.%0aI would never subscribe to that, regardless the amount of alcohol.%0a%0a%3e What do you think (as a simple example) about this:%0a%3e "The tau model aims to enable easier data integration accross RDBs and%0a%3e therefore uses opque strings to represent values."%0a%0aHmmm, maybe, maybe not.%0a%0a%3e Based on such statements, we'd have a basis to evaluate the decision%0a%3e to use opaque strings (which might in fact be good). But we need the%0a%3e statement of what is being tried to solve in order to reason about%0a%3e design decisions.%0a%0aAgain, my claim is that there is a class of content which is NOT%0arelational in structure and which is NOT tree-like in structure, but%0agraph-like. For the latter TMs can play a role.%0a%0a\rho%0a%0aFrom: sc34wg3@isotopicmaps.org (Robert Barta)['0019005']['0021440']['0021435']['0021339']['00639']20040716103315.GI31418@mandoDate: Fri, 16 Jul 2004 20:33:15 +1000%0aSubject: %5bsc34wg3%5d Look Ma! No Properties!%0aIn-Reply-To: %3c40F78F7A.C6DAB36@topicmapping.com%3e%0aReferences: %3c40F71C6B.9020106@sbl-site.org%3e %3c20040716072755.GF31418@mando%3e %3c40F78E28.9C976CD1@topicmapping.com%3e %3c40F78F7A.C6DAB36@topicmapping.com%3e%0aMessage-ID: %3c20040716103315.GI31418@mando%3e%0a%0aOn Fri, Jul 16, 2004 at 10:19:06AM +0200, Jan Algermissen wrote:%0a%3e Alright, my fault. I should have read on:%0a%3e%0a%3e %3e As we are ignorant on types (yet), I am simply using syntactic%0a%3e %3e measures (in this case regular expressions like /\d+/ and /\d{8}/) to%0a%3e %3e characterize what I want. That is good enough for many things, but%0a%3e %3e other people might need real data types.%0a%3e%0a%3e Anyhow, adding in the data types really would not affect the tau model%0a%3e in general, it would just add more subsets to I.%0a%0aTo the literals there, yes.%0a%0a\rho%0a%0aFrom: sc34wg3@isotopicmaps.org (Robert Barta)['0019160']['0021440']['0021405']['0021339']['00645']20040716103238.GH31418@mandoDate: Fri, 16 Jul 2004 20:32:38 +1000%0aSubject: %5bsc34wg3%5d Look Ma! No Properties!%0aIn-Reply-To: %3c40F78E28.9C976CD1@topicmapping.com%3e%0aReferences: %3c40F71C6B.9020106@sbl-site.org%3e %3c20040716072755.GF31418@mando%3e %3c40F78E28.9C976CD1@topicmapping.com%3e%0aMessage-ID: %3c20040716103238.GH31418@mando%3e%0a%0aOn Fri, Jul 16, 2004 at 10:13:28AM +0200, Jan Algermissen wrote:%0a%3e Robert Barta wrote:%0a%3e%0a%3e %3e forall %5b $s is-a student %5d%0a%3e %3e =%3e exists %5b $s%0a%3e %3e name : *%0a%3e %3e shoesize : /\d+/%0a%3e %3e SID : /\d{8}/ %5d%0a%3e%0a%3e Could I also have:%0a%3e%0a%3e forall %5b $s is-a student %5d%0a%3e =%3e exists %5b $s%0a%3e name : *%0a%3e shoesize : %3e 9 %3c---------------------- '%3e' instead of regex!%0a%3e SID : /\d{8}/ %5d%0a%3e%0a%3e IOW, can I 'late bind' the semantics of Integer to the opaque%0a%3e strings and apply the (numerical) '%3e' operator? Or am I%0a%3e doomed to doing the full scan, applying a regex on each literal%0a%3e in turn?%0a%0aJan,%0a%0aAs it stands I have not introduced any of the usual suspects as types%0ainto this language. Simply because I never needed it before. OWL is%0ausing XSD Data Types which would be an obvious choice.%0a%0aBut, yes, once this is incorporated, you could write something like%0athis:%0a%0aforall %5b $s is-a student %5d%0a=%3e exists %5b $s%0aname : *%0ashoesize : $shoesize: xsd:positiveInteger %26%26 $shoesize %3e 9%0aSID : /\d{8}/ %5d%0a%0aEverything to the right of the : is just a predicate which is eval'ed%0ain the light of the current value. Not really rocket-science.%0a%0a\rho%0a%0aFrom: sc34wg3@isotopicmaps.org (Patrick Durusau)['0018895']['0021440']['0021405']['0021339']['00651']['0018849']20040716110043.GJ31418@mandoDate: Fri, 16 Jul 2004 21:00:43 +1000%0aSubject: %5bsc34wg3%5d Look Ma! No Properties!%0aIn-Reply-To: %3c40F798A4.52D1D535@topicmapping.com%3e%0aReferences: %3c40F71C6B.9020106@sbl-site.org%3e %3c20040716072755.GF31418@mando%3e %3c40F798A4.52D1D535@topicmapping.com%3e%0aMessage-ID: %3c20040716110043.GJ31418@mando%3e%0a%0aOn Fri, Jul 16, 2004 at 10:58:12AM +0200, Jan Algermissen wrote:%0a%3e Robert Barta wrote:%0a%3e %3e%0a%3e %3e On Thu, Jul 15, 2004 at 08:08:11PM -0400, Patrick Durusau wrote:%0a%3e %3e%0a%3e %3e %3e Ok, the \tau model has no properties.%0a%3e %3e%0a%3e %3e The \tau model is based on assertions only. Properties are seen as%0a%3e %3e only a special form of an assertion, yes.%0a%3e%0a%3e Ok, I am beginning to see what you want.%0a%0a/me dancing on the table!%0a%0a%3e An instance of student is something that appears as p in an (instance,p)%0a%3e member, yes?%0a%0aThe name of it, yes.%0a%0a%3e %3e Remarks on identity:%0a%3e %3e%0a%3e %3e If I would further indicate that the "SID property" is inducing%0a%3e %3e equivalences and that should trigger merging, then I would say%0a%3e %3e something like%0a%3e %3e%0a%3e %3e forall %5b $s1%0a%3e %3e SID: $sid1 %5d%0a%3e %3e =%3e not exists %5b $s2%0a%3e %3e SID: $sid1 %5d%0a%3e%0a%3e Wow....you are the first person I see to come up with a purely declarative%0a%3e merging rule, which is (warning: implementation issue ahead :o) extremely%0a%3e important in order to get efficient merging. To make it possible at all.%0a%0aWhat the above only indicates to the machinery is that there cannot be%0atwo things in a map with the same SID. If I were asked to implement this%0athen it is similar to what people do in the SQL world:%0a%0acreate table (%0abla bla,%0aSID varchar(101), # argh%0aKEY id (SID) %3c---- this is a 'uniqueness constraint in disguise%0a);%0a%0a%0a%3e At least if you want to have 100%25 generic merging rules. (Note:%0a%3e IMHO, a merging rule is simply a constraint. In the case of tau, it%0a%3e is a constraint on the set of all members.%0a%0aI think there are two aspects:%0a%0a(a) when to trigger merging, and%0a(b) actually perform the merging%0a%0a(a) can be controlled by having statements like the above, the merging%0a(b) itself can be always the same, or I could even imagine that an%0aapplication DEFINES EXACTLY how it wants things to be merged. This%0acould be handled by TMQL, btw.%0a%0a%3e What I do not understand in the above is what $s1 iterates over?%0a%3e Is it I? Is it the set of all members?%0a%0aThere is no 'I', that is a square bracket.%0a%0a$s1 is iterating over 'every thing' in the map. If I do not want that%0aand I only want to have this rule applied to 'students' then I relax%0ait a bit:%0a%0aforall %5b $s1 is-a student%0aSID: $sid1 %5d%0a=%3e not exists %5b $s2 is-a student%0aSID: $sid1 %5d%0a%0a%3e %3e The machinery would conclude - trivially - that it is the SID property%0a%3e %3e alone that signals an identity.%0a%3e%0a%3e You say 'SID property'....that is actually the SID role, yes?%0a%0aOn the high-level it is a 'property', on the TMRM 'assembler level' SID%0ais a role, yes.%0a%0a......%0a%3e %3e So the SID AND the shoesize and the first letters have to be different%0a%3e %3e and - together - induce identity.%0a%3e %3e%0a%3e %3e Many more bizarre concepts of 'identity' are possible.%0a%3e%0a%3e Well, the cool thing is that you can load them into an engine in the%0a%3e form of *constraints* on literals that play certain roles, that you%0a%3e can really implement such an engine and (biggest +) that you can%0a%3e *communicate* the constraint to others.%0a%0aEXACTLY.%0a%0a%3e This is, BTW, conceptually not different from the schema definition part%0a%3e of SQL. Define a schema and load it into your engine. Then load the data.%0a%0aEXACTLY.%0a%0a%3e I wonder if merging will cause a form of multivaluedness that will%0a%3e cause problems, because you would need to hide it in opaque literals?!?!%0a%0aAt the low level this should not be a problem, as members remain in%0aexactly the same way after merging. It is a set, so only completely%0aidentical pairings are 'thrown out'.%0a%0a%3e I might give it a try and do some prototype implementation for tau%0a%3e for evaluation purposes. I am having this itch that there are%0a%3e problems induced by merging (which you exclude for now :o) and/or%0a%3e having assertions as role players....%0a%0aPlease do that, although \tau is not really meant to be implemented 1:1.%0a%0a%3e but besides that, I am quite impressed.%0a%0aI have printed out this mail :-)%0a%0a\rho%0a%0aFrom: sc34wg3@isotopicmaps.org (Robert Barta)['0019528']['0021440']['0021405']['0021339']['00662']20040716110201.GK31418@mandoDate: Fri, 16 Jul 2004 21:02:01 +1000%0aSubject: %5bsc34wg3%5d Look Ma! No Properties!%0aIn-Reply-To: %3c40F79D6C.FAC64ED5@topicmapping.com%3e%0aReferences: %3c40F71C6B.9020106@sbl-site.org%3e %3c20040716072755.GF31418@mando%3e %3c40F79D6C.FAC64ED5@topicmapping.com%3e%0aMessage-ID: %3c20040716110201.GK31418@mando%3e%0a%0aOn Fri, Jul 16, 2004 at 11:18:36AM +0200, Jan Algermissen wrote:%0a%3e A question: can a member be an element in several assertions or only in one?%0a%0aA member is a tuple %3cr, p%3e. Nothing can stop it to appear several%0atimes somewhere. Members themselves have no identity. Assertions can%0ahave one.%0a%0a\rho%0a%0aFrom: sc34wg3@isotopicmaps.org (Jan Algermissen)['0018731']['0021440']['0021405']['0021339']['00668']['0019439']FOEHKIENIPCJNPNFKGJNMEBEONAA.pepper@ontopia.netDate: Fri, 16 Jul 2004 13:30:46 +0200%0aSubject: %5bsc34wg3%5d Look Ma! No Properties!%0aIn-Reply-To: %3c40F798A4.52D1D535@topicmapping.com%3e%0aMessage-ID: %3cFOEHKIENIPCJNPNFKGJNMEBEONAA.pepper@ontopia.net%3e%0a%0a* Jan Algermissen:%0a%0a| Wow....you are the first person I see to come up with a purely declarative%0a| merging rule, which is (warning: implementation issue ahead :o) extremely%0a| important in order to get efficient merging. To make it possible at all.%0a| At least if you want to have 100%25 generic merging rules.%0a| (Note: IMHO, a merging rule is simply a constraint. In the case of tau, it%0a| is a constraint on the set of all members.%0a%0aI'm curious to know why the examples Lars Marius and I gave%0ain http://www.jtc1sc34.org/repository/0497.htm don't qualify%0aas "purely declarative merging rules". Is it simply because%0ayou didn't see that document, or have I missed something?%0a%0aSteve%0a%0a%0aFrom: sc34wg3@isotopicmaps.org (Jan Algermissen)['0019528']['0021450']['0021405']['0021339']['00679']['0019852']FOEHKIENIPCJNPNFKGJNMECPONAA.pepper@ontopia.netDate: Fri, 16 Jul 2004 15:48:55 +0200%0aSubject: %5bsc34wg3%5d Look Ma! No Properties!%0aIn-Reply-To: %3c40F7D87E.EDA74B0F@topicmapping.com%3e%0aMessage-ID: %3cFOEHKIENIPCJNPNFKGJNMECPONAA.pepper@ontopia.net%3e%0a%0a* Jan Algermissen:%0a%0a| %3e I'm curious to know why the examples Lars Marius and I gave%0a| %3e in http://www.jtc1sc34.org/repository/0497.htm don't qualify%0a| %3e as "purely declarative merging rules".%0a|%0a| I can't see one that does not involve procedural aspects (but%0a| you might want to point me to one that I missed).%0a%0aThe queries in UC1, UC2 and UC5 are intended to *declare* merging%0arules. Any merging that occurs as a result is surely procedural%0aby definition, however it is implemented?%0a%0a| Maybe our understanding of 'declarativeness' differs, though.%0a%0aHmm. Maybe. I guess it must, if you still don't think our%0aquery examples can be used declaratively.%0a%0a| It is more precise to say that Robert's 'merging rules' are%0a| constraints on the topic map and that I have not seen *this*%0a| before.%0a%0aThe thinking behind the examples we gave would be that they,%0atoo, would be constraints on the topic map, expressed as%0aqueries, using TMCL.%0a%0a| Ok?%0a%0aYes, if you now agree that our merging rule examples also can%0abe viewed as constraints on the topic map! (In that case, we%0aobviously did not explain our intent clearly enough in N497.)%0a%0aNot OK if you don't agree :-)%0a%0aSteve%0a%0a%0aFrom: sc34wg3@isotopicmaps.org (Robert Barta)['0019852']['0021450']['0021405']['0021339']['00690']20040716225208.GA4283@mandoDate: Sat, 17 Jul 2004 08:52:08 +1000%0aSubject: %5bsc34wg3%5d Look Ma! No Properties!%0aIn-Reply-To: %3c40F7D87E.EDA74B0F@topicmapping.com%3e%0aReferences: %3cFOEHKIENIPCJNPNFKGJNMEBEONAA.pepper@ontopia.net%3e %3c40F7D87E.EDA74B0F@topicmapping.com%3e%0aMessage-ID: %3c20040716225208.GA4283@mando%3e%0a%0aOn Fri, Jul 16, 2004 at 03:30:38PM +0200, Jan Algermissen wrote:%0a%3e Steve Pepper wrote:%0a%3e %3e%0a%3e %3e * Jan Algermissen:%0a%3e %3e%0a%3e %3e | Wow....you are the first person I see to come up with a purely declarative%0a%3e %3e | merging rule, which is (warning: implementation issue ahead :o) extremely%0a%3e %3e | important in order to get efficient merging. To make it possible at all.%0a%3e %3e | At least if you want to have 100%25 generic merging rules.%0a%3e %3e | (Note: IMHO, a merging rule is simply a constraint. In the case of tau, it%0a%3e %3e | is a constraint on the set of all members.%0a%3e %3e%0a%3e %3e I'm curious to know why the examples Lars Marius and I gave%0a%3e %3e in http://www.jtc1sc34.org/repository/0497.htm don't qualify%0a%3e %3e as "purely declarative merging rules".%0a%3e%0a%3e I can't see one that does not involve procedural aspects (but%0a%3e you might want to point me to one that I missed).%0a%3e%0a%3e Maybe our understanding of 'declarativeness' differs, though.%0a%3e%0a%3e It is more precise to say that Robert's 'merging rules' are%0a%3e constraints on the topic map and that I have not seen *this*%0a%3e before.%0a%0aSteve,%0a%0aI see it that way that 'merging' is an operation that is (a) triggered%0aon two or more vortices (uhm topics) and (b) does something with them.%0a%0aThe tolog code%0a%0abasename($T, $BN) :-%0atopic-name($T, $N),%0avalue($N, $BN).%0a%0aselect $T1, $T2 from%0abasename($T1, $BN),%0agabx($T1, $X),%0agaby($T1, $Y),%0abasename($T2, $BN),%0agabx($T2, $X),%0agaby($T2, $Y),%0a$T1 /= $T2?%0a%0atakes care about (a), but not of (b). (b) is covered by the generic%0amerging rules defined in TMDM.%0a%0aBUT: Does this makes sense in all circumstances? In the example of the%0acities which should merge if their are _sufficiently close_, for%0ainstance, generic merging would add up all characteristics of $T1 and%0a$T2 and would drop them into a new topic. Does this now mean that that%0anew topic has a whole lot of new coordinates so that we end up with%0amore than one latitude and more than one longitude?%0a%0aHow can an application actually control it? In the above case what we%0awant is to merge freely the names, that is ok. What we also want is%0athat the longitute/latitude coordinates are combined 'properly',%0awhatever this means for our application.%0a%0aTMQL to the rescue:%0a%0ahttp://topicmaps.it.bond.edu.au/docs/23/toc%0a%0aIf all pans out well, TMQL can generate maps, i.e. generate topics and%0aassociations from existing ones. Exactly what we need to cover%0aapplication cases which are not happy with the generic 'drop%0aeverything in this basket' merging.%0a%0aNeedless to say, that generic merging is MUCH faster as it can be%0ahard-coded in TM processors.%0a%0a\rho%0a%0a%0a%0a%0a%0a%0a%0a%0a%0a%3e%0a%3e Ok?%0a%3e%0a%3e Jan%0a%3e%0a%3e%0a%3e%0a%3e%0a%3e Is it simply because%0a%3e %3e you didn't see that document, or have I missed something?%0a%3e %3e%0a%3e %3e Steve%0a%3e%0a%3e --%0a%3e Jan Algermissen http://www.topicmapping.com%0a%3e Consultant %26 Programmer%09 http://www.gooseworks.org%0a%3e _______________________________________________%0a%3e sc34wg3 mailing list%0a%3e sc34wg3@isotopicmaps.org%0a%3e http://www.isotopicmaps.org/mailman/listinfo/sc34wg3%0a%3e%0a%0aFrom: sc34wg3@isotopicmaps.org (Robert Barta)['0019852']['0021440']['0021405']['0020494']['00696']20040716225615.GB4283@mandoDate: Sat, 17 Jul 2004 08:56:15 +1000%0aSubject: %5bsc34wg3%5d Look Ma! No Properties!%0aIn-Reply-To: %3c40F7BA84.54340013@topicmapping.com%3e%0aReferences: %3c40F71C6B.9020106@sbl-site.org%3e %3c20040716072755.GF31418@mando%3e %3c40F798A4.52D1D535@topicmapping.com%3e %3c20040716110043.GJ31418@mando%3e %3c40F7BA84.54340013@topicmapping.com%3e%0aMessage-ID: %3c20040716225615.GB4283@mando%3e%0a%0aOn Fri, Jul 16, 2004 at 01:22:44PM +0200, Jan Algermissen wrote:%0a%3e Robert Barta wrote:%0a%3e%0a%3e %3e although \tau is not really meant to be implemented 1:1.%0a%3e%0a%3e Yes, surely not..."it is the abstract machine..." :-)%0a%3e%0a%3e OTH, 1:1 implementations are very revealing and educating.%0a%0aVery true. My claim is also that if you implement this path language%0athat you have a fully functional query language for TMs. Not with all%0athe bells and whistles, of course, and difficult to digest for SQL%0aprogrammers, but you should be able to reach all results we had%0adefined in the use case document.%0a%0a\rho%0a%0aFrom: sc34wg3@isotopicmaps.org (Robert Barta)['0019439']['0021440']['0021405']['0020494']['00702']20040716230206.GC4283@mandoDate: Sat, 17 Jul 2004 09:02:06 +1000%0aSubject: %5bsc34wg3%5d Look Ma! No Properties!%0aIn-Reply-To: %3c40F7AC7C.F47B21E2@topicmapping.com%3e%0aReferences: %3c40F71C6B.9020106@sbl-site.org%3e %3c20040716072755.GF31418@mando%3e %3c40F7AC7C.F47B21E2@topicmapping.com%3e%0aMessage-ID: %3c20040716230206.GC4283@mando%3e%0a%0aOn Fri, Jul 16, 2004 at 12:22:52PM +0200, Jan Algermissen wrote:%0a%3e Question on 2.1:%0a%3e I assume that the assertions in the tuples (a1,a2,...an) all have the%0a%3e same set of roles, yes? If not, how would the projection operator work?%0a%0aThe projection simply picks a particular assertion out of a tuple. It%0ais basically what the SELECT clause in SQL does:%0a%0aSELECT name%0aFROM table%0a%0a%3e I am missing how you determine that two assertions have the same set%0a%3e of roles?%0a%0aThe individual assertions in %3c a_1, a_2, ...., a_n %3e can be completely%0adifferent, and they will be usually. So there is no need that they%0ahave 'the same form', i.e. share the exact same set of roles.%0a%0a\rho%0a%0aFrom: sc34wg3@isotopicmaps.org (Robert Barta)['0018630']['0021440']['0021405']['0020494']['00708']20040717005121.GD4283@mandoDate: Sat, 17 Jul 2004 10:51:21 +1000%0aSubject: %5bsc34wg3%5d Re: FYI: Yet another TMRM Formalization (well, not really)%0aIn-Reply-To: %3c40F7AECB.80101@sbl-site.org%3e%0aReferences: %3c20040714092408.GA20764@mando%3e %3c20040714101736.GD20764@mando%3e %3c40F52387.B0D6088C@topicmapping.com%3e %3c20040714220047.GB1060@mando%3e %3c40F65F0C.3000404@sbl-site.org%3e %3c20040716041834.GB31418@mando%3e %3c40F7AECB.80101@sbl-site.org%3e%0aMessage-ID: %3c20040717005121.GD4283@mando%3e%0a%0aOn Fri, Jul 16, 2004 at 06:32:43AM -0400, Patrick Durusau wrote:%0a%3e %3e%3eReasoning that TMCL would give one the ability to impose whatever%0a%3e %3e%3econstraints are thought necessary but would not impose a requirement%0a%3e %3e%3ethat particular constraints be expressed.%0a%3e %3e%0a%3e %3eI do not quite understand this sentence.%0a%3e %3e%0a%3e What I was trying to say, perhaps in a clumsy fashion, was that in order%0a%3e to have disclosure, we have to say what must be disclosed.%0a%0aPatrick,%0a%0aThe way I think this may work is:%0a%0a- There is topic map data. We do not care, where it is coming from,%0acould be manually written, could come directly out of a RDB.%0aThe only requirement is that it is in assertion-form or is simulated%0aby software to be in that form.%0a%0a- There is an ontological description of that data in some TMCL. That%0aincludes type hierarchies and other constraints on the structure. That%0aalso includes information _when_ particular things are supposed to be%0aseen 'identified', so that they are supposed to be mergeable.%0a%0aHumans look at this TMCL statement(s) and say "Ahh, now I know, what%0athis is about". And software looks at the TMCL statement(s) and says%0a"Ahh, now I know when to merge!".%0a%0aI do not see it that way that the data itself carries the information%0ahow to 'disclose'. It is actually a particular application which looks%0aat the data through the eyes of a TMCL statement. Other applications%0amay have different views on the same data.%0a%0aModern databases use this concept heavily.%0a%0a%3e For example, you refer below to topic maps that follow the SAME TMCL%0a%3e statements. How am I to determine that two (or more) topic maps follow%0a%3e the same TMCL statements?%0a%0aWhoever defines the language TMCL has to define how a machine can%0adetermine whether a given map m satisfies the conditions C given with%0aa set of TMCL statements. The designers of TMCL will (explicitely or%0aimplicitely) define a relation |=, so that one can determine whether%0a%0aC |= m%0a%0ais true or not.%0a%0a%3e That is to say, I can look at any topic map and determine everytime,%0a%3e what TMCL statement it follows?%0a%0aThat is the plan, yes.%0a%0aAs an aside: To determine whether a given map (called an%0a'interpretation' in logics) satisfies a given (set of) condition(s) is%0aa comparable 'cheap' operation. To _find_ a topic maps for a given set%0aof constraints is much harder. This is the difference between 'validation'%0aand 'finding proofs' TBL (Tim Berners Lee) is talking about.%0a%0a%3e %3eIf your two maps DO NOT follow the same TMCL statement, so that the%0a%3e %3emaps are incompatible, then one (or both) maps have to be transformed%0a%3e %3einto forms which are compatible. Transformations (also virtual ones)%0a%3e %3eyou can do with TMQL.%0a%3e %3e%0a%3e %3eThat way the process is very controlled and controllable.%0a%3e %3e%0a%3e But cf the question of how do I "know" two topic maps are following the%0a%3e same TMCL statement.%0a%0aAnd now we only have to test%0a%0aC |= m1 and C |= m2%0a%0a%0a===%0a%0a%3e So, how does a subject, whose identity may be determined by more than%0a%3e "ONE thing," have its identity expressed?%0a%0a\tau has no subjects, so this is not an issue. Complext identity is not%0aexpressed inside a \tau map.%0a%0a===%0a%0a%3e There is another problem, one which I think is more responsible for%0a%3e the difficulty of the TMRM .... When you say that members contain a%0a%3e pair %3cr, p%3e, it has a certain simplicity that is attractive but%0a%3e there is a problem.%0a%0a%3e Let's start with %3cr, p%3e.%0a%3e%0a%3e I assume that 'p' represents a subject, in the sense we use the term in%0a%3e TM land?%0a%0aFor the p's we only know that these are distinguishable things. No%0ainternal structure is known, although they could be as big as another%0auniverse. For us they behave as if they were names only.%0a%0a%3e Well, what if I want to talk about the subject of the relationship%0a%3e between "r, p"? Note, not talking about 'r' or 'p' but the%0a%3e relationship between them.%0a%0aYes? If a particular r and a particular p have a relationship, then%0athere must be an assertion for that. A fully-fledged assertion. And if%0aI want to talk about that as a subject, I give that assertion an%0aidentity.%0a%0a%3e And, if I can talk about that, I can also talk about the relationship%0a%3e between the two tokens that arise from that relationship, and so on.%0a%0aTokens?%0a%0aYou probably refer to the TMRM feature that allows to reify the fact%0athat a particular topic is casted into a particular role?%0a%0aI have always questioned this 'feature'. It introduces an%0ainconsistency into TMRM in the sense as it violates the general%0aspirit, that 'assertion' is the main paradigm. With this feature it is%0apossible to 'single out' a casting __IRRESPECTIVELY__ of the assertion%0ain which this casting is in.%0a%0aAnd then I would also ask, why only a single casting is becoming a%0asubject? Why not a combination of two, or three, or some?%0a%0aFor me, such a casting makes only sense in the context of the WHOLE%0aassertion. And that can be reified anyway.%0a%0a%3e The problem as I see it, is that in normal speech and even in viewing%0a%3e examples, we all elide over subjects that are not really relevant to the%0a%3e current conversation. That is to say that at some level, we realize%0a%3e there is a subject of the relationship between %3cr, p%3e but we don't%0a%3e express it because it does not seem to be relevant to the current%0a%3e conversation.%0a%3e%0a%3e The danger in that elision, however, we may arrive at a system that%0a%3e inhibits statements about subjects that we elided over in the design.%0a%0aA very valid concern. OTOH, we always loose information, there is NO%0away around it because 'abstraction' is exactly this: loosing%0ainformation. To avoid any information loss is a dead end, I would%0athink.%0a%0a%3e Personally that is how I view the notion of subject identity as treated%0a%3e in the TMDM. For my part, subject identity (we can all thank Steve%0a%3e Pepper for the more meaningful and not to mention pronounceable, SIP,%0a%0a%5b Indeed. :-) %5d%0a%0a%3e subject identity property) must be wholly left up to the topic map%0a%3e designer. To do otherwise, is to privilege some notions of subject%0a%3e identity over others, which TMAs may well do, but which ultimately%0a%3e limits the reach of topic maps.%0a%0aI would agree, but I would also fully accept a built-in bias towards%0a_some_ things which can become subjects (or actually are first-hand%0asubjects) and others which don't.%0a%0aThere reasoning behind this is that 'all data is effectively%0ateleological', that is 'all data is built with a purpose, a%0agoal'. Goals for different people may conflict. There is nothing like%0athe ultra-abstract, world-spanning, application independent database%0ascheme.%0a%0aSaying this, it also means that - whatever you may foresee in your%0amodel - people will ignore it. If, at some later stage, they%0arealize "oh, oh, we have built that in a stupid way, we cannot make%0astatements about this and that", then nothing should stop them to%0aconvert the map.%0a%0aAnd this is where TMQL kicks in again. It can extract information from%0aone (or more) existing maps and can create a new map. That may be much%0amore clever that its predecessor. They could even co-exist (virtual%0amaps).%0a%0a%3e Note that most syntaxes will make those choices in advance and%0a%3e properly so. That will allow them to be optimized for particular%0a%3e areas and I see no reason why that should not be allowed.%0a%0aYes, a syntax where everything is possible at everytime is hard to%0ause, hard to parse, hard to process and hard to handle.%0a%0a%3e %3eMaybe. :-) As I mentioned to Jan already, we did not see the necessity%0a%3e %3eto hard-code this into the formalism. If we need it later (and I like the%0a%3e %3ecleanness of the idea), then we can easily add it.%0a%3e %3e%0a%3e We may be using the terms formalism and formal model differently. Are%0a%3e you saying that that \tau model is a formalism (means of expression) or%0a%3e a formal model (means of expression + somethign being expressed)?%0a%0aThe 'means of expression' of the \tau model is - of course - set%0atheory. The structures we can build ontop of sets are models for topic%0amaps (abstract representations if you want). The extension of basic%0amaths by the rules given in \tau is the \tau formalism.%0a%0a%3e For example, the TMDM has rules for merging of topic information items.%0a%3e If I use another set of rules for merging topic information items, am I%0a%3e required to disclose those in a TMCL statement?%0a%0aI would put the question the other way round (I slowly begin to%0aunderstand your way of thinking):%0a%0aIf the application cares that the basic merging rules are not%0asufficient or are inappropriate for this particular application, then%0athe application has to do something against it. It is the application%0awhich interprets the data.%0a%0aThe data itself is completely dumb.%0a%0a%3e What if I took the route that Kal does and have implied topics? Part of%0a%3e the software and I suspect you get different behavior/capabilities from%0a%3e Kal's software than software that does not have that ability on the same%0a%3e topic map.%0a%0aI can only guess what 'implied topics' are (maybe it is the same we%0acall here 'virtual maps'), but yes, the meaning of the data is very much%0adetermined by the application.%0a%0a%3e %3e%3eYou don't say how the pairs of objects and literals arise. I assume that%0a%3e %3e%3eis intentional? (Thinking here of the TMRM's distinction between%0a%3e %3e%3ebuilt-in versus conferred properties.)%0a%3e%0a%3e %3eYes. This is a postulated set.%0a%3e%0a%3e Ok, so are you planning on saying how the postulated set arises?%0a%0aNo, because there is no need to do so. There are - at least at this%0astage - no further requirements on this set.%0a%0a%3e So you are saying there is no general notion of identity?%0a%0aNo general one, no. Identity (and equivalence) are only 'natural' at%0athe literal level. "Rumsti" and "Rumsti" are usually regarded the same.%0aThat may not true for a compiler for a programming language:%0a%0avar a = "Rumsti";%0aconst b = "Rumsti";%0a%0aShould the string "Rumsti" for a variable be the same allocated memory%0aas that for the constant? One is immutable, the other may be not.%0a%0a%3e That is to say if I wanted to return to my issue above of the identity%0a%3e of a subject being defined by more than "ONE thing," your most likely%0a%3e response is that such rules for identity are defined elsewhere?%0a%0aYup. Not only because identity could be induced by two or more 'properties'%0aof the object under comparison; also because identity/equivalence may depend%0aon things _outside_ the two objects. The weather, the government, ...%0a%0a%3e That is to say that the reference model only says that subjects have%0a%3e identities and those are defined for particular applications?%0a%0aYes, the 'reference model' (I would not call \tau at this stage a%0areference model, just an 'idea') would use a name (= label) to define%0a'atomic identity' and particular applications would use that and%0aadditionally some app-specific equivalence induction.%0a%0a--%0a%0aPhew. :=)%0a%0a\rho%0a%0aFrom: sc34wg3@isotopicmaps.org (Lars Marius Garshol)['0018849']['0021440']['0021435']['0020494']['00714']['0019321']m3bri7azrm.fsf@ontopia.netDate: Fri, 23 Jul 2004 10:33:49 +0200%0aSubject: %5bsc34wg3%5d And yet another...%0aIn-Reply-To: %3c69D276452CD2904980D5B6AC33C9BE1701ADEBC1@gtlbmlexs0006.bagmail.net%3e%0aReferences: %3c69D276452CD2904980D5B6AC33C9BE1701ADEBC1@gtlbmlexs0006.bagmail.net%3e%0aMessage-ID: %3cm3bri7azrm.fsf@ontopia.net%3e%0a%0aHi Holger,%0a%0a* Holger Rath%0a|%0a| Compact notation, easy to grasp, appealing to RDF people (not *only*%0a| because of the first two statements ;-), it can do more than TMDM%0a| (because TMDM is just one possible application of your FM).%0a|%0a| I like it! Good job!%0a%0aThank you! I was worried that the explanation of the model in there%0amight be too terse, so I'm glad to see you got it this quickly. :)%0a%0aIt can indeed do more than the TMDM; for example, it can represent RDF%0adirectly, with no loss of information. One thing that is lacking is%0amore work on how to represent TMDM, because I believe that if we get%0athat right we can remove the TMDM/RDF distinction almost entirely.%0a%0a| And I also have the impression (without knowing the latest TMRM%0a| version out of heart) that it is close to the TMRM minus the%0a| constraints/templating stuff TMRM has in it (and which is under%0a| discussion if it is necessary).%0a%0aI'm not sure this is true. I've always seen the assertion model as%0abeing the heart of the TMRM, and this model represents statements in a%0avery different way. They *are* similar in that they focus on%0astatements rather than nodes, however.%0a%0a--%0aLars Marius Garshol, Ontopian %3cURL: http://www.ontopia.net %3e%0aGSM: +47 98 21 55 50 %3cURL: http://www.garshol.priv.no %3e%0a%0a%0aFrom: sc34wg3@isotopicmaps.org (sc34wg3@isotopicmaps.org)['00726']['0021454']['0021419']['0020314']69D276452CD2904980D5B6AC33C9BE1701ADEBC1@gtlbmlexs0006.bagmail.net['00725']m3y8lb9hmw.fsf@ontopia.netDate: Fri, 23 Jul 2004 11:50:47 +0200%0aSubject: %5bsc34wg3%5d And yet another...%0aIn-Reply-To: %3c69D276452CD2904980D5B6AC33C9BE1701ADEC37@gtlbmlexs0006.bagmail.net%3e%0aReferences: %3c69D276452CD2904980D5B6AC33C9BE1701ADEC37@gtlbmlexs0006.bagmail.net%3e%0aMessage-ID: %3cm3y8lb9hmw.fsf@ontopia.net%3e%0a%0a* Holger Rath%0a|%0a| Well, Graham introduced me to quadruples 1.5 years ago when he%0a| developed the Semantic Web Server. So the idea was familiar to me%0a| :-)%0a%0aOh, you're a bad test subject, then. :)%0a%0aI knew Graham was onto this, too. We discussed this at least once when%0ahe worked for us (after he worked on the SWS), and I think I came up%0awith this myself (though to be frank I am not absolutely sure), and%0athat when presenting it to him I realized from his reaction that he'd%0aalready worked out pretty much the same thing for himself. I was not%0aaware that he'd implemented it, though.%0a%0a| Yep. And you sketched already how to do it: define a vocabulary for%0a| the TMDM properties. Maybe using RDFS and/or OWL.%0a%0aSomething along those lines, yes. The RTM vocabulary for mapping RDF%0ato topic maps is one possibility. What you suggest (and which I admit%0awas in the back of my mind) is another. I don't think either is quite%0a*there* yet, but I do think it can be done.%0a%0a| %5bTMRM relationship%5d%0a|%0a| That's what I meant. And the TMRM assertions always reminded me of%0a| RDF statements. And with the 4th element in the tuple you build the%0a| bridge for reification.%0a%0aRight. I suppose the main difference is that quad statements are%0afixed-size, and that theirs are variable-size (since you can always%0athrow in more roles and players). However, given that I represent each%0arole assignment as a quad it could be argued that my associations are%0avariable-sized, too. The difference is that I distinguish between%0aoccurrence/name assignments and associations, which TMRM and the Tau%0amodel do not do. Whether that's a strength or a weakness I'm not sure.%0a%0a| I am wondering how the TMRM people will react to your proposal.%0a%0aSo am I. :-)%0a%0a--%0aLars Marius Garshol, Ontopian %3cURL: http://www.ontopia.net %3e%0aGSM: +47 98 21 55 50 %3cURL: http://www.garshol.priv.no %3e%0a%0a%0aFrom: sc34wg3@isotopicmaps.org (sc34wg3@isotopicmaps.org)['00732']['0021454']['0021419']['0020314']69D276452CD2904980D5B6AC33C9BE1701ADEC37@gtlbmlexs0006.bagmail.net['00731']['0019085']['0018902']20040724053843.GA12451@mandoDate: Sat, 24 Jul 2004 15:38:43 +1000%0aSubject: %5bsc34wg3%5d And yet another...%0aIn-Reply-To: %3cm3oem7b1vm.fsf@ontopia.net%3e%0aReferences: %3cm3oem7b1vm.fsf@ontopia.net%3e%0aMessage-ID: %3c20040724053843.GA12451@mando%3e%0a%0aOn Fri, Jul 23, 2004 at 09:48:13AM +0200, Lars Marius Garshol wrote:%0a%3e%0a%3e I've written up and published my proposal for a foundational model for%0a%3e topic maps.%0a%0aLars,%0a%0aComments unavoidable, I would think :-)) I'll break this up to make it%0amore digestable for everyone.%0a%0a%0aPart I%0a%0a- First, thanks for suggesting a model. %5b Does actually anyone keep%0atrack on the number of 'models' we have produced over the years? %5d%0a%0a- Is there an error in the translation?%0a%0a(11, 14, 15, 1)%0a%0aseems very inconsistent to me, the edge is labelled 14 which is%0aalso the 'reifier' for the quadruple above.%0a%0a- BTW, you seem to use the word 'model' in three different meanings.%0a%0a"tolog as model"%0a%0a"foundation model as model"%0a%0a"quadruples form the model for the XTM file"%0a%0aI have no problem with that, but I think this is an area where%0acareful wording is probably relevant.%0a%0a\rho%0a%0aFrom: sc34wg3@isotopicmaps.org (Robert Barta)['0019321']['0021440']['0021419']['0020309']['00747']20040724054154.GB5802@mandoDate: Sat, 24 Jul 2004 15:41:54 +1000%0aSubject: %5bsc34wg3%5d And yet another...%0aIn-Reply-To: %3cm3oem7b1vm.fsf@ontopia.net%3e%0aReferences: %3cm3oem7b1vm.fsf@ontopia.net%3e%0aMessage-ID: %3c20040724054154.GB5802@mando%3e%0a%0aOn Fri, Jul 23, 2004 at 09:48:13AM +0200, Lars Marius Garshol wrote:%0a%3e%0a%3e I've written up and published my proposal for a foundational model for%0a%3e topic maps. It's unfortunately incomplete due to time constraints, but%0a%3e I've tried to get enough into the document to at least help people%0a%3e understand how it works and how it would be used.%0a%3e%0a%3e %3cURL: http://www.jtc1sc34.org/repository/0529.htm %3e%0a%3e%0a%3e Comments welcome, of course.%0a%0aLars,%0a%0aPart II%0a%0a- What I think that the proposal shows successfully is that you can%0atranslate any TMDM structure into RDF. Your quadruples are actually%0aRDF statements, or, more precisely, implementations thereof.%0a%0aAll implementations of RDF I have seen use this approach, although%0athe notation is maybe different:%0a%0amy $subject = ....%0amy $predicate = ....%0amy $object = ....%0amy $statement = new RDF::Core::Statement($subject, $predicate, $object);%0a%0a$statement is nothing else than the identifier for the whole thing, like%0awhat you suggest.%0a%0aIn this context you write%0a%0aFinally, the only way to represent associations in this model is%0ato turn them into full nodes with each role player connected in%0aby a triple of its own.%0a%0aWell, this is RDF isn't it?%0a%0a- The question is now whether the foundation model (FM) is a model for%0atopic maps. For me this is the case when all topic maps, say%0ainstances of TMDM, can be be mapped into the FM (completeness).%0a%0aYou have not shown all details, but I cannot see a problem here. Actually,%0athe RDF people have argued all along that this can be done and that TMs%0acan be disregarded because of this.%0a%0aThe other question is whether all sets of quadruples form valid topic%0amaps (soundness). This is less clear to me. Is, for instance, the set%0a%0a%5b 1, 2, 3, 4 %5d%0a%5b 5, 6, 7, 8 %5d%0a%0aa map? And if not, why not?%0a%0aIn this context you write that%0a%0aSince the thinking behind this proposal is that TMDM remain as it is%0aand where it is, it is not necessarily a problem for the%0afoundational model to not have the constraints in it. The%0aconstraints will be provided by TMDM, and the foundational model%0awill be specified as a transformation from TMDM to the set of tuples.%0a%0aIf the FM is simply a transformation of TMDM items into quaduple sets,%0athen what exactly is the additional benefit, except of showing one%0aalternative to implement TMDM instances?%0a%0aShould then not FM simply be an addendum to TMDM, or - even better -%0ashould TMDM not be drastically simplified by using quadruples only?%0a%0a- The FM would allow to map TMDM instances to quadruples. This is making%0ause of the 'vocabulary' we all (almost) love and use: basename, occurrences,%0avariants, ....%0a%0aWhat about using another vocabulary? birthdate, shoesize? Is this then%0aun-TM-ishly improper? How can I define which are there and in which%0aconstellation they may appear? (Others would call it 'disclosure'.)%0a%0aWould I have to write then a TMDM-rho which - in prose - would define%0aall this stuff? Isn't this a bit like going to field number one, given%0aall the TMRM discussions we had over the last year?%0a%0a\rho%0a%0a%0aFrom: sc34wg3@isotopicmaps.org (Robert Barta)['0019321']['0021440']['0021419']['0020309']['00753']20040724062321.GA12348@mandoDate: Sat, 24 Jul 2004 16:23:21 +1000%0aSubject: %5bsc34wg3%5d And yet another...%0aIn-Reply-To: %3cm3oem7b1vm.fsf@ontopia.net%3e%0aReferences: %3cm3oem7b1vm.fsf@ontopia.net%3e%0aMessage-ID: %3c20040724062321.GA12348@mando%3e%0a%0aOn Fri, Jul 23, 2004 at 09:48:13AM +0200, Lars Marius Garshol wrote:%0a%3e%0a%3e I've written up and published my proposal for a foundational model for%0a%3e topic maps.%0a%0aLars,%0a%0aPart III%0a%0a- You again use the predicate 'direct-instance-of'. Again, I raise the issue%0awhether this is a good practice to offer these things. In practice new subclasses%0amay be introduced and removed during the course of time. Should, because of%0athis, the outcome of a queries change?%0a%0aShould not programmers be encouraged to write robust queries which survive%0athese fluctuations?%0a%0a- You have not covered all cases of FORALL p EXISTS q and SOME p SATISFY q.%0aSince you map this into Prolog/Datalog this should not be a problem. Still,%0aI would like to see whether you can transfer the semantics.%0a%0a- You write that%0a%0aIf we take tolog as the model then a magic predicate (not visible%0ain the language) called '_quadruple' can be defined, and all%0aother built-in predicates (except /=) defined using this. To wit:%0a%0atype($X, $TOPIC) :- _quadruple($X, TYPE, $Q, $TOPIC).%0atopic-name($TOPIC, $NAME) :- _quadruple($TOPIC, TOPIC_NAME, $NAME, $V).%0avariant($TNAME, $VARIANT) :- _quadruple($TNAME, VARIANT, $VARIANT, $V).%0a....%0a%0aWhat you are saying is that tolog can be easily reduced (read implemented) using%0aa single predicate. I certainly buy that.%0a%0aIn fact, this leads to the question why tolog is not simply a set of a few%0arules like these above? Why fuss around with a query language at all? Why not%0ause Prolog and add 10-15 rules (like the ones above) and we are done? Why%0ago through the whole circus of specifying a query language?%0a%0a%5b In fact, you yourself said many times that tolog is not specific%0ato topic maps as it can query "anything you like" (RDF, relational%0astuff). It is just using the logic programming paradigm behind%0atolog. %5d%0a%0aAnd if we do this with TMQL what should stop us to express constraints as%0aProlog rules? Maybe tweak a bit with the syntax (use SELECT, WHERE and ? to%0agive SQL developers a warm feeling :-), but use Prolog.%0a%0a----%0a%0aMy answer, why a dedicated QL and CL for TMs would make sense in the first%0aplace, is that we DO NOT WANT a predicate approach.%0a%0aWhy? I think, because of computational complexity (read: potential speed). A%0apredicate approach like in tolog is coming with Datalog. Datalog (please%0acorrect me) is based on Horn-Clauses. Horn clauses are restricted FOL%0aexpressions. Unfortunately, problems expressed with Horn clauses are not fully%0adecidable, i.e. for a given set of data and a given set of horn clauses, the%0aresolution algorithm may find a solution. Or not. Or it just may take long.%0a%0aIn fact, Prolog programmers play around with all sorts of tricks (cut,%0areordering, ...) to make the programs (a) either terminate or (b) faster.%0a%0aThis could imply (I am not a logician but I am not the one proposing the TMQL%0asemantics based on Horn clauses), that some things may not be 'provable', like%0athe subsumption "Is a mother a woman", something you immediately need when you%0aprocess queries together with ontological knowledge.%0a%0aThis is EXACTLY the reason why OWL DOES NOT USE FOL (first order logic) but%0avaries flavours of DLs. For most of the DL flavours VERY efficient algorithms%0aare known by now. And these are guaranteed to terminate. Something which may%0abe mostly relevant for the kinds of applications in the semantic web arena.%0a%0a--%0a%0aSo, if we do not want to disqualify ourselves out of this market at this%0astage, a query/constraint language should not be like the tank in a glass shop.%0aYes, you have the power to fire granades, but....%0a%0a\rho%0a%0aFrom: sc34wg3@isotopicmaps.org (Robert Barta)['0019321']['0021440']['0021419']['0020309']['00759']20040724063031.GA17402@mandoDate: Sat, 24 Jul 2004 16:30:31 +1000%0aSubject: %5bsc34wg3%5d And yet another...%0aIn-Reply-To: %3cm3oem7b1vm.fsf@ontopia.net%3e%0aReferences: %3cm3oem7b1vm.fsf@ontopia.net%3e%0aMessage-ID: %3c20040724063031.GA17402@mando%3e%0a%0aOn Fri, Jul 23, 2004 at 09:48:13AM +0200, Lars Marius Garshol wrote:%0a%3e%0a%3e I've written up and published my proposal for a foundational model for%0a%3e topic maps.%0a%0aLars,%0a%0aPart IV (last one)%0a%0a- You write that%0a%0aThis proposal originally came out of the author's search for an%0aefficient representation of topic maps....%0a%0aDo you regard an FM-like representation as an efficient one?%0a%0a- You write that%0a%0aThe definition will probably live in a corner of the TMQL%0aspecification and be part of the machinery used to define TMQL%0awithout the model itself being normative in any real%0asense. Further, TMCL can then use bits from the TMQL%0aspecification (the model, the vocabulary, the semantics) for its%0aown purposes.%0a%0aShould not be this%0a%0aEITHER completely INSIDE TMQL%0aOR factored out and USED by both, TMQL and TMCL%0a%0a?%0a%0a%5b Here I refer to the diagram which I have sent to Ann, Steve P. and others%0aabout my suggestions on the arrangement of the standards. %5d%0a%0a\rho%0a%0aFrom: sc34wg3@isotopicmaps.org (Robert Barta)['0019321']['0021440']['0021419']['0020309']['00765']20040724072802.GB18880@mandoDate: Sat, 24 Jul 2004 17:28:02 +1000%0aSubject: %5bsc34wg3%5d Look Ma! No Properties!%0aIn-Reply-To: %3c41017B86.E42958F3@topicmapping.com%3e%0aReferences: %3c40F71C6B.9020106@sbl-site.org%3e %3c20040716072755.GF31418@mando%3e %3c41017B86.E42958F3@topicmapping.com%3e%0aMessage-ID: %3c20040724072802.GB18880@mando%3e%0a%0aOn Fri, Jul 23, 2004 at 10:56:38PM +0200, Jan Algermissen wrote:%0a%3e Robert,%0a%3e%0a%3e I had posted two other questions about your proposal. Maybe you missed%0a%3e them. Here they are again:%0a%0aJan,%0a%0aMy apologies, I thought I had covered this in the other mails.%0a%0a%3e Robert Barta wrote:%0a%3e %3e%0a%3e %3e On Thu, Jul 15, 2004 at 08:08:11PM -0400, Patrick Durusau wrote:%0a%3e %3e%0a%3e %3e %3e Ok, the \tau model has no properties.%0a%3e %3e%0a%3e %3e The \tau model is based on assertions only. Properties are seen as%0a%3e %3e only a special form of an assertion, yes.%0a%3e%0a%3e Uhm...I don't get it. How are properties seen as a special form of%0a%3e assertion?%0a%0aIf you look at the property 'shoesize' which is attached to a person,%0athen you would have assertions of the form:%0a%0a{ %3c person: rho %3e, %3c shoesize: 42 %3e }%0a%0aWhat I find always appealing in this 'relativistic' view of the world%0ais that objects are going away completely and are reduced to%0adots. Everything else is interaction with something else.%0a%0a%3e %3e Just to make an example to avoid a too abstract discussion: Lets%0a%3e %3e assume we model students with their names, their shoesize and their%0a%3e %3e student ID (SID). In the 'assembler-like' tau model we would only have%0a%3e %3e assertions:%0a%3e %3e%0a%3e %3e { %3c name-haver: jack-learner %3e, %3c name : "Jack Learner" %3e },%0a%3e %3e { %3c shoesize-haver: jack-learner %3e, %3c shoesize : 1234 %3e }%0a%3e %3e { %3c sid-haver: jack-learner %3e, %3c SID : 12345678 %3e }%0a%3e%0a%3e I guess I am missing the step how you group together the assertions that%0a%3e have members (r1,p1),(r2,p1),(r3,p1) with p1 E N (not I !!)%0a%3e and how this enables the forall semantics on p1, allowing you to%0a%3e view name,shoesize and SID as properties.%0a%0aHmmm, with 'grouping' you mean 'identification'? In that case, since%0ap1 is the same everywhere it is the same thing in all members. Names%0aare similar to IDs, except that behind a name could be a huge%0athings. You cannot see it, though.%0a%0aThe 'forall semantics' is not directly applicable here as the model%0aitself does not have any semantics. It is like a skeleton. Structure,%0abut no movement, no action.%0a%0aThe 'forall semantics' (and reciprocal the 'exists') kicks in if you%0aintroduce quantifiers into queries and constraints. You need them%0ato express queries like%0a%0a"give me all computer clusters in my network where all machines%0aare down"%0a%0a\rho%0a%0aFrom: sc34wg3@isotopicmaps.org (Jan Algermissen)['0018902']['0021440']['0021405']['0020309']['00771']410252E9.2032812E@topicmapping.comDate: Sat, 24 Jul 2004 14:15:37 +0200%0aSubject: %5bsc34wg3%5d And yet another...%0aReferences: %3c69D276452CD2904980D5B6AC33C9BE1701ADEC37@gtlbmlexs0006.bagmail.net%3e %3cm3y8lb9hmw.fsf@ontopia.net%3e%0aMessage-ID: %3c410252E9.2032812E@topicmapping.com%3e%0a%0aLars Marius Garshol wrote:%0a%3e%0a%3e * Holger Rath%0a%0a%3e | I am wondering how the TMRM people will react to your proposal.%0a%3e%0a%3e So am I. :-)%0a%0aHi Lars,%0a%0abefore looking at the model at a detaled level, I'd again like to stress%0awhat I consider to be the most important (and still unabswered) issue:%0a%0aYoue write:%0a%0a%3cquote%3e%0aThis is a proposal for a Foundational Model for topic maps that is intended to meet the%0afollowing goals:%0a%0aIt should be simpler than TMDM.%0a%0aIt should be able to fully represent TMDM without loss of information.%0a%0aIt should be suitable as a common foundation for TMCL and TMQL.%0a%0aIt should be sufficiently formal to appeal to an academic audience.%0a%0a%3c/quote%3e%0a%0a%0aDo you mean to say that the above goals are the goals the reference model part of%0athe standard should meet? And if the reference model meets them, then it is a good%0amodel?%0a%0aHonestly, I think this is far too weak if the intention is that Topic Maps as a%0aparadigm are to have any significant impact in the field of data modeling and%0ainformation organisation.%0a%0aI am deeply convinced that the purpose (the overall goal) of the paradigm as such%0ais the only source for real requirements that any structural model must meet.%0a%0a%0aIMHO, the 'flow of argumentation' must be:%0a%0a"Topic Maps are a paradigm that is designed to solve this and that existing problem%0aand in doing so, it will have this and that benefit for users of the paradigm.%0aThe abstract information structure that underlies all topic maps must be designed to%0ameet the requirements imposed be the overall goals of the paradigm. Therefore, this%0aabstract information structure is as follows...."%0a%0aA precise statement on the goal of Topic Maps is the *only* source for evaluation%0aof any proposed underlying model.%0a%0a%0aSo, why don't we define this overall goal of Topic Maps *first*?%0a%0aSeveral things may happen:%0a%0a1) We all agree%0a%0aFine, then we'd have a clear means of reasoning why your model, Robert's or%0athe current RM is best suited or why they are all missing the critical points.%0a%0a2) We know what we think, but we totally disagree%0a%0aLess fine, but also ok. This will give us a basis for further discussion and%0aIMHO reveal the real source of the disagreements over the last years.%0a%0a3) We do not know what to say%0a%0aBad! Without knowing what the paradigm is to achieve, how can we find an%0aappropriate model? How can we ever argue, that what we propose (RM included)%0ais sufficient, if we do not even know what it must be sufficient for?%0a%0a%0aSo, would everyone mind to write down her or his understanding what this overall%0agoal is? I have never read nor heard anything that would give me a clue. Honestly.%0a%0a%0a%0a%3crant%3e%0aThere is surely more to Topic Maps then doing data integration (merging)%0aon datasets that all share a common ontology (name,occurrence, class-instance,%0asuperclass subclass)?!?%0a%0aIf this is all, then a published relational schema would have done the job.%0a%3c/rant%3e%0a%0a%0aJan%0a%0a%0a%0a%3e --%0a%3e Lars Marius Garshol, Ontopian %3cURL: http://www.ontopia.net %3e%0a%3e GSM: +47 98 21 55 50 %3cURL: http://www.garshol.priv.no %3e%0a%3e%0a%3e _______________________________________________%0a%3e sc34wg3 mailing list%0a%3e sc34wg3@isotopicmaps.org%0a%3e http://www.isotopicmaps.org/mailman/listinfo/sc34wg3%0a%0a--%0aJan Algermissen http://www.topicmapping.com%0aConsultant %26 Programmer%09 http://www.gooseworks.org%0a%0aFrom: sc34wg3@isotopicmaps.org (Lars Marius Garshol)['0021452']['0021419']['0020309']['00777']m3wu0rtff8.fsf@pavarotti.intern.opera.noDate: Mon, 26 Jul 2004 09:07:23 +0200%0aSubject: %5bsc34wg3%5d And yet another...%0aReferences: %3c69D276452CD2904980D5B6AC33C9BE1701B7B54C@gtlbmlexs0006.bagmail.net%3e%0aMessage-ID: %3cm3wu0rtff8.fsf@pavarotti.intern.opera.no%3e%0a%0a* Holger Rath%0a|%0a| Hmmm, but when you make the distinction between your general quad%0a| model and the application of the quad model to TMDM (= vocabulary of%0a| properties) more explicit in your spec then your are very close to%0a| TMRM. Quad model is on the same abstraction level as TMRM and the%0a| vocabulary defines the application. So, you also "invented" a way%0a| to define application of your model, which is - I think but I am not%0a| sure - still missing in TMRM.%0a%0aThat's true. The difference (apart from the substance, of course) is%0amostly one of rhetoric and degree of formality.%0a%0a| I expect very exciting discussion in Montreal ... a pitty that I'll%0a| miss that.%0a%0aYes, it would have been very nice to have you there. Better luck in%0aWashington, perhaps?%0a%0a--%0aLars Marius Garshol, Ontopian %3cURL: http://www.ontopia.net %3e%0aGSM: +47 98 21 55 50 %3cURL: http://www.garshol.priv.no %3e%0a%0a%0aFrom: sc34wg3@isotopicmaps.org (Lars Marius Garshol)['0021454']['0021419']['0021310']['00782']m3oem3tfdx.fsf@pavarotti.intern.opera.noDate: Mon, 26 Jul 2004 09:08:10 +0200%0aSubject: %5bsc34wg3%5d And yet another...%0aReferences: %3c69D276452CD2904980D5B6AC33C9BE1701ADEC37@gtlbmlexs0006.bagmail.net%3e%0a%3cm3y8lb9hmw.fsf@ontopia.net%3e %3c410252E9.2032812E@topicmapping.com%3e%0aMessage-ID: %3cm3oem3tfdx.fsf@pavarotti.intern.opera.no%3e%0a%0a* Jan Algermissen%0a|%0a| Do you mean to say that the above goals are the goals the reference%0a| model part of the standard should meet? And if the reference model%0a| meets them, then it is a good model?%0a%0aWhat I'm saying is that that was the goal I was interested in. If the%0aRM had met this goal I would have been interested in the RM, yes.%0a%0a| Honestly, I think this is far too weak if the intention is that%0a| Topic Maps as a paradigm are to have any significant impact in the%0a| field of data modeling and information organisation.%0a%0aThat's your view.%0a%0a| I am deeply convinced that the purpose (the overall goal) of the%0a| paradigm as such is the only source for real requirements that any%0a| structural model must meet.%0a%0aAs far as I'm concerned XTM 1.0 did this a long time ago, except it%0adidn't have a model. Now it does.%0a%0a| IMHO, the 'flow of argumentation' must be:%0a|%0a| "Topic Maps are a paradigm that is designed to solve this and that%0a| existing problem and in doing so, it will have this and that benefit%0a| for users of the paradigm. The abstract information structure that%0a| underlies all topic maps must be designed to meet the requirements%0a| imposed be the overall goals of the paradigm. Therefore, this%0a| abstract information structure is as follows...."%0a%0aAs far as I'm concerned TMDM == Topic Maps, and this is how I've%0aevaluated TMDM. For me, the RM/FM/... discussion isn't on this level%0aat all.%0a%0a| A precise statement on the goal of Topic Maps is the *only* source%0a| for evaluation of any proposed underlying model.%0a%0aNo, Jan, that's not a given. You may think so, but I don't. As far as%0aI'm concerned ISO already defined what topic maps are a long time ago%0aand what we're doing now is something else.%0a%0a| So, why don't we define this overall goal of Topic Maps *first*?%0a%0aGood question. I've been asking about this for years, and you're%0aactually the first person to take up the question as far as I can%0aremember.%0a%0a| Several things may happen:%0a|%0a| 1) We all agree%0a|%0a| Fine, then we'd have a clear means of reasoning why your model,%0a| Robert's or the current RM is best suited or why they are all%0a| missing the critical points.%0a|%0a| 2) We know what we think, but we totally disagree%0a|%0a| Less fine, but also ok. This will give us a basis for further%0a| discussion and IMHO reveal the real source of the disagreements%0a| over the last years.%0a|%0a| 3) We do not know what to say%0a|%0a| Bad! Without knowing what the paradigm is to achieve, how can we%0a| find an appropriate model? How can we ever argue, that what we%0a| propose (RM included) is sufficient, if we do not even know what%0a| it must be sufficient for?%0a%0aWe're on 3) now, as far as I know. We're most likely to move on to 2),%0aprobably.%0a%0a| So, would everyone mind to write down her or his understanding what%0a| this overall goal is? I have never read nor heard anything that%0a| would give me a clue. Honestly.%0a%0aI'm with you on this, and I think I've done it.%0a%0a| %3crant%3e%0a| There is surely more to Topic Maps then doing data integration%0a| (merging) on datasets that all share a common ontology%0a| (name,occurrence, class-instance, superclass subclass)?!?%0a|%0a| If this is all, then a published relational schema would have done%0a| the job.%0a| %3c/rant%3e%0a%0aFrankly, I don't see that either TMDM or RM do any more than this.%0a%0a--%0aLars Marius Garshol, Ontopian %3cURL: http://www.ontopia.net %3e%0aGSM: +47 98 21 55 50 %3cURL: http://www.garshol.priv.no %3e%0a%0a%0aFrom: sc34wg3@isotopicmaps.org (Lars Marius Garshol)['0021454']['0021419']['0021310']['00787']m3fz7ftfdk.fsf@pavarotti.intern.opera.noDate: Mon, 26 Jul 2004 09:08:23 +0200%0aSubject: %5bsc34wg3%5d And yet another...%0aReferences: %3cm3oem7b1vm.fsf@ontopia.net%3e %3c20040724063031.GA17402@mando%3e%0aMessage-ID: %3cm3fz7ftfdk.fsf@pavarotti.intern.opera.no%3e%0a%0a* Robert Barta%0a|%0a| Part IV (last one)%0a|%0a| - You write that%0a|%0a| This proposal originally came out of the author's search for an%0a| efficient representation of topic maps....%0a|%0a| Do you regard an FM-like representation as an efficient one?%0a%0aYes. That's just a side-effect, though, and not something that matters%0afor the purposes of this discussion.%0a%0a| - You write that%0a|%0a| The definition will probably live in a corner of the TMQL%0a| specification and be part of the machinery used to define TMQL%0a| without the model itself being normative in any real%0a| sense. Further, TMCL can then use bits from the TMQL%0a| specification (the model, the vocabulary, the semantics) for its%0a| own purposes.%0a|%0a| Should not be this%0a|%0a| EITHER completely INSIDE TMQL%0a| OR factored out and USED by both, TMQL and TMCL%0a|%0a| ?%0a%0aI think so, yes. This is orthogonal to the issue of which simpler%0amodel we choose, though. Whether we use FM/Tau/RM/somethingelse%0adoesn't really affect this question.%0a%0a| %5b Here I refer to the diagram which I have sent to Ann, Steve%0a| P. and others about my suggestions on the arrangement of the%0a| standards. %5d%0a%0aYou didn't send it to me, so that reference doesn't help much.%0a%0a--%0aLars Marius Garshol, Ontopian %3cURL: http://www.ontopia.net %3e%0aGSM: +47 98 21 55 50 %3cURL: http://www.garshol.priv.no %3e%0a%0a%0aFrom: sc34wg3@isotopicmaps.org (Lars Marius Garshol)['0021454']['0021419']['0021310']['00792']m37jsrtfax.fsf@pavarotti.intern.opera.noDate: Mon, 26 Jul 2004 09:09:58 +0200%0aSubject: %5bsc34wg3%5d And yet another...%0aReferences: %3cm3oem7b1vm.fsf@ontopia.net%3e %3c20040724062321.GA12348@mando%3e%0aMessage-ID: %3cm37jsrtfax.fsf@pavarotti.intern.opera.no%3e%0a%0a* Robert Barta%0a|%0a| Part III%0a|%0a| - You again use the predicate 'direct-instance-of'. Again, I raise%0a| the issue whether this is a good practice to offer these%0a| things. In practice new subclasses may be introduced and removed%0a| during the course of time. Should, because of this, the outcome of a%0a| queries change?%0a|%0a| Should not programmers be encouraged to write robust queries which%0a| survive these fluctuations?%0a%0aThat's a separate discussion. I just took tolog as my example TMQL to%0ashow how the quad model could be used with it. Whether or not tolog is%0agood is a completely different discussion.%0a%0a| - You have not covered all cases of FORALL p EXISTS q and SOME p%0a| SATISFY q. Since you map this into Prolog/Datalog this should not%0a| be a problem. Still, I would like to see whether you can transfer%0a| the semantics.%0a%0aSo would I, but there wasn't time. This is one of the open issues.%0a%0a| - You write that%0a|%0a| If we take tolog as the model then a magic predicate (not visible%0a| in the language) called '_quadruple' can be defined, and all%0a| other built-in predicates (except /=) defined using this. To wit:%0a|%0a| %09type($X, $TOPIC) :- _quadruple($X, TYPE, $Q, $TOPIC).%0a| %09topic-name($TOPIC, $NAME) :- _quadruple($TOPIC, TOPIC_NAME, $NAME, $V).%0a| %09variant($TNAME, $VARIANT) :- _quadruple($TNAME, VARIANT, $VARIANT, $V).%0a| ....%0a|%0a| What you are saying is that tolog can be easily reduced (read%0a| implemented) using a single predicate. I certainly buy that.%0a%0aYep.%0a%0a| In fact, this leads to the question why tolog is not simply a set%0a| of a few rules like these above? Why fuss around with a query%0a| language at all? Why not use Prolog and add 10-15 rules (like the%0a| ones above) and we are done? Why go through the whole circus of%0a| specifying a query language?%0a%0aThere are several reasons for this:%0a%0a- Prolog is unsuitable for a query language because it is%0aTuring-complete%0a%0a- a custom syntax provides us with far better support for topic maps%0a(crucially through dynamic association predicates, which account%0afor most of what is done with tolog)%0a%0a| %5b In fact, you yourself said many times that tolog is not specific%0a| to topic maps as it can query "anything you like" (RDF, relational%0a| stuff). It is just using the logic programming paradigm behind%0a| tolog. %5d%0a%0aYes.%0a%0a| And if we do this with TMQL what should stop us to express%0a| constraints as Prolog rules? Maybe tweak a bit with the syntax%0a| (use SELECT, WHERE and ? to give SQL developers a warm feeling%0a| :-), but use Prolog.%0a%0aI don't think that would give us a very good query language, for the%0areasons given above.%0a%0aAlso, as was agreed in Amsterdam, we want the path expressions, which%0acertainly do not exist in any way, shape, or form in Prolog.%0a%0a| My answer, why a dedicated QL and CL for TMs would make sense in%0a| the first place, is that we DO NOT WANT a predicate approach.%0a%0aUh?%0a%0a| Why? I think, because of computational complexity (read: potential%0a| speed). A predicate approach like in tolog is coming with%0a| Datalog. Datalog (please correct me) is based on Horn-Clauses.%0a| Horn clauses are restricted FOL expressions. Unfortunately,%0a| problems expressed with Horn clauses are not fully decidable,%0a| i.e. for a given set of data and a given set of horn clauses, the%0a| resolution algorithm may find a solution. Or not. Or it just may%0a| take long.%0a%0aDatalog is based on Horn clauses, yes, but it's fully decidable. And%0asince we would here be creating the evaluation algorithm ourselves it%0awould be up to us to ensure that it was decidable. I don't see that%0athis is an issue in any way.%0a%0a| In fact, Prolog programmers play around with all sorts of tricks%0a| (cut, reordering, ...) to make the programs (a) either terminate%0a| or (b) faster.%0a%0aProlog is *very* different from Datalog. Their evaluation algorithms%0aare completely different. Prolog is Turing-complete, but Datalog has%0athe same expressivity as SQL3. I think discussing Prolog in this%0acontext just confuses the issues, really.%0a%0a| This could imply (I am not a logician but I am not the one%0a| proposing the TMQL semantics based on Horn clauses), that some%0a| things may not be 'provable', like the subsumption "Is a mother a%0a| woman", something you immediately need when you process queries%0a| together with ontological knowledge.%0a|%0a| This is EXACTLY the reason why OWL DOES NOT USE FOL (first order%0a| logic) but varies flavours of DLs. For most of the DL flavours%0a| VERY efficient algorithms are known by now. And these are%0a| guaranteed to terminate. Something which may be mostly relevant%0a| for the kinds of applications in the semantic web arena.%0a%0aI think you are reading more into my notation than what is there. If%0ayou go back and look at the actual document it describes a few%0aoperations (predicate application, predicate application chaining,%0aunion, set difference, and probably a couple of others). *That*%0alanguage is what we are discussing, not FOL, though admittedly what I%0awrote may have made it lookas though that's what I meant.%0a%0aI guess you could argue that it seems silly for us to define our own%0alanguage when these other ones exist, but I think you've already%0aargued quite convincingly why we can't use the existing ones. And you%0aare yourself defining a semantics from scratch so the only real%0adifference here is that what I'm doing looks similar to something that%0aalready exists (and probably this confused you) whereas you're doing%0asomething that's much harder to confuse with something else.%0a%0a| So, if we do not want to disqualify ourselves out of this market%0a| at this stage, a query/constraint language should not be like the%0a| tank in a glass shop. Yes, you have the power to fire granades,%0a| but....%0a%0aAgreed.%0a%0a--%0aLars Marius Garshol, Ontopian %3cURL: http://www.ontopia.net %3e%0aGSM: +47 98 21 55 50 %3cURL: http://www.garshol.priv.no %3e%0a%0a%0aFrom: sc34wg3@isotopicmaps.org (Lars Marius Garshol)['0021454']['0021419']['0021310']['00797']m3pt6js0jd.fsf@pavarotti.intern.opera.noDate: Mon, 26 Jul 2004 09:14:14 +0200%0aSubject: %5bsc34wg3%5d And yet another...%0aReferences: %3cm3oem7b1vm.fsf@ontopia.net%3e %3c20040724053843.GA12451@mando%3e%0aMessage-ID: %3cm3pt6js0jd.fsf@pavarotti.intern.opera.no%3e%0a%0a* Robert Barta%0a|%0a| Comments unavoidable, I would think :-))%0a%0aNot really. If the thing were not interesting it would not merit%0acomments.%0a%0a| Part I%0a|%0a| - First, thanks for suggesting a model.%0a%0aYou're welcome. :)%0a%0a| - Is there an error in the translation?%0a|%0a| (11, 14, 15, 1)%0a|%0a| seems very inconsistent to me, the edge is labelled 14 which is%0a| also the 'reifier' for the quadruple above.%0a%0aYeah, it's wrong. I had to change the numbering half-way through and%0aclearly got things muddled. Thanks for catching it. Corrected version:%0a%0a(1, SOURCE_LOCATOR, 2, "file://example.xtm#lmg")%0a(1, TOPIC_NAME, 3, "Lars Marius Garshol")%0a(3, VARIANT, 4, "garshol, lars marius")%0a(4, SCOPE, 5, 6)%0a(6, SUBJECT_IDENTIFIER, 7, "http://www.topicmaps.org/xtm/1.0/core.xtm#sort")%0a(1, 8, 9, "The person who wrote this document.")%0a(8, SUBJECT_IDENTIFIER, 10, "http://psi.ontopia.net/xtm/occurrence-type/description")%0a(11, TYPE, 12, 13) /* 11 is an association */%0a(13, SUBJECT_IDENTIFIER, 14, "http://psi.example.com/employed-by")%0a(11, 15, 16, 1)%0a(15, SUBJECT_IDENTIFIER, 17, "http://psi.example.com/employee")%0a(11, 18, 19, 20)%0a(18, SUBJECT_IDENTIFIER, 21, "http://psi.example.com/employer")%0a(20, SOURCE_LOCATOR, 22, "file://example.xtm#ontopia")%0a%0a| - BTW, you seem to use the word 'model' in three different meanings.%0a|%0a| "tolog as model"%0a|%0a| "foundation model as model"%0a|%0a| "quadruples form the model for the XTM file"%0a|%0a| I have no problem with that, but I think this is an area where%0a| careful wording is probably relevant.%0a%0aYeah. For "tolog as model" read "tolog as the basis for TMQL".%0a%0aFor "From this XTM file we'd get the model shown below" read%0a"From this XTM file we'd get the model *instance* shown below".%0a%0aI think that clarifies things at least a little.%0a%0a--%0aLars Marius Garshol, Ontopian %3cURL: http://www.ontopia.net %3e%0aGSM: +47 98 21 55 50 %3cURL: http://www.garshol.priv.no %3e%0a%0a%0aFrom: sc34wg3@isotopicmaps.org (Lars Marius Garshol)['0021454']['0021419']['0021310']['00802']m3y8l7s0ju.fsf@pavarotti.intern.opera.noDate: Mon, 26 Jul 2004 09:13:57 +0200%0aSubject: %5bsc34wg3%5d And yet another...%0aReferences: %3cm3oem7b1vm.fsf@ontopia.net%3e %3c20040724054154.GB5802@mando%3e%0aMessage-ID: %3cm3y8l7s0ju.fsf@pavarotti.intern.opera.no%3e%0a%0a* Robert Barta%0a|%0a| Part II%0a|%0a| - What I think that the proposal shows successfully is that you can%0a| translate any TMDM structure into RDF. Your quadruples are actually%0a| RDF statements, or, more precisely, implementations thereof.%0a%0aNearly, but not quite. All my quads that have a statement ID as the%0afirst item in the quad are very awkward to reproduce in real RDF. The%0areal merit here (if there is any) must lie in the ability of the model%0ato represent both TMDM and RDF more easily than TMDM and RDF can%0arepresent this model.%0a%0a| All implementations of RDF I have seen use this approach, although%0a| the notation is maybe different:%0a|%0a| my $subject = ....%0a| my $predicate = ....%0a| my $object = ....%0a| my $statement = new RDF::Core::Statement($subject, $predicate, $object);%0a|%0a| $statement is nothing else than the identifier for the whole thing, like%0a| what you suggest.%0a%0aSure, but you can't easily refer to $statement in a new statement in%0aRDF. That's why exporting TMs to RDF is so difficult, because where do%0ayou put scope, variants, and reification?%0a%0a| In this context you write%0a|%0a| Finally, the only way to represent associations in this model is%0a| to turn them into full nodes with each role player connected in%0a| by a triple of its own.%0a|%0a| Well, this is RDF isn't it?%0a%0aNot really. In RDF the employed-by relationship goes like this:%0a%0a(employee-topic, employed-by, employer-topic)%0a%0awhile in the FM it goes%0a%0a(assoc-id, employee, id1, employee-topic)%0a(assoc-id, employer, id2, employer-topic)%0a(assoc-id, TYPE, id3, employed-by)%0a%0a| - The question is now whether the foundation model (FM) is a model for%0a| topic maps. For me this is the case when all topic maps, say%0a| instances of TMDM, can be be mapped into the FM (completeness).%0a|%0a| You have not shown all details, but I cannot see a problem here.%0a%0aThere is one problem, actually, which isn't described in the document.%0aIf we use the occurrence type as the value of the second item of the%0aquad to represent occurrences there is nothing in there that says that%0athis actually *is* an occurrence and not, say, a typed name.%0a%0aThe solutions I've thought of for this problem are%0a%0aa) introduce a TMDM restriction that says a type can only be used as%0aa type for a single kind of construct, or%0a%0ab) turn the quads into quints.%0a%0aI haven't gone for either yet, because I think this problem is%0aintimately related to the RDF/TM interoperability problem, and that%0aremains unsolved here, even though it does appear to be within reach.%0a%0a| Actually, the RDF people have argued all along that this can be%0a| done and that TMs can be disregarded because of this.%0a%0aIf you take the Omnigator, go into opera.xtm, click export, select%0aRDF/XML format, and study the result I think you'll have to admit that%0ait's harder than it seems. In fact, it's so hard that I think the%0aclaim can be dismissed out of hand, unless I misunderstand something.%0a%0a| The other question is whether all sets of quadruples form valid topic%0a| maps (soundness). This is less clear to me. Is, for instance, the set%0a|%0a| %5b 1, 2, 3, 4 %5d%0a| %5b 5, 6, 7, 8 %5d%0a|%0a| a map? And if not, why not?%0a%0aThat's a good question, and I think this is what the first para of 5%0ais talking about. Frankly, I don't know if this is an interesting%0aquestion.%0a%0aDo we care about this model as a model, or do we only care about it as%0aa way of connecting XTM/CXTM with TMQL/TMCL? I don't know the answer%0ato this, but I think we should answer this question for ourselves%0abefore we spend a lot of time creating a waterproof model for%0asomething that may in the end be no more than an editorial device.%0a%0a| In this context you write that%0a|%0a| Since the thinking behind this proposal is that TMDM remain as%0a| it is and where it is, it is not necessarily a problem for the%0a| foundational model to not have the constraints in it. The%0a| constraints will be provided by TMDM, and the foundational%0a| model will be specified as a transformation from TMDM to the%0a| set of tuples.%0a|%0a| If the FM is simply a transformation of TMDM items into quaduple sets,%0a| then what exactly is the additional benefit, except of showing one%0a| alternative to implement TMDM instances?%0a%0aIt makes it easier to do TMQL. End of story, really. (Of course, there%0ais the RDF bit, but whether we can make any use of that in the%0astandards work I don't know.)%0a%0a| Should then not FM simply be an addendum to TMDM, or - even better%0a| - should TMDM not be drastically simplified by using quadruples%0a| only?%0a%0aI'm not sure it *would* be simplified, since you'd have to import all%0athe constraints into the quad model. How that would look I haven't%0aconsidered.%0a%0aThe other thing is that TMDM has gone to CD after three years of%0acommittee work. I'd hate to start the mill necessary to stop it and%0areplace it with something based on quads, especially when, as you say,%0ait's not clear that there's any benefit to it.%0a%0aMy conclusion is that I think this model, if we do further work on it%0aat all, should go into TMQL as the basis for TMQL and the means of%0aconnecting TMQL with TMDM.%0a%0a| - The FM would allow to map TMDM instances to quadruples. This is%0a| making use of the 'vocabulary' we all (almost) love and use:%0a| basename, occurrences, variants, ....%0a%0aYep.%0a%0a| What about using another vocabulary? birthdate, shoesize? Is this%0a| then un-TM-ishly improper?%0a%0aBirthdate and shoesize are both occurrence types in TMDM. So%0a%0a%3ctopic id="rho"%3e%0a%3coccurrence%3e%0a%3cinstanceOf%3e%0a%3ctopicRef xlink:href="#shoesize"/%3e%0a%3c/instanceOf%3e%0a%3cresourceData%3e41%3c/resourceData%3e%0a%3c/occurrence%3e%0a%3coccurrence%3e%0a%3cinstanceOf%3e%0a%3ctopicRef xlink:href="#birthdate"/%3e%0a%3c/instanceOf%3e%0a%3cresourceData%3eunknown%3c/resourceData%3e%0a%3c/occurrence%3e%0a%3c/topic%3e%0a%0awould become (using symbolic identifiers this time, for readability)%0a%0a(rho, SOURCE_LOCATOR, statement1, "file://...#rho")%0a(rho, shoesize, statement2, "41")%0a(rho, birthdate, statement3, "unknown")%0a(shoesize, SOURCE_LOCATOR, statement4, "file://...#shoesize)%0a(birthdate, SOURCE_LOCATOR, statement5, "file://...#birthdate)%0a%0aI guess what I'm saying is that you don't *need* another vocabulary%0ato do this sort of thing; you just do it within TMDM.%0a%0a| How can I define which are there and in which constellation they%0a| may appear? (Others would call it 'disclosure'.)%0a%0aTMCL is still the answer to that question, as far as I'm concerned.%0a%0a| Would I have to write then a TMDM-rho which - in prose - would%0a| define all this stuff? Isn't this a bit like going to field number%0a| one, given all the TMRM discussions we had over the last year?%0a%0aIt would be, yes. So I'm not talking about that, but only about%0aconnecting TMDM with TMCL/TMQL.%0a%0a--%0aLars Marius Garshol, Ontopian %3cURL: http://www.ontopia.net %3e%0aGSM: +47 98 21 55 50 %3cURL: http://www.garshol.priv.no %3e%0a%0a%0aFrom: sc34wg3@isotopicmaps.org (Lars Marius Garshol)['0021454']['0021419']['0021310']['00807']m3acxns062.fsf@pavarotti.intern.opera.noDate: Mon, 26 Jul 2004 09:22:13 +0200%0aSubject: %5bsc34wg3%5d And yet another...%0aIn-Reply-To: %3c05f701c470ef$72726210$0c01a8c0@MAINFRAME%3e%0aReferences: %3cm3oem7b1vm.fsf@ontopia.net%3e%0a%3c05f701c470ef$72726210$0c01a8c0@MAINFRAME%3e%0aMessage-ID: %3cm3acxns062.fsf@pavarotti.intern.opera.no%3e%0a%0aHi Martin,%0a%0a* Martin Bryan%0a|%0a| I'm afraid your examples are beyond my limited brain capacity.%0a%0aI'm not sure that's the problem. I had to send this thing out before I%0ahad time to explain it in much detail, so it probably is quite hard to%0agrasp from 0529.%0a%0a| For the life of me I can't fathom out (11, 17, 18, 19)%0a%0aWhat that quad is saying is that "11 (the association) has a role of%0atype 17 played by topic 19, and 18 is the ID of this statement".%0a%0a| or where the TYPE comes from in (11, TYPE, 12, 13).%0a%0aIt's the same kind of thing as 11, 12, and 13, except that it's an%0aidentifier I predefined to mean the %5btype%5d property from TMDM. So what%0athat statement is saying is "11 (the association) has as its type%0atopic 13, and the ID of this statement is 12".%0a%0a| I presume this is the same TYPE that appears in _quadruple($X, TYPE,%0a| $Q, $TOPIC)%0a%0aYes.%0a%0a| but here I have trouble scoping $Q.%0a%0aThe Q is there only because tolog requires me to specify something for%0aall four parameters of the _quadruple predicate, and so had I to put%0asomething there, even though it's not used. So you can ignore that.%0a%0a| Similarly I can't scope $V.%0a%0aIt's another unused variable. It holds the string/URI value of the%0astatement being matched, but it doesn't go anywhere, so it's not used.%0a%0a| I know this is only a draft, but a little more explanation of%0a| mysteriously appearing and disappearing parameters would be very%0a| much appreciated by those of us who are a bit rusty in the mind%0a| reading department :-)%0a%0aI know. I'm sorry about this. I've had this idea lying around for%0amonths, and have been writing this text in what spare time I've had%0aover the past month. As you can tell I haven't had much spare time.%0a%0a--%0aLars Marius Garshol, Ontopian %3cURL: http://www.ontopia.net %3e%0aGSM: +47 98 21 55 50 %3cURL: http://www.garshol.priv.no %3e%0a%0a%0aFrom: sc34wg3@isotopicmaps.org (Lars Marius Garshol)['0019085']['0021454']['0021419']['0021310']['00812']['0019752']m3k6wqq3l4.fsf@pavarotti.intern.opera.noDate: Mon, 26 Jul 2004 15:51:19 +0200%0aSubject: %5bsc34wg3%5d RM workshop agenda%0aMessage-ID: %3cm3k6wqq3l4.fsf@pavarotti.intern.opera.no%3e%0a%0aDo we have an agenda for the RM workshop? Does anyone consider%0athemselves responsible for creating one? I think it's very important%0athat we have an agenda before we arrive, in order to make sure we have%0aa productive meeting. If nobody else wants the task I can take it on,%0abut I don't want to step on any toes here.%0a%0a--%0aLars Marius Garshol, Ontopian %3cURL: http://www.ontopia.net %3e%0aGSM: +47 98 21 55 50 %3cURL: http://www.garshol.priv.no %3e%0a%0a%0aFrom: sc34wg3@isotopicmaps.org (sc34wg3@isotopicmaps.org)['0021454']['0021032']['0021310']['00823']['0018704']['0019914']['0019585']m3llh6orvn.fsf@pavarotti.intern.opera.noDate: Tue, 27 Jul 2004 09:01:48 +0200%0aSubject: %5bsc34wg3%5d Re: %5bsc34wg3%5d RM workshop agenda%0aReferences: %3c6892716$109085027341050de11edef9.39492269@config7.schlund.de%3e%0aMessage-ID: %3cm3llh6orvn.fsf@pavarotti.intern.opera.no%3e%0a%0a* jalgermissen@topicmapping.com%0a|%0a| Regardless of wheather this is related to the overall purpose of%0a| Topic Maps or not, I think one item of this agenda should be to%0a| define the requirements, against which any proposal and the various%0a| aspects of the proposals can be evaluated.%0a%0aYeah, I agree. But I can't say that before there's a process to create%0aan actual agenda. So I was trying to get that process started before I%0asaid what you just said. :)%0a%0aAnyway, we very much agree on this.%0a%0a| Without such requirements, the evaluation will be done on the basis%0a| of personal taste and is likely to lead to nothing but disagreement.%0a%0aYep.%0a%0a| I regret that I am not able to participate, but I wish you a%0a| productive meeting.%0a%0aIt would be nice to finally meet you, but better luck some other time,%0aI guess.%0a%0a--%0aLars Marius Garshol, Ontopian %3cURL: http://www.ontopia.net %3e%0aGSM: +47 98 21 55 50 %3cURL: http://www.garshol.priv.no %3e%0a%0a%0aFrom: sc34wg3@isotopicmaps.org (Lars Marius Garshol)['0021454']['0021032']['0020310']['00844']['0018719']m3vfg9or8q.fsf@pavarotti.intern.opera.noDate: Tue, 27 Jul 2004 09:15:33 +0200%0aSubject: %5bsc34wg3%5d And yet another...%0aIn-Reply-To: %3c41054E91.9AC1996@topicmapping.com%3e%0aReferences: %3c69D276452CD2904980D5B6AC33C9BE1701ADEC37@gtlbmlexs0006.bagmail.net%3e%0a%3cm3y8lb9hmw.fsf@ontopia.net%3e %3c410252E9.2032812E@topicmapping.com%3e%0a%3cm3oem3tfdx.fsf@pavarotti.intern.opera.no%3e%0a%3c41054E91.9AC1996@topicmapping.com%3e%0aMessage-ID: %3cm3vfg9or8q.fsf@pavarotti.intern.opera.no%3e%0a%0a* Jan Algermissen%0a|%0a| Yes. All I try to do is to contribute to a robust and long living%0a| standard and I neccessarily do that according to my believes. Sorry%0a| if that sounds too aggressive at times.%0a%0aYou didn't sound aggressive at all; it's just that we've been debating%0athis issue for three years already, and I don't want to spend more%0atime discussing it, since I don't think further discussion will get us%0aanywhere.%0a%0a| %5bgoals%5d%0a|%0a| Can you point me to exactly where you did that. No offense intended%0a| here, I just want to make sure I look at exactly the text that you%0a| understand to define the overall goal.%0a%0aWhen you wrote "Topic Maps" I took it to mean what I mean by%0a"Foundational Model", and so I wrote this up in the beginning of 0529.%0a%0aWriting up the goals for "topic maps" as I understand the term is a%0abit late at this point, given that the standard was first published in%0a2000.%0a%0a| Well, time will tell, I guess :-)%0a%0aSo it will. :)%0a%0a--%0aLars Marius Garshol, Ontopian %3cURL: http://www.ontopia.net %3e%0aGSM: +47 98 21 55 50 %3cURL: http://www.garshol.priv.no %3e%0a%0a%0aFrom: sc34wg3@isotopicmaps.org (Lars Marius Garshol)['0019914']['0021454']['0021419']['0020310']['00854']m3r7qxoqu7.fsf@pavarotti.intern.opera.noDate: Tue, 27 Jul 2004 09:24:16 +0200%0aSubject: %5bsc34wg3%5d Comments on Tau model%0aIn-Reply-To: %3c20040726230011.GA6843@mando%3e%0aReferences: %3cm3oem3qkhk.fsf@pavarotti.intern.opera.no%3e%0a%3c20040726230011.GA6843@mando%3e%0aMessage-ID: %3cm3r7qxoqu7.fsf@pavarotti.intern.opera.no%3e%0a%0a* Robert Barta%0a|%0a| Yes, it's the operations which count. But: Whenever you choose a%0a| 'particular structure' then you - in the same step - implicitely%0a| choose the operations which come with it.%0a%0aUp to a point, yes.%0a%0a| I would not know why you could not do that. Maybe the description is%0a| a bit different in complexity.%0a%0aYeah, I think the complexity of the resulting description is the test%0afor all of these models. I think the problem we have right now is that%0anone of them have been carried forward to the point where we can judge%0athe complexity. I'm not sure what to do about that.%0a%0a(Below I cut your answers to a lot of my questions, since there's not%0amuch of interest to say to a "Yes" response. :-)%0a%0a| No, as every assertion is a thing by itself which can be referenced%0a| in any other assertion the 'type of an assertion a' is expressed by%0a| another assertion which happens to have the right roles (class,%0a| instance).%0a%0aWell, for more on that see my other set of comments.%0a%0a| So there is no special treatment for "association types".%0a%0aIn that case it seems to me that the TMDM representation in the Tau%0amodel is going to be quite large and that potentially it may be%0adifficult to use it to define TMQL. I may be wrong, but these worries%0acrop up immediately.%0a%0a* Lars Marius Garshol%0a|%0a| In 1.4 the two basic operations are defined. Interestingly, since all%0a| is defined in terms of roles in assertions, this is very similar to%0a| the FM I proposed, if the model I used is changed to use the structure%0a| I used for associations for *all* statements.%0a%0a* Robert Barta%0a|%0a| Ye....es. I think it this is a consequence of getting rid of topics,%0a| moving everything into assertions/quadruples/... Since you only%0a| have now assertions, you only have to worry about these.%0a%0aThat's probably correct, but I find it very interesting that the model%0ayou came up with is so close to the one I envisioned. On the subway to%0athe office this morning I was thinking we should just go with the Tau%0amodel and see where it got us. Now that I've seen your answers I'm not%0aso sure any more.%0a%0a* Lars Marius Garshol%0a|%0a| Regarding 2, are you sure that instances/subclassing belongs in the%0a| core model? In my view this is more suitable for user-space%0a| vocabulary.%0a%0a* Robert Barta%0a|%0a| No, I am not sure, whether it belongs here.%0a|%0a| But: 1) These both assertions types are so inherent in our%0a| ontological thinking that they would have a right to be first-class%0a| citizens.%0a%0aI don't think that necessarily follows. Note that XTM 1.0, TMDM, and%0aRDF all chose a different approach.%0a%0a| %5b2%5d 2) As you pointed out already there is a need to express an%0a| assertion type and as you point out below the basic operations%0a| DO NOT make use of this assertion type.%0a|%0a| Now, in practical cases I would like to say%0a|%0a| lars -%3e player / plays-squash-somewhere%0a|%0a| ^^^^ ^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^%0a|%0a| thing role association type%0a|%0a| and not just%0a|%0a| lars -%3e player%0a|%0a| To define such convenient operations I need to have%0a| /instance-of/ inside the formalism.%0a%0aTrue, but this is what TMDM calls "type" and not "instance of". I%0aguess we should leave this alone until we've seen how TMDM is%0arepresented in the Tau model.%0a%0a* Lars Marius Garshol%0a|%0a| In 2.3 the list of operations provided is, interestingly, very%0a| nearly the same as the one I sketch in my FM proposal. Yours is of%0a| course much more detailed, but it's interesting that the operations%0a| seem to be the same.%0a%0a* Robert Barta%0a|%0a| I wonder how the exists and forall things look like in FM.%0a%0aI don't know, really. If it turns out that Tau does this much more%0aneatly then that's a strong argument in Tau's favour, I'd say. I think%0awe all have more work to do here before we're ready to make a%0adecision.%0a%0a--%0aLars Marius Garshol, Ontopian %3cURL: http://www.ontopia.net %3e%0aGSM: +47 98 21 55 50 %3cURL: http://www.garshol.priv.no %3e%0a%0a%0aFrom: sc34wg3@isotopicmaps.org (Lars Marius Garshol)['0019585']['0021454']['0021429']['0020310']['00860']m3n01loqp2.fsf@pavarotti.intern.opera.noDate: Tue, 27 Jul 2004 09:27:21 +0200%0aSubject: %5bsc34wg3%5d Comments on Tau model%0aIn-Reply-To: %3c41054785.40658AA3@topicmapping.com%3e%0aReferences: %3cm3oem3qkhk.fsf@pavarotti.intern.opera.no%3e%0a%3c41054785.40658AA3@topicmapping.com%3e%0aMessage-ID: %3cm3n01loqp2.fsf@pavarotti.intern.opera.no%3e%0a%0a* Lars Marius Garshol%0a|%0a| I guess my key question for the author of this model is why he chose%0a| the particular structure he did. As far as I can tell, almost any%0a| underlying structure would have served the purpose, since it is the%0a| operations that do the job. To put it another way, couldn't the%0a| exact same set of operations have been used on a quad model? Or on%0a| some third model?%0a%0a* Jan Algermissen%0a|%0a| that is exactly the point I am trying to make. Without some%0a| requirements, the choice of the underlying model is arbitrary.%0a%0aThat's a different point, actually. What I was noting was that despite%0ahaving a different model Robert actually had very nearly the same%0aoperations as me. Robert and I actually have our requirements: we need%0ato support the TMQL specification.%0a%0a--%0aLars Marius Garshol, Ontopian %3cURL: http://www.ontopia.net %3e%0aGSM: +47 98 21 55 50 %3cURL: http://www.garshol.priv.no %3e%0a%0a%0aFrom: sc34wg3@isotopicmaps.org (Patrick Durusau)['0018704']['0021454']['0021429']['0020310']['00866']['0018897']['0019412']['0018954']m3ekmw3zxr.fsf@pavarotti.intern.opera.noDate: Wed, 28 Jul 2004 17:37:52 +0200%0aSubject: %5bsc34wg3%5d RM workshop agenda%0aIn-Reply-To: %3cFEF4858E8AB32D4EAC2CF2A7D85386EBBC7EC8@lnxdayexch06b.lexis-nexis.com%3e%0aReferences: %3cFEF4858E8AB32D4EAC2CF2A7D85386EBBC7EC8@lnxdayexch06b.lexis-nexis.com%3e%0aMessage-ID: %3cm3ekmw3zxr.fsf@pavarotti.intern.opera.no%3e%0a%0a* Eric D. Freese%0a|%0a| What is the likelihood of the meeting stretching into Sunday? My%0a| flights got re-arranged and I won't be arriving until Saturday night%0a| now. Just want to know if I should try to find you on Sunday.%0a%0aAs far as I know the meeting is scheduled for Saturday and Sunday, but%0athis is one of the (unstated) questions I had about the agenda.%0a%0a--%0aLars Marius Garshol, Ontopian %3cURL: http://www.ontopia.net %3e%0aGSM: +47 98 21 55 50 %3cURL: http://www.garshol.priv.no %3e%0a%0a%0aFrom: sc34wg3@isotopicmaps.org (Lars Marius Garshol)['0019412']['0021454']['0021032']['0020316']['00888']m365883zhx.fsf@pavarotti.intern.opera.noDate: Wed, 28 Jul 2004 17:47:22 +0200%0aSubject: %5bsc34wg3%5d RM workshop agenda%0aIn-Reply-To: %3cm3isc83zzd.fsf@pavarotti.intern.opera.no%3e%0aReferences: %3cm3k6wqq3l4.fsf@pavarotti.intern.opera.no%3e%0a%3c4107C59F.5060802@sbl-site.org%3e%0a%3cm3isc83zzd.fsf@pavarotti.intern.opera.no%3e%0aMessage-ID: %3cm365883zhx.fsf@pavarotti.intern.opera.no%3e%0a%0a* Lars Marius Garshol%0a|=20%0a| I think that sounds good. I think the last requirements draft will%0a| work for you %26 SRN, but I'm not sure it will work for anyone%0a| else. It may be that point 1 will actually take up the whole%0a| workshop. We'll see. (For my take on the requirements, see the four%0a| bullet points at the start of my proposal.)%0a%0aOh, one more thing. Graham and I were contacted by the OMG, which%0awants to create a UML model of the TMDM. We've answered lots of%0aquestions from them, and they've put together a quite nice model of%0ait. Now they came back and said, in effect, "actually, this is silly;%0awe should have a common model", and so now they want a collaborative%0aeffort on this.%0a%0aI can explain the background, show the model they've done, and present%0athe parameters for the collaboration that they are proposing when we%0aare in Montr=E9al, but I need space on the agenda for this. I'd also%0alike us to briefly discuss this and agree on a way to do it (I'll%0apropose one, but I want community backing on it).=20%0a%0aCan I get 1 hour for this? It doesn't really matter where, though at%0athe beginning might be good, to ensure we get it done, and as a nice,%0auncontroversial start to the meeting.%0a%0a--=20%0aLars Marius Garshol, Ontopian %3cURL: http://www.ontopia.net %3e%0aGSM: +47 98 21 55 50 %3cURL: http://www.garshol.priv.no %3e%0a%0a%0aFrom: sc34wg3@isotopicmaps.org (Patrick Durusau)['0018954']['0021454']['0021032']['0020316']['00894']['0018933']m3u0vs2jiq.fsf@pavarotti.intern.opera.noDate: Wed, 28 Jul 2004 18:17:49 +0200%0aSubject: %5bsc34wg3%5d RM workshop agenda%0aIn-Reply-To: %3c4107CF71.2070708@sbl-site.org%3e%0aReferences: %3cm3k6wqq3l4.fsf@pavarotti.intern.opera.no%3e%0a%3c4107C59F.5060802@sbl-site.org%3e%0a%3cm3isc83zzd.fsf@pavarotti.intern.opera.no%3e%0a%3c4107CF71.2070708@sbl-site.org%3e%0aMessage-ID: %3cm3u0vs2jiq.fsf@pavarotti.intern.opera.no%3e%0a%0a* Patrick Durusau%0a|%0a| I may have been unclear. I was referring to the list of requirements%0a| that WG3 drafted last summer, not the restatement of them by SteveN%0a| and myself. As I recall, you were working the keyboard.%0a%0aI couldn't find this on my system in the iso/montreal-2003 folder, but%0athat doesn't mean I didn't do it.%0a%0a| Your position on the requirements may have changed since that time%0a| but I am not sure we should simply throw the requirements process%0a| back open to start from scratch once again. Well, assuming that%0a| delay is something we want to avoid.%0a%0aI think probably what I captured was your requirements, in an effort%0ato understand what they were, rather than my own, but if you feel it%0areflects your thinking then that's fine with me. It gives us something%0ato start from. The important point is just that *someone* has to agree%0awith them, otherwise it's kind of a waste. :)%0a%0a| I think part of my disagreement centers in your language%0a| "...author's search for an efficient representation of topic%0a| maps....". (in Background)%0a|%0a| Personally I don't view ISO 13250 as having a goal of efficiently%0a| representing topic maps,%0a%0aI agree fully. That was the background for coming up with this idea,%0anot the reason why ISO should be interested in the idea. It's the four%0abullet points that gives the requirements, not the rest, so please%0ajust ignore that.%0a%0a| I am really tired and will probably be going out with my boss%0a| tonight but perhaps we can exchange a few posts before Montreal on%0a| the the "implementation neutral" issue before the meeting?%0a%0aI don't think there's any disagreement on this, actually. I don't want%0aany implementation-specific stuff in the standard, either. (Nor do I%0athink Graham, as an empolis employee working on a different%0aimplementation from the one I'm working on, would let me put any in.)%0a%0aHowever, I don't see XTM/TMDM as an implementation; I see them as%0abeing topic maps. This has been a running debate for three years now,%0aso I'm not sure it's worth spending any more time on this particular%0aaspect.%0a%0a| Realize that you may wish to term the TMDM "implementation neutral"%0a| as well so we will need to find some other term to describe what I%0a| am trying to say.%0a%0aYes. :-)%0a%0a--%0aLars Marius Garshol, Ontopian %3cURL: http://www.ontopia.net %3e%0aGSM: +47 98 21 55 50 %3cURL: http://www.garshol.priv.no %3e%0a%0a%0aFrom: sc34wg3@isotopicmaps.org (Dmitry)['0018933']['0021454']['0021032']['0020316']['00905']FDAAFF0A-E113-11D8-B686-000A957183D4@cogeco.caDate: Thu, 29 Jul 2004 00:01:38 -0400%0aSubject: %5bsc34wg3%5d Several slides with yet another model%0aMessage-ID: %3cFDAAFF0A-E113-11D8-B686-000A957183D4@cogeco.ca%3e%0a%0ahttp://homepage.mac.com/dmitryv/TopicMaps/TMRM/TMAssert.pdf%0a%0aDmitry%0a%0a%0aFrom: sc34wg3@isotopicmaps.org (Patrick Durusau)['0021248']['00912']['0020315']Several slides with yet another model['00911']['00911']410881FF.7090704@sbl-site.orgDate: Thu, 29 Jul 2004 00:50:07 -0400%0aSubject: %5bsc34wg3%5d Proposed Agenda for Reference Model Workshop%0aMessage-ID: %3c410881FF.7090704@sbl-site.org%3e%0a%0aGreetings!%0a%0aHurriedly as I am finishing packing for the trip to Montreal:%0a%0aSuggest (subject to item #1) the following agenda for the reference%0amodel workshop:%0a%0aSaturday:%0a%0a9:00 AM%0a%0a1. Approval of agenda%0a%0a2. Presentation of proposed models (dividing the time remaining until%0anoon equally between the proposals, Newcomb/Durusau, Garshol, Barta, Dmitry)%0a%0aMy thinking here is that each presentation should focus on the model%0abeing presented.%0a%0aNoon-1:30 PM Lunch%0a%0a1:30 - 5 PM%0a%0a3. Discussion of reference model requirements%0a%0aMy thinking here is that the prior discussion of the various proposals%0awill give us a framework within which to discuss actual requirements, as%0aopposed to discussing them completely in the abstract.%0a%0aSunday:%0a%0a9:00 AM - Noon%0a%0aComparison of the results of the requirements discussion to the various%0amodels, lead serially by the proponents of the various models.%0a%0aNoon-1:30 PM Lunch%0a%0a1:30 PM - 3:00 PM%0a%0aFormulation of next steps towards a reference model (One of the things%0awe have been lacking as the result of prior meetings is some specific%0asteps that will take us to the next stage.)%0a%0a3:00 - 5:00 PM%0a%0aPresentation of the OMG model for the TMDM%0a%0aMy thinking here is that it will give us something to look forward to as%0athe end of the meeting and allow us to conclude on a high note. While%0aLars and I disagree on some fundamental issues, be aware that I do think%0athe TMDM is important and my disagreements are about its place in the%0atopic maps paradigm and not disagreement about the importance of data%0amodels.%0a%0aWill be offline the rest of the day traveling.%0a%0aShould be able to pick up discussion in the AM tomorrow (Montreal time).%0a%0aHope everyone is at the start of a great day!%0a%0aPatrick%0a%0a--%0aPatrick Durusau%0aDirector of Research and Development%0aSociety of Biblical Literature%0aPatrick.Durusau@sbl-site.org%0aChair, V1 - Text Processing: Office and Publishing Systems Interface%0aCo-Editor, ISO 13250, Topic Maps -- Reference Model%0a%0aTopic Maps: Human, not artificial, intelligence at work!%0a%0a%0a%0aFrom: sc34wg3@isotopicmaps.org (Patrick Durusau)['0021442']['00917']['0020315']Proposed Agenda for Reference Model Workshop['00916']['00916']['0018679']MDAEMON-F200407301023.AA2315393md50000134552@csw.co.ukDate: Fri, 30 Jul 2004 10:23:10 +0100%0aSubject: %5bsc34wg3%5d Essence of the TMRM%0aIn-Reply-To: %3c410958E3.3010509@sbl-site.org%3e%0aMessage-ID: %3cMDAEMON-F200407301023.AA2315393md50000134552@csw.co.uk%3e%0a%0aPatrick %26 all,%0a%0aThis latest posting brings out v. clearly to me that one of the most%0adifficult problems we must face this week-end is how we can compare models%0adeveloped using radically different approaches, in our case%0aformal/mathematical vs philosophical/linguistic/rhetorical. Neither is%0anecessarily good or bad, however comparison is difficult because from the%0apoint of view of either, the other will inevitably tend to be seen as%0amissing the point rather than providing a reasonable alternative. To add to%0athe difficulty, TMDM is based on yet another approach, from IT/engineering.%0a%0aI hope this helps.%0a%0aI'm travelling today, %26 will be around in the Europa this eve (no guarantees%0aabout being awake :)%0a%0aAnn W.%0a%0a%0a%0aFrom: sc34wg3@isotopicmaps.org (Jan Algermissen)['0018679']['0021227']['0021431']['0020156']['00926']410A1E90.FBDCB0A7@topicmapping.comDate: Fri, 30 Jul 2004 12:10:24 +0200%0aSubject: %5bsc34wg3%5d Essence of the TMRM%0aReferences: %3cMDAEMON-F200407301023.AA2315393md50000134552@csw.co.uk%3e%0aMessage-ID: %3c410A1E90.FBDCB0A7@topicmapping.com%3e%0a%0aAnn Wrightson wrote:%0a%0a%3e how we can compare models%0a%0aHi,%0a%0ait would propably also be a very good idea to start with a working%0adefinition of 'model' since this term is so heavily overloaded.%0a%0aIMHO, it would help a lot, to clearly distinguish between%0a%0a- abstract information structure%0a(the *view* provided on how the data is organised)%0a%0a- the semantics that are expressed by some data%0a(the ontology or schema)%0a%0aIt is a basic question, how many semantics should go into%0athe informations structure. Example: TMDM intermingles the 'TAO'%0asemantics with the information structure, the RM does not. With the%0aRM, the 'TAO' semantics are simply *a* (standard) ontology.%0a%0aWhile the latter offers greater freedom, because it is more%0ageneric, the former makes application development easier, because%0aimplementors can rely on more structural information.%0a%0aEnjoy the workshop ;-)%0a%0aJan%0a%0a%0a%0a%0a--%0aJan Algermissen http://www.topicmapping.com%0aConsultant %26 Programmer%09 http://www.gooseworks.org%0a%0aFrom: sc34wg3@isotopicmaps.org (Patrick Durusau)['0021452']['0021431']['0020156']['00932']410A301F.5090507@sbl-site.orgDate: Fri, 30 Jul 2004 07:25:19 -0400%0aSubject: %5bsc34wg3%5d Essence of the TMRM%0aReferences: %3cMDAEMON-F200407301023.AA2315393md50000134552@csw.co.uk%3e%0aMessage-ID: %3c410A301F.5090507@sbl-site.org%3e%0a%0aAnn,%0a%0aAnn Wrightson wrote:%0a%3e Patrick %26 all,%0a%3e%0a%3e This latest posting brings out v. clearly to me that one of the most%0a%3e difficult problems we must face this week-end is how we can compare models%0a%3e developed using radically different approaches, in our case%0a%3e formal/mathematical vs philosophical/linguistic/rhetorical. Neither is%0a%3e necessarily good or bad, however comparison is difficult because from the%0a%3e point of view of either, the other will inevitably tend to be seen as%0a%3e missing the point rather than providing a reasonable alternative. To add to%0a%3e the difficulty, TMDM is based on yet another approach, from IT/engineering.%0a%3e%0a%0aI don't find the "formal/mathematical vs.%0aphilosophical/linguistic/rhetorical" distinction all that helpful.%0a%0aWhat we need to isolate are the points made by the models, however we%0awould characterize the models. That will at least allow us to separate%0athe points made by the models from the manner in which they were made.%0a%0aGranted that formal/mathematical expressions are useful, but they have%0ato start from underlying assumptions about what is to be expressed or%0aproved.%0a%0aIt is those points that I think we can extract and compare for purposes%0aof the reference model workshop.%0a%0aHope you have a great trip!%0a%0aPatrick%0a%0a%0a%0a%3e I hope this helps.%0a%3e%0a%3e I'm travelling today, %26 will be around in the Europa this eve (no guarantees%0a%3e about being awake :)%0a%3e%0a%3e Ann W.%0a%3e%0a%3e%0a%3e _______________________________________________%0a%3e sc34wg3 mailing list%0a%3e sc34wg3@isotopicmaps.org%0a%3e http://www.isotopicmaps.org/mailman/listinfo/sc34wg3%0a%3e%0a%0a%0a--%0aPatrick Durusau%0aDirector of Research and Development%0aSociety of Biblical Literature%0aPatrick.Durusau@sbl-site.org%0aChair, V1 - Text Processing: Office and Publishing Systems Interface%0aCo-Editor, ISO 13250, Topic Maps -- Reference Model%0a%0aTopic Maps: Human, not artificial, intelligence at work!%0a%0a%0a%0a%0aFrom: sc34wg3@isotopicmaps.org (Martin Bryan)['0021442']['0021431']['0020156']['00937']0b0901c47667$94305100$0c01a8c0@MAINFRAMEDate: Fri, 30 Jul 2004 20:01:11 +0100%0aSubject: %5bsc34wg3%5d Essence of the TMRM%0aReferences: %3c410958E3.3010509@sbl-site.org%3e%0aMessage-ID: %3c0b0901c47667$94305100$0c01a8c0@MAINFRAME%3e%0a%0aPatrick%0a%0a%3e What is NOT OK is to redefine 13250 in such a way that all subject%0a%3e proxies in all topic maps must use only certain standardized kinds%0a%3e of information as subject descriptors, and only certain ways of%0a%3e comparing such restricted kinds of information. In other words, it is%0a%3e not OK for TMDM to re-state 13250 in such a way that, where 13250%0a%3e had left things wide open for Application designers to decide, 13250%0a%3e will now be a single, pre-designed Application.%0a%0aBeautifully stated. I could never have got such clarity to my objections to%0athe XTM-based model.%0a%0a%3e Hope everyone is having a great day!%0a%0aIt was terrible until your message cheered me up. Thanks%0a%0aMartin Bryan%0a%0a%0aFrom: sc34wg3@isotopicmaps.org (Lars Marius Garshol)['0021451']['0021431']['0020156']['00942']m3vfg5feuu.fsf@ontopia.netDate: Fri, 30 Jul 2004 21:56:57 +0200%0aSubject: %5bsc34wg3%5d Essence of the TMRM%0aIn-Reply-To: %3c410958E3.3010509@sbl-site.org%3e%0aReferences: %3c410958E3.3010509@sbl-site.org%3e%0aMessage-ID: %3cm3vfg5feuu.fsf@ontopia.net%3e%0a%0a* Patrick Durusau%0a|%0a| What is NOT OK is to redefine 13250 in such a way that all subject%0a| proxies in all topic maps must use only certain standardized kinds%0a| of information as subject descriptors, and only certain ways of%0a| comparing such restricted kinds of information. In other words, it%0a| is not OK for TMDM to re-state 13250 in such a way that, where 13250%0a| had left things wide open for Application designers to decide, 13250%0a| will now be a single, pre-designed Application.%0a%0aFirstly, what the TMDM actually does is to define four standard%0amechanisms for identifying subjects:%0a%0a- source locators, (the IDs from HyTM and XTM),%0a%0a- subject identifiers, (the subject indicator references from XTM,%0aand, as you note, roughly equivalent to the subject descriptors of%0aHyTM),%0a%0a- subject locators, (unnamed property from XTM), and,%0a%0a- unique characteristic types (new in TMDM).%0a%0aHowever, TMDM does not preclude merging by means other than these, so%0ano freedom has been removed. Nothing that could be done using subject%0adescriptors is now impossible.%0a%0aSecondly, let's assume your criticism is valid. Then what? What do you%0awant to do? We could of course add in a "subject descriptor" concept%0aand say that it can be used to merge topics on in any what whatsoever,%0abut if we did the standard would be no different from what it is now,%0aexcept it would have an undefined concept in it.%0a%0a| Topic map designers should be as free as they were in ISO 13250 to%0a| declare any basis they wish to use to determine when two subject%0a| proxies represent the same subject.%0a%0aWe still have that, and you should know that we still have that. Why%0ado you write this? What's the point?%0a%0a--%0aLars Marius Garshol, Ontopian %3cURL: http://www.ontopia.net %3e%0aGSM: +47 98 21 55 50 %3cURL: http://www.garshol.priv.no %3e%0a%0a%0aFrom: sc34wg3@isotopicmaps.org (Steve Pepper)['0018679']['0021454']['0021431']['0020156']['00947']FOEHKIENIPCJNPNFKGJNGEBHPGAA.pepper@ontopia.netDate: Sat, 31 Jul 2004 04:10:30 +0200%0aSubject: %5bsc34wg3%5d RM meeting in Paradise%0aMessage-ID: %3cFOEHKIENIPCJNPNFKGJNGEBHPGAA.pepper@ontopia.net%3e%0a%0aThe RM workshop will take place as planned starting%0atomorrow, Saturday July 31st on the 6th floor of the%0aHotel Europa at 9am.%0a%0aThe name of the meeting room is Paradiso. Don't forget%0ayour halos :-)%0a%0a--%0aSteve Pepper %3cpepper@ontopia.net%3e%0aConvenor, ISO/IEC JTC 1/SC 34/WG 3%0a%0a['0021450']['00954']['0020157']RM meeting in Paradise['00953']['00953']['0018664']['0018714']MDAEMON-F200406150813.AA1351239md50000043832@csw.co.ukDate: Tue, 15 Jun 2004 08:14:09 +0100%0aSubject: %5bsc34wg3%5d RM workshop: July 31-August 1%0aIn-Reply-To: %3c1087219981.16906.122.camel@localhost.localdomain%3e%0aMessage-ID: %3cMDAEMON-F200406150813.AA1351239md50000043832@csw.co.uk%3e%0a%0aMichel,%0a%0aI think that it is good to have 2 days set aside, and also to acknowledge%0athe possiblity that the work might be completed in one day. The criterion%0amust be consensus of those present, and I am confident that the level of%0atrust and collaboration that we achieved in Amsterdam will make it possible%0ato proceed relatively informally.%0a%0aAnn W.%0a%0a-----Original Message-----%0aFrom: sc34wg3-admin@isotopicmaps.org %5bmailto:sc34wg3-admin@isotopicmaps.org%5d%0aOn Behalf Of Michel Biezunski%0aSent: 14 June 2004 14:33%0aTo: sc34wg3@isotopicmaps.org%0aSubject: Re: %5bsc34wg3%5d RM workshop: July 31-August 1%0a%0aOn Mon, 2004-06-14 at 08:12, Steve Pepper wrote:%0a%3e This is to confirm that the Reference Model workshop will take place%0a%3e as originally planned in Montreal starting on July 31st.%0a%3e Whether it will be one or two days will be decided after the first%0a%3e day.%0a%0aWhat are the criteria that will be used to decide whether it's going to be a%0a1-day or 2-days workshop? Why can't we decide this in advance?%0a%0aI think it's important for those of us who plan to attend to make plans%0aaccordingly.%0a%0aMichel%0a%0a%0a%3e A meeting room is being arranged by Patrick in conjunction with%0a%3e IDEAlliance. We will let you know the exact location later. It is%0a%3e quite likely that it will be in the Hotel Europa (i.e. the same%0a%3e location as the Extreme Markup conference).%0a%3e%0a%3e Although the workshop is not a regular WG3 meeting, we encourage%0a%3e everyone to follow the usual rules for the submission of%0a%3e contributions, i.e. to make them available to National Bodies via the%0a%3e SC34 secretariat at least 4 weeks before the meeting.%0a%3e%0a%3e There are a number of interesting Topic Maps-related papers and%0a%3e tutorial being presented at the Extreme Markup conference that follows%0a%3e the RM Workshop, so we encourage delegates to stay on in Montreal for%0a%3e the conference. See%0a%3e http://www.extrememarkup.com/extreme/2004/schedule.asp for the%0a%3e conference program and hotel/venue details.%0a%3e%0a%3e Best regards,%0a%3e%0a%3e Steve%0a%3e%0a%3e --%0a%3e Steve Pepper %3cpepper@ontopia.net%3e%0a%3e Convenor, ISO/IEC JTC 1/SC 34/WG 3%0a%3e%0a%3e _______________________________________________%0a%3e sc34wg3 mailing list%0a%3e sc34wg3@isotopicmaps.org%0a%3e http://www.isotopicmaps.org/mailman/listinfo/sc34wg3%0a--%0a==================================%0aMichel Biezunski%0aCoolheads Consulting%0a402 85th Street #5C%0aBrooklyn NY 11209%0aEmail: mb@coolheads.com%0aWeb : http://www.coolheads.com%0aVoice: (718) 921-0901%0a==================================%0a%0a%0a_______________________________________________%0asc34wg3 mailing list%0asc34wg3@isotopicmaps.org%0ahttp://www.isotopicmaps.org/mailman/listinfo/sc34wg3%0a%0a%0a%0aFrom: sc34wg3@isotopicmaps.org (Steve Pepper)['0018714']['0021227']['0021088']['0020522']['00969']FOEHKIENIPCJNPNFKGJNGEKMNEAA.pepper@ontopia.netDate: Tue, 15 Jun 2004 19:22:22 +0200%0aSubject: %5bsc34wg3%5d RM workshop: July 31-August 1%0aIn-Reply-To: %3c1087219981.16906.122.camel@localhost.localdomain%3e%0aMessage-ID: %3cFOEHKIENIPCJNPNFKGJNGEKMNEAA.pepper@ontopia.net%3e%0a%0aHi Michel,%0a%0a| What are the criteria that will be used to decide whether%0a| it's going to be a 1-day or 2-days workshop? Why can't we%0a| decide this in advance?%0a%0aThe criteria will be whether we feel at the end of Day 1%0athat more useful progress can be made by continuing for%0aanother day. We can't really decide that in advance.%0a%0a| I think it's important for those of us who plan to attend%0a| to make plans accordingly.%0a%0aLike SRN said in Amsterdam: If it turns out that we have a%0afree day in Montreal on August 1st, who's going to complain?%0a%0aSeriously, though: Those that want to contribute to the%0aworkshop should aim to be present at 9am on Saturday July%0a31st and be prepared to spend two whole days getting the%0abest possible result. If we're going to come out of this%0awith something that is just about ready to go to CD ballot,%0awe'll need both days.%0a%0aSteve%0a%0a--%0aSteve Pepper %3cpepper@ontopia.net%3e%0aConvenor, ISO/IEC JTC 1/SC 34/WG 3%0a%0a['0018714']['0021450']['0021088']['0020522']['00975']['0019800']A393351AAE080640999E5935BCE9FDA102D3E292@exchange10.y12.do e.gov2003/09/03['0018770']['0018770']A393351AAE080640999E5935BCE9FDA102D3E2AD@exchange10.y12.doe.govDate: Tue, 2 Sep 2003 22:41:49 -0400%0aSubject: %5bsc34wg3%5d Heads up! SC36 Liaison coming%0aMessage-ID: %3cA393351AAE080640999E5935BCE9FDA102D3E2AD@exchange10.y12.doe.gov%3e%0a%0aIf Frank and I declare a liaison between our two SCs, I can appoint you or%0aanyone else an interim liaison representative (until we can get to a plenary%0ato make it official), and then you can show up at SC36 functions.%0a%0aThe details on the Singapore meeting are on the JTC1 Web Site, though your%0anational body probably also has them.%0a%0aJim%0a%0a-----Original Message-----%0aFrom: Mary Nishikawa %5bmailto:nisikawa@fuchinobe.oilfield.slb.com%5d%0aSent: Tuesday, September 02, 2003 8:01 PM%0aTo: sc34wg3@isotopicmaps.org; 'sc34wg3@isotopicmaps.org'%0aCc: komachi@y-adagio.com%0aSubject: Re: %5bsc34wg3%5d Heads up! SC36 Liaison coming%0a%0a%0aHi Jim,%0a%0a%3eI just had a conversation with Frank Farrance, Chairman of JTC1/SC36,%0a%3ewhich deals with applications of IT to education and training.. He's%0a%3ewildly enthusiastic about Topc Maps and wants to promote their use in the%0a%3eSC36 context; he wants to establish better liaison.%0a%3e%0a%3eHe plans to discuss this at the next SC36 meeting, at a conference in%0a%3eKorea, and at JTC1 (which meets in Singapore in November: anyone want to%0ago?).%0a%0aCan you send me the details of the Singapore meeting? I may be able to%0aattend. Lars Marius, Naito-san and I met with one of the Japan delegates%0aof SC 36 last year and at that time and she was also very much interested%0ain topic maps (I need to hunt down here name card). SC36 seems to be very%0aactive in Japan. I will see if I can attend one of the Japan sc36 meetings%0aas a guest.%0a%0aAs far as I can remember, they are working on standards such as SCORM for%0aonline training. They might be working on a controlled vocabulary for%0aeducational concepts.%0a%