- From: Pat Hayes <phayes@ihmc.us>
- Date: Fri, 18 Aug 2006 19:11:49 -0700
- To: Bijan Parsia <bparsia@cs.man.ac.uk>
- Cc: RDF Data Access Working Group <public-rdf-dawg@w3.org>
>On Aug 17, 2006, at 8:34 AM, Pat Hayes wrote: >[snip] > >>Well, this is an aside to our main discussion here, but I think >>that it would be quite acceptable to have an RDF query standard >>which was defined *entirely* syntactically, and simply treated an >>RDF graph as a triple store, and used essentially algebraic >>operations to troll through it for patterns that match and satisfy >>superficial conditions (which might include semantic conditions if >>those can be computed locally, eg typed literal values). This was >>basically the design we had originally, about which so many >>protests were received wanting a more 'semantic' account. > >I think is a point of misunderstanding. If y'all said, "We're >defining the Query Of RDF Syntax (QORS) language, and if you want to >do simple, or rdf, or rdfs, with or without D, or even OWL, well, >you're out of luck, make a new standard and you might consider >borrowing our query language syntax" I would not have objected. But I don't think you *are* out of luck for RDF/S/D. OWL... well yes, OWL is more complicated because it has disjunctions in it. >Or at least not in the same way. I'm fine without a unitary semantic >framework per se. Just let me *say* in my own way, what the >semantics are (ok, some framework would be nice, just to make them >easier to read; but I'm fine with an outlier), and give me good >hooks to indicate when I'm using it (and the hooks should be in the >query language please; not all sparql query is across the web in any >interesting way). > >What I objected to was 1) a syntactic reading that in no way tied to >the RDF Semantics document It was tied to it, in the sense that the subgraph/match design corresponds directly to simple entailment. And the entailment lemmas then give you at least a spec for RDF and RDFS, if not a very good implementation strategy off the cuff, as it were. I agree, the XSD case needs more work. >, and 2) the claim that this would require no change in order to >work for simple, rdf, rdfs, and even OWL queries. I hope nobody made that last claim about OWL. I certainly did not. >This is manifestly not true. There are people in the working group >who support RDFS, and at the very least you have to say something >about contradictory documents. True, but you can follow what the RDF semantics document says, which refers to the concept of 'datatype clash'. The point being that quite a lot of this was already worked out in the RDF WG and is documented (with some known bugs, which are now fixed by others), and we *could* have simply directly used this stuff, with minimal change. But it wouldn't extend this simply to OWL-DL, indeed. >Even if you go with maximal consistent subsets, that still needs to >be said, explained, etc. True, true, there is work to be done. But it still would make for a much easier basic design (and one which is tied closely to the extant implementations) and a much simpler description. Issues of how to describe binding restrictions are much simpler when the notion of pattern matching is built into the primary definitions, for example. >So my problem then is the same as my problem now: Lots of things are >unspecified or underspecified. Some of the offered ways of >specifying just would work very well if at all. > >>> And I think we should make the semantics available. (Now, of >>>course, we're disagreeing on what the semantics require. Let me >>>weaken my principle to say that it should help people understand >>>the semantics of the graph.) >> >>OK, Im quite happy with that reading. But I still think that its >>important to not suppress answers which can be used to extract >>*semantically* distinct information entailed by the graph. I guess >>my point is that it is the semantics of the *graph*, not of the >>*answers*, that likely matter most to a querying agent. > >Well, we disagree. Or at least, I think focusing the semantics of >the answers are: > 1) important > 2) reasonable > 3) easier to specify, understand, and implement > >This doesn't mean I feel a need to kick yours out, but if there's >only one, yeah, this is the one I'll support. Fair enough that we disagree. However, I stick to my point. IMO, the answers are primarily a way to extract information from the graph. It's the graph that is being queried. Pat > >Cheers, >Bijan. -- --------------------------------------------------------------------- IHMC (850)434 8903 or (650)494 3973 home 40 South Alcaniz St. (850)202 4416 office Pensacola (850)202 4440 fax FL 32502 (850)291 0667 cell phayesAT-SIGNihmc.us http://www.ihmc.us/users/phayes
Received on Saturday, 19 August 2006 02:12:17 UTC