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 17:22:28 UTC