thoughts and some refs about AFS-2 UC

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