Re: Upcoming wave of quad/namedgraph implementations ,was: Reification - whats best practice?

Andrew Newman wrote:

> Hamish Harvey wrote:
> > Andrew Newman wrote:
> >
> >> The main problem we've had with named graphs is that it can be a pain
> >> on a machine that has multiple names or names that change over time.
> >> If I create a models based on machine names called
> >> "http://192.168.10.1/foo" and then move to another network and
> >> suddenly it's "http://10.0.0.42/foo" then all my existing queries stop
> >> working.  I now prefer URNs for models not URIs and add a level of
> >> indirection between them (I think this has been mentioned before).
> >
>
> Ideally, you would have an infrastructure that would allow indirection
> of models like DNS does with names to IP addresses.  It can be more than
> DNS though, you could change what's resolved based on a user's
> credentials, for example.  The security credentials, the protocol, the
> host name/IP, query string or any part of the URI should be separate
> from the name of the graph.  I don't think you should change your
> configuration/code/queries just because any of these details change.
> Semantically it's the same data.
>

The Peer-to-Peer research community has been working in this subject. E.g. the problem is
solved in the SUN's  JXTA P2P Framework:
"...
The Project JXTA addressing model is based on an uniform and location independent logical
addressing model.
Every network resource (peer, pipe, data, peergroup, etc.) is assigned a unique JXTA ID.
JXTA IDs are abstract
objects enabling multiple ID representations (IPv6, MAC) to coexist within the same JXTA
network. The reference
implementation is using 128-bit random UUIDs allowing each peer to self-generate its own
IDs. A peer in
the JXTA network is uniquely identified by its peer ID allowing the peer to be addressed
independently of its
physical address  For instance, a laptop booting via DHCP, and therefore having many
different IP
addresses overtime, will always have the same peer ID. Similarly, a peer supporting multiple
network interfaces
(Ethernet, Wi-Fi, etc.) will be addressed as a single peer independently on the interface
used. The peer ID
abstraction allows a peer to encapsulate not just physical transports, but also “logical”
transport protocols such
as HTTP or TLS. JXTA logical addressing model introduces a fundamental indirection
separating the identification
of a resource and the location of a resource allowing a variety of virtual mappings to be
used to determine
the physical location of a resource.
...."

See also page 2 at : http://www.jxta.org/project/www/docs/JXTA2.0protocols1.pdf

Alex
___________________________________________________________
  Alexander Löser
  Technische Universitaet Berlin
  hp: http://cis.cs.tu-berlin.de/~aloeser/
  office: +49- 30-314-25551
  fax   : +49- 30-314-21601
___________________________________________________________

Received on Monday, 13 September 2004 15:59:27 UTC