RE: i0001: EPRs as identifiers - alternative proposal

Like +44 123 123 123#3456 3456 3456 3456?

Dave

> -----Original Message-----
> From: paul.downey@bt.com [mailto:paul.downey@bt.com]
> Sent: Friday, December 03, 2004 12:39 PM
> To: Savas.Parastatidis@newcastle.ac.uk; David Orchard
> Cc: public-ws-addressing@w3.org
> Subject: RE: i0001: EPRs as identifiers - alternative proposal
> 
> > 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.
> 
> Paul
> 
> 
> 	-----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
> 	#s
> 	> 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.
> 	It
> 	> 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
> 	be
> 	> 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,
> 	.savas.
> 
>

Received on Friday, 3 December 2004 20:55:40 UTC