Re: Identity modelling

Marshall Spight wrote:
> dawn wrote:
> > Marshall Spight wrote:
> > > > I think your use of "pointer" here is very extreme
> > >
> > > I'm okay with that. :-)
> >
> > Good. I myself shy away from such extremes ;-)
>
> "...moderation in the pursuit of justice is no virtue!"
>
> But mostly what I meant was that I was okay that you considered
> it extreme. I am trying to highlight the significance of
> content based addressing. It's not just another kind of pointer.
> It's different.

So if an instance cannot exist without a value for the identifier, then it is a key, otherwise a value that uniquely identifies it would be a pointer -- is that close?

>
> > > > There is nothing hidden or behind the scenes about a URL.
> > > > One issue I see is that you opted to talk about
> > > > modeling the html file, rather than all of the data under
> > > > consideration.
> > >
> > > I don't understand this statement. Did I say it needed to be hidden?
> >
> > No, I was still referring to lines between what is a pointer and what
> > is not. A value that is entered by humans routinely is not a likely
> > candidate to be termed a "pointer" unless every value that points is a
> > pointer.
>
> What is a pointer if not a thing that points?

We have had discussions about the term "pointer" before. I was told that when looking at the issues that relational theory was addressing, the term "pointer" there is used to refer to memory addresses IIRC, which is the only way that concern made sense to me anyway. So, I changed my use of the term "pointer" to align with that, rather than using it as a term for a thing that points.

> I agree that a human entered value is unlikely to be a hardware
> memory address, but I'm not sure of the relevance.

Does the above clarify?

>
> > > > So, perhaps if you add in the URL to the data you are
> > > > modeling, you will agree that it is, indeed, a key?
> > >
> > > Yes: if the URL was *in* the html, and we accessed it by
> > > looking for an html document with a specified URL, then it
> > > would be a key.
> >
> > Would you be OK with saying that the URL is a key TO the full web page,
> > while not being a key OF the html page?
>
> What you're calling a "key TO" is a location, an address, a pointer.

As a Uniform Resource Identifier, a Uniform Resource Locator is also a logical identifier. Of course this highly distributed data repository (the www) implementation does navigate to a page by way of this key value and a single html page can be arrived at via more than one URL, so I'm not so sure that the URL is the key to an html document, but a URI is a key to a web resource.

>
> > It sounds like you would be OK
> > with that iff we defined the full web page to include both the URL and
> > the html
>
> That's necessary but not sufficient.
>
> > (not typically how "web page" is used).
>
> Yes, because the web doesn't used content-addressable storage.
> Yes, because URLs are pointers.

Are they pointers with the same meaning used by Codd in his earlier treatments of relational theory? (I'm not looking it up now, so perhaps it is, but that was not my impression)

>
> > When working with key-value pairs, it is common to say that the key is
> > a key to that value. Why would we want to redefine that term to make
> > that inaccurate?
>
> We're not doing that. The key is part of the map. Check out, for
> example, java.util.Map.Entry.
>

OK. The term gets used both ways.

> > Maybe we should just say that the URL is a key, but not a relational
> > key to the web page?
>
> You are of course free to call it that. I'm going to call it a pointer
> to the web page.

I was happy calling foreign keys pointers until I was corrected on that, but perhaps this will give me more clues to what can be called a pointer. I figured a foreign key was a pointer because it was not part of the entity to which it was pointing. Does that work with your definition? Thanks. --dawn

>
> Marshall
Received on Thu Sep 01 2005 - 06:19:19 CEST