- From: Bijan Parsia <bparsia@isr.umd.edu>
- Date: Mon, 7 Mar 2005 15:30:01 -0500
- To: kendall@monkeyfist.com
- Cc: DAWG Mailing List <public-rdf-dawg@w3.org>
On Mar 7, 2005, at 1:47 PM, Kendall Clark wrote: > On Mon, Mar 07, 2005 at 10:55:45AM -0500, Bijan Parsia wrote: > >> If the action was to show the feasibility, then it is completed. > > I think I understand what you've done. But my only concerns are > > 1. Jos's case of being able to say that a graph is closed over an > arbitrary (?) set of rules They just need an URI denoting them as an individual. That could be a member of the class Expressivity. > 2. the point that Bijan raises in a later message; that, for > example, a graph may be closed over only the "interesting" subset > of, say, RDFS entailments... Maybe there's not a real need to be > able to say something this specific in the service description, > but I can imagine a client taking "RDFS closure" in a strong way, > querying for some triple that's inferred by one of the RDFS > entailment rules that a particular graph *doesn't* implement... [snip] Well, I was thinking more of this. Suppose I am 3Store and I always aggressively do RDFS closure. I can't *not* query the RDFS closure. Suppose I am am Sesame, which can turn off RDFS closure, but have it on too. These seem interestingly distinct. Now suppose there is a graph whose RDF and RDFS closure is identical (are there any? hmm. I'll have to check). Then, these stores would return the same hits. So it seems a little odd to say that 3Store *doesn't* do RDF closure. It doesn't *filter out* RDFS (only) entailments. I'm not sure it matters, but it did occur to me. In a class representation of expressivity, you might want RDFExpr to be a subclass of RDFSExpr and so on. But that wouldn't mean you could do *only* rdf expr if you did RDFSExpr. Cheers, Bijan.
Received on Monday, 7 March 2005 20:30:02 UTC