Recommendations for serving backlinks when having hash URIs?

Dear all,

  are there any guidelines on how to reasonably restrict the number of served
RDF triples when

* the linked data served should also include backlinks (i.e. triples that have
  the requested resource as object), as is good practice
* hash URIs are used (and therefore a server response contains a lot more than
  what the client actually needs)
?

In our setting, we are bound to use hash URIs for certain resources, as the
URI syntax conventions have existed before the age of linked data.  Suppose we
have resources with URIs like fooX#barY, such as foo23#bar57.  Suppose that
the RDF on the server is not served from static files fooX.rdf, but from a
triple store, and thus the server has some flexibility w.r.t. what exactly to
serve.  Now suppose a client is interested in foo27#bar4 and therefore (hash
URIs!) has to request foo27 from the server.  Then, the server would at least
have to return a lot of triples having any of the foo27#barY as subject, e.g.

foo27#bar1 :someprop foo27#bar56 .
foo27#bar2 :someprop foo33#bar1 .
foo27#bar4 :someprop foo66#bar89 .

Additionally we would like to get some triples having foo27#barY as an object,
but again the server does not know that the client is only interested in
foo27#bar4.

Of course any reasonable approach to pick the most "relevant" triples depends
on the specific vocabulary and application, but still, are there any
guidelines?  Or should we rather consider ways of mapping hash URIs to slash
URIs?  Are there standard approaches?  I could imagine that e.g. for foo27 the
server could return only these triples:

foo27#bar1 owl:sameAs slashland/foo27/bar1 .
foo27#bar2 owl:sameAs slashland/foo27/bar2 .
...

and that then the client would issue a second request to "slashland", where a
reasonable response of links and relevant backlinks could be computed more
easily.

Cheers, and thanks in advance for any help,

Christoph

-- 
Christoph Lange, Jacobs Univ. Bremen, http://kwarc.info/clange, Skype duke4701