Whilst the technical issues and backends may vary, there are one or two URI patterns that may be adopted I think. It’s not REST, but it is a sensible structure I hope. (This is not to replace voID, but to accompany a voID description and other characterisation methods)
http://host/#catalog – URI for the catalog dataset
http://host/void
302 – conneg response to a voID description at .ttl, .rdf (xml), etc
http://host/describe/{uri} –
200 – responds with a conneg’d graph with the information a store ‘knows’ about a given URI. The HTML representation would likely be viewed as a ‘record’ page, insofar as this is valid for the item. (uses Content-Location: http://host/describe/{uri}/ttl etc rather than 302, due to load and network traffic cost.)
404 – doesn’t know about this uri
http://host/types
200 – voID-like Response based on the canned query ‘SELECT DISTINCT ?x WHERE {?foo rdf:type ?x)’ BUT with the addition of some lowest common denominator types. Can be easily cached. Filtering out the least important types is at the discretion of the service – this is not intended to be a complete set, but to publish the set of types that this service cares most about. Best shown by example (note that some predicates need to be minted/swapped for suitable ones. Shown by *):
<http://host/#catalog> a void:Dataset ; *containsType* <myOnto:Researcher> ; *containsType* <myOnto:foo> ; etc... void:uriLookupEndpoint <http://host/describe/> ; etc... <myOnto:Researcher> <owl:subclassOf> <foaf:Person> ; <myOnto:foo> <owl:subclassOf> <bibo:Article> ;
Thoughts?
Hi Ben
Pete Johnston from the LOCAH project has recently posted on URI patterns. Any crossover/ possibilities for alignment here?
Adrian
JiscEXPO Synthesis Liaison
… I meant to put the link of course
http://blogs.ukoln.ac.uk/locah/2010/11/16/identifying-the-things-uri-patterns-for-the-hub-linked-data/