This not a use case where SPARQL shines. Although SPARQL uses graphs as a metaphor, it is not really ideal for implementing classical graph algorithms.
In some cases, it may be easiest to implement things using multiple, iterative queries.
In other cases, it may be easier to use SPARQL to construct a subgraph containing the relevant individuals and property assertions, then uses that as input to one of the usual algorithms.
Note that the problem of finding all paths between two nodes is NP-hard , so reducing the number of nodes that need to be considered is a good thing. You may want to instead look for the top k shortest paths - the results of the ESWC 2016 challenge on this topic are now available ; unfortunately the papers aren't currently self-archived or open access.
Depending on the implementation of the triple store, and the structure of the graph, it may be feasible to find all the triples involved in some path between a and b by looking for every c such that a owl:topObjectProperty+ ?c and ?c owl:topObjectProperty+ b.
It is also possible that this kind of query may cause the server to melt, or your DBA to tie you to a chair and do evil things with UPS parts.
Some systems provide extensions that make implementing such algorithms easier- for example AllegroGraph has non-standard support for first class paths.