Re: ACTION Bijan: to work on "closeOver" work-alike with

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.