- From: Danny Ayers <danny@panlanka.net>
- Date: Sun, 22 Apr 2001 17:27:50 +0600
- To: "RDFInterest" <www-rdf-interest@w3.org>
<- 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