W3C home > Mailing lists > Public > public-ws-addressing@w3.org > December 2004

RE: i0001: EPRs as identifiers - alternative proposal

From: <paul.downey@bt.com>
Date: Fri, 3 Dec 2004 20:39:01 -0000
Message-ID: <2B7789AAED12954AAD214AEAC13ACCEF2709DDF8@i2km02-ukbr.domain1.systemhost.net>
To: <Savas.Parastatidis@newcastle.ac.uk>, <dorchard@bea.com>
Cc: <public-ws-addressing@w3.org>
> tel:+44 123 123 123 123 ext: 3456 3456 3456 3456
fwiw call centres do just this - the telno is a 'virtual' number which may be
switched across suppliers (~ DNS name) and the first thing they do 
is get you to key in your account no followed by the 'square sign' to 
route your call to an appropriate operator + shave valuable seconds 
from their script. i'm sure if they could squash the account no into 
the published telno, they would.

	-----Original Message----- 
	From: Savas Parastatidis [mailto:Savas.Parastatidis@newcastle.ac.uk] 
	Sent: Fri 03/12/2004 17:19 
	To: David Orchard; Downey,PS,Paul,XSJ67A C 
	Cc: public-ws-addressing@w3.org 
	Subject: RE: i0001: EPRs as identifiers - alternative proposal

	> +1.  URIs have infinite scale, see cantor's theorem.
	> The reason banks don't give out phone #s per person is because phone
	> are not extensible as the phone system understands a finite length.
	> There's a fascinating discussion we could have about the benefits that
	> the phone system accrues by having mandatory fixed length (shades of
	> mandatory action).
	> The reason for having RefPs has nothing to do with URI extensibility.
	> has everything to do with configurability particularly having soap
	> specific software handle the RefP rather than URI software.
	> I have no problem talking about architecture, but we have to at least
	> able to distinguish between scalability and extensibility.
	I respectfully continue to disagree... A banking service could provide,
	if they wanted, "addresses" to individuals' bank accounts in the form of
	telephone numbers... For example:
	"Call this number:
	tel:+44 123 123 123 123 ext: 3456 3456 3456 3456
	and you'll get access to your bank account. As far as you are concerned,
	that's your opaque bank account number". Isn't that an equivalent of a
	URI? Then, when a banking service decides that they want to provide
	freephone service to their customer, they change their telephone. All
	the bank account numbers are now invalidated.
	And, yes, banks don't do this. Why? Because they don't want to couple
	the access mechanism (the telephone) with the identifier of the bank
	account. Instead, they give us an abstract identifier (the bank account
	number) which is completely decoupled with the way in which we can
	access the details of and perform operations on it.
	Yes, I know that URIs don't necessarily imply a communication mechanism.
	But that's how they are usually used. Do
	ftp://ftp.example.org/resource/1 and http://www.example.org/resource/1

	identify the same entity? The lsid:authority-name:bla:bla:resource:1 is
	unique though but doesn't convey any information about how the resource
	is accessed.
	Do you want to make EPRs identifiers that also convey addressing
	information? To my mind, that would be the wrong thing to do.
	In the real world, the banking services say... call this number tel:+44
	123 123 123 123 and once you start interacting with the service you can
	use the identifier of your bank account to do what you want (e.g., an
	automated system asks you to type it or you tell it to the person at the
	other end). The same account number will be used even when the banking
	service will change.
	I am all in favour of URIs as identifiers (e.g., a URI of the form
	bank:Barclays:account:3456345634563456) but I see a difference between
	an identifier and an address.
	I personally see the real world using addresses that are decoupled from
	the identifiers of the entities about which conversations take place.
	The entities are identified in the payload of our business interactions
	and are not part of the addresses.
	Best regards,

Received on Friday, 3 December 2004 20:38:19 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:04:07 UTC