190 lines
8.2 KiB
Plaintext
190 lines
8.2 KiB
Plaintext
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 <nop>ContactType that has no support to link to external agent databases. Under the assumption that we will agree on a common data infrastructure, the <nop>ABCD.ContactType should be integrated with the general ObsoleteTopicObsoleteTopicProxyDataModel to form a revised <nop>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 <nop>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 <nop>ContactType that has no support to link to external agent databases. Under the assumption that we will agree on a common data infrastructure, the <nop>ABCD.ContactType should be integrated with the general UBIF.ProxyDataModel to form a revised <nop>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 <nop>ContactType that has no support to link to external agent databases. Under the assumption that we will agree on a common data infrastructure, the <nop>ABCD.ContactType should be integrated with the general UBIF.ProxyDataModel to form a revised <nop>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 <nop>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 <nop>ContactType that has no support to link to external agent databases. Under the assumption that we will agree on a common data infrastructure, the <nop>ABCD.ContactType should be integrated with the general ProxyDataModel to form a revised <nop>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
|
|
@
|