- From: Alberto Reggiori <alberto@asemantics.com>
- Date: Thu, 18 Mar 2004 17:30:04 +0100
- To: RDF Data Access Working Group <public-rdf-dawg@w3.org>
After RDF DAWG telecon 17 March I got an action: ACTION AlbertoS: elaborate on AFS-2 "Tell me about ..." http://lists.w3.org/Archives/Public/public-rdf-dawg/2004JanMar/0022.html --- I personally found AFS-2 UC [1] very much appealing due it touches one important and generic aspect of a Web query-language/protocol: information discovery. Similarly, other use-cases cover this aspect too e.g. PS-1, PS-2, DB-1 et al. The reason I see behind this is very clear - once you have generated data/metadata in some RDF format and you published it to some URI, how are the others going to find out about it? Which properties are linked to this URI/node? Or how can I find more triples (metadata) about a certain URI I am responsible for or describing? How a crawler/robot is going to find which "links" it has to follow and collect/harvest? How a Web browser/application is going to follow URI-ed hyperlinks? And so on... All these questions need first to answer to a more generic question "where do I find information/metadata about a given URI/resource?". This UC also relates to several other query aspects such as optional properties (where property may or may not be supplied), provenance/attributions (who said so?) [2][3], how to follow links between RDF objects [4] and more generic "reference-by-description" [5] negotiations. The Joseki RDF Net API/protocol natively supports a method "fetch object" [6][7] to gather "everything known about a certain URI", URIQA [8] has a similar MGET method as well as TAP GetData interface [9]. Other system are adopting similar solutions and protocols [10]. The neat effect of those is that, by simply asking a generic/atomic question about a certain URI to a certain trusted source/node, a client gets returned all relevant triples (Concise Bounded Description (CBD) [11] ) about the URI; and then it can "boot up" (discover/negotiate) knowledge about that URI. And in a second time then, the client might ask more specific questions/queries to the service or post-process the CBD. This could also be used to overcome to the optional properties aspect/problem [12]. To tackle the provenance aspect/problem instead, I would expect such systems to explicitly flag/annotate their CBDs with some authoritative information about the source providing the the answer. Even so, it is not clear to me how today solutions like Joseki/URIQA solves this problem though. Any thoughts about this? I would like to hear your feelings/opinions about the relevance of this UC and if you feel it crucial for the future of our work. Alberto [1] http://lists.w3.org/Archives/Public/public-rdf-dawg/2004JanMar/ 0022.html [2] http://www.w3.org/2001/12/attributions/ [3] http://sunsite.informatik.rwth-aachen.de/Publications/CEUR-WS/Vol-89/ macgregor-et-al.pdf [4] http://www.hpl.hp.com/techreports/2002/HPL-2002-315.pdf [5] http://tap.stanford.edu/tap/rbd.html [6] http://www.joseki.org/RDF_data_objects.html [7] http://lists.w3.org/Archives/Public/www-rdf-dspace/2003Jun/0047.html [8] http://sw.nokia.com/uriqa/URIQA.html [9] http://tap.stanford.edu/tap/getdata.html [10] http://lists.w3.org/Archives/Public/www-rdf-interest/2004Mar/0019.html [11] http://sw.nokia.com/uriqa/URIQA.html#cbd [12] http://groups.yahoo.com/group/jena-dev/message/3151
Received on Thursday, 18 March 2004 11:30:09 UTC