- From: Ron Daniel <rdaniel@interwoven.com>
- Date: Sat, 21 Apr 2001 15:08:27 -0700
- To: "Danny Ayers" <danny@panlanka.net>, "Brian McBride" <bwm@hplb.hpl.hp.com>
- Cc: "RDFInterest" <www-rdf-interest@w3.org>
Danny Ayres said: > Let me suggest another scenario - I have 10000 documents on cheesemaking, > 5000 of these are by the same author, 5000 by another, half of > the documents > are from one publisher half from another (not along author lines or > anything). You will surely agree that this metadata doesn't represent much > information. Ok, perhaps I could dynamically generate metadata, perhaps I > could hack XSLT to do what I wanted. Or of course I could repeat the same > information 10000 times inline with all the documents. OK, so I am clear on the documents, authorship, and publisher. But I don't have any feeling for what it is that you want to actually DO. What are you trying to do with those documents and metadata? What problem are you trying to solve? A very common problem is to search a collection of documents by author and publisher. In that case, why not have a RDBMS that gets loaded up with author, title, and publisher info? That is not RDF, but the point is to solve problems, not exercise technologies gratuitously. Another scenario might be that you want to provide those 10k documents to someone else. In that case, you might send the documents and an RDF description of each (generating the RDF descriptions out of the database mentioned above). The receiver can then parse the descriptions and import their content into their own database. Wasteful of bytes being transferred? Yes. Simple to implement and understand? Yes. So, unless I am working on a problem where the cost of transferring bytes is higher than the cost of programming, I'd do it the simple way. > The model for what's ideally needed is multiple inheritance, or at least > something approaching this. "Needed" to do what? It sounds to me like you want to be able to describe things using the minimum number of statements. That is a fine thing to want to do, but it seems like a "nice to have" rather than a "must have" for any applications that I am currently looking at. The hardest part about RDF is clearly identifying the problem you want to solve, and distinguishing it from related problems that you don't need to solve. RDF is a means to an end, not an end in itself. Regards, Ron Daniel Jr. Standards Architect Tel: +1 415 778 3113 Fax: +1 415 778 3131 Email: rdaniel@interwoven.com Visit www.interwoven.com Moving Business to the Web
Received on Saturday, 21 April 2001 18:09:46 UTC