- From: Joshua Allen <joshuaa@microsoft.com>
- Date: Sat, 21 Apr 2001 16:20:07 -0700
- To: "Ron Daniel" <rdaniel@interwoven.com>, "Danny Ayers" <danny@panlanka.net>, "Brian McBride" <bwm@hplb.hpl.hp.com>
- Cc: "RDFInterest" <www-rdf-interest@w3.org>
> 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. Right, metadata can be stored, indexed, and used in many ways, RDF is simply a way to make the metadata interoperable. As you point out: > 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 Yeah, I think that is the point -- metadata like "author" you probably want to be able to ship around with a document; if you want those 10,000 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. > > 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. What about a server-side include? This problem sounds to me to be very similar to the idea of someone wanting to include a copyright statement at the bottom of every page without having to update and maintain every page. If you have a more sophisticated content-management system like Interwoven, this can be automatic, but a low-tech way is to manually create the author statements and <!-- #include file="author_a_fragment.rdf" --> (or something like that). I think that solutions like this or the database ideas proposed are good in the short-term, because the RDF received by the client is then fairly simple (IOW, these solutions do not require the clients to understand things like multiple inheritance, do not require dereferencing of extra resources, etc.) > 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. s/RDF/anything
Received on Saturday, 21 April 2001 20:59:01 UTC