RE: Common Metadata (was:RE: RDF in XHTML)

<- Terminology -- you have to download it to read it.  Browsing a page
<- implies downloading it.  Having a machine "read" it implies downloading
<- it.

Terminology indeed - to me download means making a copy rather than
accessing/viewing. In context the difference makes sense - if you've found
what you're looking for, you don't need the metadata any more.


<- Because HTML META tags aren't RDF.  Having part of the RDF come from a
<- database or #include on the server-side does not in any way change or
<- "hack" the RDF that the client sees.  Neither solution requires RDF to
<- change, and both accomplish what you seem to want, which is easier
<- manageability of oft-used bits of metadata.  Or putting it another way;
<- if most people are comfortable grabbing bits of oft-used markup through
<- #include or a database, it seems a bit harsh for one person to ask for a
<- complex change to the base spec just so they can do it "yet another
<- way".  And it is a bad solution because it pushes off what is
<- essentially a server-side information management problem and forces it
<- to become the problem of each and every client.

I was suggestesting that we try and reduce problems

<- (FWIW, I'm not arguing against *links* as such, but pointing out that
<- linking is often a bad solution for a piece of markup that appears in
<- many documents.

ok...

For example, suppose that you make a special file just
<- for "author_1", "author_2", etc.  Now you link to "author_1" or
<- "author_2" and expect the client to retrieve that additional information
<- [else if you do it on the server you are completely reinventing
<- #include].  So the client now has to issue *two* gets against your
<- server instead of one, and you still send up the same amount of data.

I'm sorry, you've lost me a bit there

<- One argument in favor of this that I *could* buy is if you felt that
<- each author_x RDF snippet was going to be very large and requested
<- multiple times by a single client, and you could count on the client to
<- use some caching policy [and trust it not to return stale data].  In
<- general I think it's a rather risky game to try to outsmart web site and
<- ISP caches by using links, though.)

I'm trying to suggest something really simple here - if we'va whole section
of the library that is about 'natural history', do we need 'natural history'
stamped on every book?

I've been talked out of it being a being a fundamental requirement - it
looks like a quantification problem, so let the logic folks sort it on top.

Received on Sunday, 22 April 2001 07:31:30 UTC