- From: Patrick Stickler <patrick.stickler@nokia.com>
- Date: Thu, 22 Apr 2004 10:55:22 +0300
- To: "ext Phil Dawes" <pdawes@users.sourceforge.net>
- Cc: www-rdf-interest@w3.org, "Peter F. Patel-Schneider" <pfps@research.bell-labs.com>
On Apr 20, 2004, at 12:35, ext Phil Dawes wrote: >> However, I would consider it to be much more in line with the goals >> of the >> Semantic Web to instead have a document that explicitly points to >> these >> employee documents to establish the trust relationship. > > My experience has been that once you start writing SW applications, > the notion of 'document' becomes clumsy and doesn't provide much > value. For example, we have lots of RDF published in documents at > work, but typically applications don't go to these documents to get > this information - they query an RDF knowledge base (e.g. sesame) > which sucks data in from these documents. +10! The sooner we stop thinking in terms of documents, RDF/XML instances, etc. and start thinking in terms of graphs (however they might be serialized, defined, partitioned, managed) the sooner we'll start seeing scalable, global SW solutions. > >> Even better would be >> to have some mechanism to implicitly points to these employee >> documents, >> but I do not believe that there are currently any mechanisms in the >> Semantic Web for so doing. If you denote the employee with a URI that is meaningful to HTTP, the you could use MGET to obtain an authoritative description of that employee (presuming, of course, that the web authority was URIQA englightened...) Note that providing a formal, RDF description via MGET does not preclude or impact providing representations of the employee in traditional web fashion via GET, etc. Patrick -- Patrick Stickler Nokia, Finland patrick.stickler@nokia.com
Received on Thursday, 22 April 2004 03:58:36 UTC