Re: Conceptual, Logical, and Physical views of data

Marshall Spight wrote:
> dawn wrote:
> > > ...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.
>
> Consider: if you know *only* a person's SSN, do you know anything
> about the person? Yes! You know their SSN. If you picked that
> person's records up out of the system they're currently in
> and moved them to another completely different server, maybe
> even change from SQL to, uh, flat files, would the SSN change?
> No! It's the same, regardless of the medium.

lightbulb went off both with this and when you explained what you meant with * and & (since I have "used" or at least read them in C++, but was just cloning and modifying so I didn't understand the regerencing/dereferencing, but it is becoming clearer).

> Let's say that the HTML document in question contains the
> exact same information about the person as the relational
> records. Now let's say you know *only* the URL of that
> document. Do you know anything about the person? Not a bit.

yes, yes, but to me that is like you saying "if you just know the data source or host/port/schema name plus table name and generated key to a row, you don't know anything about the person". So, would a site-gen'd key value be analogous to a URL then? Would it be a pointer, where an SSN would not be?

> Let's say you pick that HTML doc up and move it to a
> different server, would the URL change? You bet it would.

Not if I keep the same URL. The URL is not tied to a server, although it is easier if you keep it on a server with the same domain name, otherwise you need to do some fancy footword to keep the old URL as a "synonym." I haven't done that myself, but my understanding is that is possible.

This is somewhat similar to moving data to a new base table at which point you can point your view to the new base table, but if you were working directly against the base table (and how many sites only write apps against views and never base tables?) you would have to make a change because that table name served as a "pointer" to the data (like the URL).

> See the difference?

Yes, I think so. Does it make sense to you that the URL has characteristics of the datasource(namespace) > table which is also a "location" identifier?

>
> > > 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?
>
> YES!
>
>
> > > 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]
>
> I like the classic "a database is a collection of facts" and
> the classic "dbms handles structure, integrity, and manipulation."
> A document can certainly be a fact or a collection of facts.
> But I note that HTML and HTTP have little in the way of facilities
> for formal structure (it's pretty much semantic-free markup)
> and exactly nothing in the way of integrity and manipulation.

agreed. --dawn
>
> Marshall
Received on Sun Sep 11 2005 - 21:20:31 CEST