Re: One semi-historical point (was Re: ISSUE: DISTINCT is underspecified)

>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