Re: Conceptual, Logical, and Physical views of data

<big snip>
> > > > Other than specifying a data source, what would be an
> > > > example of addressing data by location?
> > >
> > > The "*" operator in C. A Url. Bulk mail addressed to "occupant." :-)
> >
> > I don't yet see how a URL is more of a pointer than a foreign key. It
> > is an identifier. You can use it to "go to" another source of data
> > just as you can use a foreign key to "go to" another source of data.
> > It doesn't even point to a machine, even if it resolves to know what
> > machine to go to. My foreign key used in a join statement knows that
> > too.
>
> We already discussed this to death. :-(

I know and I apologize for not yet understanding. This pointer issue seems one of the big motivators for relational theory, so I want to "get it". I understand why this was problematic when related to memory locations, but I don't understand the big downside of using logical pointers, reference values, foreign keys -- what's the difference?

>
> > > > Do you consider a base table name to be a location?
> > >
> > > No, because table names are semantic. Pointers are not semantic.
> >
> > If we use a URL as the value of a foreign key to a base table from
> > which we can gen the html, then the URL would not be a pointer, right?
>
> Right.
>
>
> > So, it seems like it is the distributed nature of this vast database
> > called "the web" that makes you think that the URL is a pointer.
>
> Nope. Distributedness has nothing to do with it. It has to do with
> the nature of the *operator* you apply to get the results. With a Url,
> let's call that operator GET. Can you do anything with GET besides
> give it a Url and get back HTML? No; so it's a pointer; it exists
> only in the context of a dereference operator. Without GET, the Url
> is useless; it doesn't tell you anything.

I suspect I'm just not thinking clearly, because I don't see the difference between that and a social security number for a person. The SSN tells me nothing without the operations to retrieve the person who has been assigned that SSN. Apologies again Marshall that I'm being dense. I really want to see what you are seeing with this one.

> Now, if you could supply GET with some attributes of the document
> itself, that would be different. Let's say you could say:
>
> GET title like "foo"
>
> and get back all the documents on the web that had "foo" in the title.

Like google, but with attribute names instead of all data being identified in the value of the document, such as could be the case if the html were xhtml and a query language were employed?

> Anyway, you're totally going down the wrong path with your focus
> on the web-as-database, anyway.

I didn't call it a dbms. Do you want to toss out your def of "database" so that the web doesn't conform, or of "attribute" so that a document cannot be the value of one? [she asks, goading him]

> The web is a document
> storage-and-retrieval system; as a database it's totally
> crippled. It has no semantic controls, schema, manipulation
> routines, nothing.

so far

> Great for finding reading material, though.

I don't have a need to argue this one, because when some business databases that would otherwise have been implemented using SQL-based tools are implemented using web technology (prettey much, but with additions) then we can talk about it again. I'm tempted to write something like that myself right now. Later. --dawn

>
> Marshall
Received on Sat Sep 10 2005 - 23:54:40 CEST