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

> <- different documents to be published on your website, where
10,000,000
> <- people may download documents and want to know who the author is,
> <- embedding the metadata in the page is nice.
> 
> Why are you talking of shipping documents around? The documents are
surely
> there to be read, not for copies to be downloaded - the publishing
model
> is different when you have connectivity.

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

> <- What about a server-side include?  This problem sounds to me to be
very
> <- create the author statements and <!-- #include
> <- file="author_a_fragment.rdf" --> (or something like that).
> 
> Why is everyone so keen to hack? RDF is a tool at the early stages of
its
> development. If there are things it needs to do that aren't possible
with
> the current version [*] then now is the time to add the capabilities.

How is that a hack?  Maybe we are talking different things -- you want
an oft-used piece of RDF to be included with all pages of a certain
group without having to maintain each page individually, right?  That is
what #include is meant to do.

> <- (IOW, these solutions do not require the clients to understand
things
> <- like multiple inheritance, do not require dereferencing of extra
> <- resources, etc.)
> 
> If we want it simple, why not just use HTML meta tags? But why should
the

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.

(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.  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.
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.)

Received on Sunday, 22 April 2001 03:15:34 UTC