- From: Steve Harris <S.W.Harris@ecs.soton.ac.uk>
- Date: Thu, 29 Sep 2005 20:22:53 +0100
- To: RDF Data Access Working Group <public-rdf-dawg@w3.org>
On Thu, Sep 29, 2005 at 08:57:02 -0400, Bijan Parsia wrote:
> >I'm absolutly not qualified to talk about the logical issues here, but
> >from a practical point of view, both as a user and developer its very
> >useful to be able to distinguish a graph as fetched from the web and
> >any
> >entailments from it.
>
> I agree....but I don't know if you agree with how this affects the
> protocol design. I have a preference for "one graph/dataset; several
> parameters" requestable by the client and controlled by the server.
> This is in part because I think there is a strong natural bias in
> documents toward a particular entailment relation based on their
> logical vocabulary (e.g., if you use rdf:subClassOf, the natural thing
> to do is publish it "under" RDFS entailment). Using other modes
> (including told-bnode redundancy) seem to be special (and useful)
> deviations (e.g., when you are interested in the syntax of the graph
> rather than strictly its informational content; or if the server can't
> handle that level of entailment in sufficient time, etc.).
>
> This means that this information has to be recoverable somehow. E.g., I
> suspect that there should be a metadata field in the results format
> where I can stuff such information (perhaps this only matters in the
> SOAP binding where the initiator of the request and the receiver of the
> results might be very different; but then we have soap headers to help
> out...)
>
> I like to minimize the number of exchanges necessary to achieve
> reasonably common effects.
Sure but, my preferred design is to do this in the query language (the
distinctions between what ended up in the query language and what in the
protocol seems somewhat arbitrary to me).
In 3store you can do something like
SELECT ?x ?y ?z WHERE {
?g :dependsOn <graph.rdf>
GRAPH ?g { ?x ?y ?z }
}
Which will return all the triples that are entailed from graph.rdf*
I'm not arguing for this as any kind of standard, but it seems like the
sort of thing that might emerge as consensus. I guess the usability of
this depends on how much interop. you want on day 0.
* actually it wont right now, because :dependsOn is not transitive yet.
Also, I'm sure theres a better name for :dependsOn, I looked in the log:
namespace but couldn't find anything that seemed like an exact match.
> Also, I don't *mind* having URIs for all these things so long as their
> are reasonably "generatable", e.g., like the various XPointer schemes
> floating about. Just having bare, coined uris and having to do a
> whoooooole lotta discovery sees rather burdensome.
Yes, agreed.
> >Pre-SPARQL versions of 3store did not seperate them (as far as the user
> >could tell), and it caused confusion.
>
> Now it does? Excellent!
In a shocking move you can even turn off inference alltogether now ;)
- Steve
Received on Thursday, 29 September 2005 19:23:11 UTC