Some obvious URI patterns for a service?

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?