- From: Steve Harris <steve.harris@garlik.com>
- Date: Wed, 30 Sep 2009 20:41:22 +0100
- To: Birte Glimm <birte.glimm@comlab.ox.ac.uk>
- Cc: "public-rdf-dawg@w3.org Group" <public-rdf-dawg@w3.org>
On 30 Sep 2009, at 18:56, Birte Glimm wrote: > 2009/9/30 Steve Harris <steve.harris@garlik.com>: >> I've skimmed the document, and I have some questions and comments. >> >> 1) I'm sure sure how the scoping graph and active graph related to >> the rest >> of the document. Linking to the definitions in SPARQL 1.0 might be >> more >> helpful. I don't find the related section in SPARQL 1.0 especially >> clear >> either, but it's trying to talk in very general terms. > > I'll add links to the according section in the SPARQL 1.0 spec. > >> 2) Where it says "Systems who want to support... can state..." is >> that >> intended to be a requirement for the service description section, >> or is >> state meant in an informal sense? > > Any suggestion whether it should be or not? So far Bijan and I started > by looking at RDFS and RDF and it seems that one can use the same > conditions to meet the requirements that entailment regimes have to > satisfy, so we didn't want to have two more or less duplicate > sections, one for RDF and one for RDFS. We might even use the same > conditions for D-entailment, if it seems they fit well. Now that > obviously does not mean that RDF (and maybe D-entailment) cannot or > should not be proper entailment regimes. It would be a possibility > though. I not much of an opiniomn about it ad I am happy about any > opinions or advice. So far it is more undecided and the sentence > should be rephrased once we know better what we want. I have a preference for it being described. In the simplest case, the regimes could be assigned URIs and given as features in the service description. >> 3) In the section on RDFS, I share Andy's concerns. My systems >> wouldn't have >> been able to detect the inconsistent case with acceptable >> efficiency either. > > Ok, we'll work on alternatives/changes. I'll add a note on that now > and we'll see how we can solve this soonish. Great. I used the past tense deliberatly there though, I no longer maintain any inferencing systems, so other peoples opinions will be more relevant. >> General notes: >> >> It's not clear to me how the terms used 1) relate to the ground >> data. I'm >> not really familiar with the mechanics of typical OWL reasoners, so >> it could >> be obvious to practitioners. > > Hm, here I don't know where you are referring to. Is 1) just a one > with no two or is that referring to the scoping graph above, in which > case I am not sure how that relates to ground data. Are you looking at > the (unfinished) OWL section or are you thinking of OWL implementors > as implementors for the RDFS entailment regime? The latter, and yes I was wondering how the scoping graph stuff relates to the actual triples/quads in the store. >> Is the implication that inference only happens within a (named) >> graph? > > Good point. I have to check on that and see whether this is clear from > the SPARQL 1.0 spec or whether we have to specify something for that > in the ent. regimes. The notion of named or default graph is not used > in the OWL context. I have never seen it in the RDF(S) spec either > (maybe I forget), so if the SPARQL spec does not say anything, then we > have to address that I guess. Any clues? RDF doesn't ever mention graphs, the spec ignores what happens if you have more than one graph. My suspicion is that to be useful for large datasets the inferencing has to span multiple graphs. That's far from the only usecase of course, but Garlik only really cares about large datasets :) An example is where you have lots of data with different origins, and a separate graph with the schema/ontology in it. That seemed to be the common case when I worked with RDFS inferencing. - Steve -- Steve Harris Garlik Limited, 2 Sheen Road, Richmond, TW9 1AE, UK +44(0)20 8973 2465 http://www.garlik.com/ Registered in England and Wales 535 7233 VAT # 849 0517 11 Registered office: Thames House, Portsmouth Road, Esher, Surrey, KT10 9AD
Received on Wednesday, 30 September 2009 19:41:53 UTC