- From: Joshua Allen <joshuaa@microsoft.com>
- Date: Sun, 22 Apr 2001 00:14:58 -0700
- To: "Danny Ayers" <danny@panlanka.net>, "RDFInterest" <www-rdf-interest@w3.org>
> <- 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