URIs and cell IDs (was: Implementing ZigZag)

["B. Fallenstein" <b.fallenstein@xxxxxx>]

Hi Tuukka, Jan, all!

Tuukka Hastrup wrote:
> 
> We have the cell identity as a
> String though, because what good is something else?

In general, I think this is most useful for virtual structures. For
example, if you have a virtual structure representing a database, and a
cell in there represents one database entry, then it would be sensible
to have the identity of that cell be the database entry object.
Otherwise, you'd have to map the identity string to the database entry
and vice versa every time you request information about the virtual
structure (such as: which cell is next to this one?).

> The semantics can
> matter, yes, like having it interpreted as an URI, or a Mediaserver
> Globally Unique ID as it's in GZigZag at the moment. I'd say you'll want
> to think about IDs a lot, because that's a very powerful and complex
> matter.

I don't think leaving the semantics of the ID open really works if we
want to have interoperability. As I said earlier, I propose that all
ZigZag implementations agree to have URIs as cell and dimension
identifiers; this does not mean that they have to use URIs internally,
but they need to be able to map their cell identities to URIs and vice
versa. All implementations agreeing on this is the whole idea of the
proposal to use URIs.

The point here is non-conflicting use of cells and dimensions across
implementations. This is even more important with dimensions than with
cells, but I think the issue is there with cells, too. My earlier
argument for this can be accessed at
http://www.xanadu.com.au/mail/zzdev/msg01379.html (as well as Ted's
two-line reply).

Basically, no matter which implementation an arbitrary space comes from,
we want to be able to generate a 'canonicalized' representation in any
other implementation. This means that if we import the same space into
the other implementation twice, we want to get the same result. What
MUST NOT happen is that different dimension names are assigned to the
same dimension, because then we would not be able to write conversion
code to convert the internals of the source implementation to the
internals of the target representation, as we wouldn't even know which
dimensions were which ones (and thus have no clue what connections along
these dimensions mean).

One argument for the cell IDs as URIs is similar, though not as strong:
Cells which have special meaning in the source implementation should be
always mapped to the same ID in the target implementation, so that
autoconvert tools can recognize them by looking at the ID. More
important is that we want to be able to use cells as identifiers for
dimensions; now if we refer to dimensions as URIs, we have to be able to
map the cells to URIs as well (so that they can refer to the dimensions)
and a natural way of doing that is by having the cell IDs be URIs.

The general point is that it would be good if cell identifiers, as well
as dimension identifiers, would be globally unique and consistent across
ZigZag implementations. Using an ad-hoc scheme like GZigZag does
currently is of course possible, but it would be hard to agree on, it'd
mean people would have to learn a new scheme, and it'd also means
foolishly ignoring a relevant and useful Internet Standard (well, I
think it's a Draft Standard currently).

Besides, there are nice interoperability effects to be gained from this:
it would be possible to talk about ZigZag cells e.g. in RDF triples and
other 'net formats, and in ZigZag we could easily talk about resources
denoted by URIs created outside ZigZag, as cells. When ZZ gets more
popular and people want it to interoperate it with other things on the
net, this could prove very helpful; for example, it would be easy to
export in-ZigZag logical statements to RDF without losing identity
information, or a network printer or an XML namespace, etc. could be
represented as a cell in ZigZag, and connected to other cells-- anything
that can be refered to by an URI.

(Of course, this benefit can also be gained by one implementation using
URIs as cell IDs in isolation, but it's not the only reason, but just
one that supports the real argument of interoperation between ZigZag implementations.)

I would appreciate if we could get into a real discussion of this
proposal, and make a decision about it.

- Benja