head 1.8; access; symbols; locks; strict; comment @# @; 1.8 date 2007.03.06.17.30.00; author TWikiGuest; state Exp; branches; next 1.7; 1.7 date 2006.05.08.10.22.38; author GregorHagedorn; state Exp; branches; next 1.6; 1.6 date 2005.03.21.17.49.29; author GregorHagedorn; state Exp; branches; next 1.5; 1.5 date 2004.07.16.10.41.00; author GregorHagedorn; state Exp; branches; next 1.4; 1.4 date 2004.07.15.18.18.11; author GregorHagedorn; state Exp; branches; next 1.3; 1.3 date 2004.06.10.06.26.01; author GregorHagedorn; state Exp; branches; next 1.2; 1.2 date 2004.06.06.19.29.00; author GregorHagedorn; state Exp; branches; next 1.1; 1.1 date 2004.06.06.14.21.00; author GregorHagedorn; state Exp; branches; next ; desc @none @ 1.8 log @Added topic name via script @ text @---+!! %TOPIC% %META:TOPICINFO{author="GregorHagedorn" date="1147083758" format="1.1" version="1.7"}% %META:TOPICPARENT{name="ObsoleteTopicObsoleteTopicProxyDataModel"}% New resources: Relevant internet sources are: xNAL Name and Address Standard (xNL, xAL) (http://xml.coverpages.org/xnal.html) http://www.jabber.org/jeps/inbox/profile.html (version read was experimental, 2005-03-11) XML STANDARDS FOR "GLOBAL" CUSTOMER INFORMATION MANAGEMENT (http://www.oasis-open.org/committees/ciq/ciq.shtml) --- The agent proxy type in SDD was up to 0.9 simply a place holder, based on the proxy base type and extended only with exemplary elements to indicate the a specific extension would be desirable. However, we never invested real modeling effort into it. ABCD (ca. version 1.44) provides an elaborate and well thought out ContactType that has no support to link to external agent databases. Under the assumption that we will agree on a common data infrastructure, the ABCD.ContactType should be integrated with the general ObsoleteTopicObsoleteTopicProxyDataModel to form a revised AgentProxy type. I propose a model that is partly based on vCard 3.0 (http://www.ietf.org/rfc/rfc2426.txt). vCard does not provide for some extensions (we may have deceased agents where death date is relevant, the organisations have no abbreviations/acronyms, and the personal names have a strong American bias, that works well with many European cultures, but not necessarily internationally (a most interesting document in this respect is http://dublincore.org/documents/1998/02/03/name-representation/). Nevertheless, vCard seems to be a likely upcoming source for external Agent data. XML-vCard exists either in the variant used in the Jabber community, see http://www.jabber.org/jeps/jep-0054.html, or embedded in RDF, see e.g. http://www.xml.com/pub/a/2004/03/31/qa.html (note: the commercial GoldMine schema mentioned there is useless for our purposes). Another option may be the friend-of-a-friend projects (see http://rdfweb.org/topic/FAQ) which start to provide a standard-trail like document: http://xmlns.com/foaf/0.1/. FOAF is very semantic web and RDF-oriented. See also: "URLs for Telephone Calls. A. Vaha-Sipila, Internet RFC 2806 issued 2000-04" (http://www.ietf.org/rfc/rfc2806.txt) and "Markup Languages for Names and Addresses" (http://xml.coverpages.org/namesAndAddresses.html). Can anybody give advice on what to do here? The issue would be to define a moderately simple but expressive schema, that is relatively easy to implement for stand-alone use (i.e. in the absence of truly external Agent databases), but which allows to define interfaces where such external databases exist. -- [[Main.GregorHagedorn][Gregor Hagedorn]] - 06 Jun 2004 %META:TOPICMOVED{by="GregorHagedorn" date="1111427309" from="UBIF.ProxyDataAgent" to="UBIF.AgentDataModel"}% @ 1.7 log @none @ text @d1 2 @ 1.6 log @none @ text @d1 2 a2 2 %META:TOPICINFO{author="GregorHagedorn" date="1111427369" format="1.0" version="1.6"}% %META:TOPICPARENT{name="UBIF.ProxyDataModel"}% d14 1 a14 1 The agent proxy type in SDD was up to 0.9 simply a place holder, based on the proxy base type and extended only with exemplary elements to indicate the a specific extension would be desirable. However, we never invested real modeling effort into it. ABCD (ca. version 1.44) provides an elaborate and well thought out ContactType that has no support to link to external agent databases. Under the assumption that we will agree on a common data infrastructure, the ABCD.ContactType should be integrated with the general UBIF.ProxyDataModel to form a revised AgentProxy type. @ 1.5 log @none @ text @d1 1 a1 1 %META:TOPICINFO{author="GregorHagedorn" date="1089974460" format="1.0" version="1.5"}% d3 24 a26 12 The agent proxy type in SDD was up to 0.9 simply a place holder, based on the proxy base type and extended only with exemplary elements to indicate the a specific extension would be desirable. However, we never invested real modeling effort into it. ABCD (ca. version 1.44) provides an elaborate and well thought out ContactType that has no support to link to external agent databases. Under the assumption that we will agree on a common data infrastructure, the ABCD.ContactType should be integrated with the general UBIF.ProxyDataModel to form a revised AgentProxy type. I propose a model that is partly based on vCard 3.0 (http://www.ietf.org/rfc/rfc2426.txt). vCard does not provide for some extensions (we may have deceased agents where death date is relevant, the organisations have no abbreviations/acronyms, and the personal names have a strong American bias, that works well with many European cultures, but not necessarily internationally (a most interesting document in this respect is http://dublincore.org/documents/1998/02/03/name-representation/). Nevertheless, vCard seems to be a likely upcoming source for external Agent data. XML-vCard exists either in the variant used in the Jabber community, see http://www.jabber.org/jeps/jep-0054.html, or embedded in RDF, see e.g. http://www.xml.com/pub/a/2004/03/31/qa.html (note: the commercial GoldMine schema mentioned there is useless for our purposes). Another option may be the friend-of-a-friend projects (see http://rdfweb.org/topic/FAQ) which start to provide a standard-trail like document: http://xmlns.com/foaf/0.1/. FOAF is very semantic web and RDF-oriented. See also: "URLs for Telephone Calls. A. Vaha-Sipila, Internet RFC 2806 issued 2000-04" (http://www.ietf.org/rfc/rfc2806.txt) and "Markup Languages for Names and Addresses" (http://xml.coverpages.org/namesAndAddresses.html). Can anybody give advice on what to do here? The issue would be to define a moderately simple but expressive schema, that is relatively easy to implement for stand-alone use (i.e. in the absence of truly external Agent databases), but which allows to define interfaces where such external databases exist. -- [[Main.GregorHagedorn][Gregor Hagedorn]] - 06 Jun 2004 %META:TOPICMOVED{by="GregorHagedorn" date="1089974459" from="SDD.ProxyDataAgent" to="UBIF.ProxyDataAgent"}% @ 1.4 log @none @ text @d1 1 a1 1 %META:TOPICINFO{author="GregorHagedorn" date="1089915491" format="1.0" version="1.4"}% d14 1 a14 1 %META:TOPICMOVED{by="GregorHagedorn" date="1086848761" from="SDD.ProxyDataAgentProxy" to="SDD.ProxyDataAgent"}% @ 1.3 log @none @ text @d1 3 a3 3 %META:TOPICINFO{author="GregorHagedorn" date="1086848761" format="1.0" version="1.3"}% %META:TOPICPARENT{name="ProxyDataModel"}% The agent proxy type in SDD was up to 0.9 simply a place holder, based on the proxy base type and extended only with exemplary elements to indicate the a specific extension would be desirable. However, we never invested real modeling effort into it. ABCD (ca. version 1.44) provides an elaborate and well thought out ContactType that has no support to link to external agent databases. Under the assumption that we will agree on a common data infrastructure, the ABCD.ContactType should be integrated with the general ProxyDataModel to form a revised AgentProxy type. @ 1.2 log @none @ text @d1 1 a1 1 %META:TOPICINFO{author="GregorHagedorn" date="1086550140" format="1.0" version="1.2"}% d14 1 @ 1.1 log @none @ text @d1 1 a1 1 %META:TOPICINFO{author="GregorHagedorn" date="1086531660" format="1.0" version="1.1"}% d9 1 a9 1 See also: URLs for Telephone Calls. A. Vaha-Sipila, Internet RFC 2806 issued 2000-04, http://www.ietf.org/rfc/rfc2806.txt @