RE: Objective 4.6 -- additional semantic information

Rob - I've been suspecting you and I have been misunderstanding one 
another on this, now I'm sure of it.  Not quite sure where we're off, 
so let me ask two questions
   1 -  in your opinion, what does objective 4.6 add -- that is, if we 
accomplished this objective what would be in the language that isn't 
there in the design that doesn't include it?  Are you implying below 
that if we don't reach the objective it will be "wrong" for a query 
of an RDFS store to return the ?x = c answer below?
  2 - .  The UC&R doesn't have any use case that seems to really 
motivate disjunctive queries and the charter says that the 
expressivity (using disjunct as an example) will be determined by use 
cases.  In my experience most query languages don't actually handle 
disjunctive queries very well (SQL, for example, only allows the OR 
in the conditional of a return, which is a very limited kind of OR). 
I think the reason for this is that a lot of the complex border cases 
seem to arise around disjunctive queries (as in the case below) - so 
my question is really whether you see this as a trade-off, or if you 
take it as a given that a good DA rec would include" (a R b) OR (c S 
d)" and thus worry about a lot of these complex cases?
  thanks
  JH
p.s. if either of the above sound hostile or argumentative, please 
don't take them that way -- I haven't been privy to the discussions 
of the group to date, and am trying to catch up - I'm trying to read 
the message log, but there's too much to simply read end to end, so 
i'm trying to catch up on the most relevant threads, and thus may 
have missed things where the above were discussed.


At 8:47 -0700 6/9/04, Rob Shearer wrote:
>>  Maybe I didn't understand what 4.6 was about, I assumed it was
>>  something like this:
>>
>>  if I have
>>     a rdfs:subClassOf b
>>     b rdfs:subClassOf c
>>
>>  then I was assuming that the requirments in UC&R would imply that if
>>  I query for
>>     a rdfs:subClassOf ?x
>>  then ?x would be bound to b
>>  however, if we include 4.6, then we would be expected to return
>>     ?x = b and ?x = c
>
>I think it would be wrong to require implementations to return both 'b'
>and 'c', because that would be *requiring* implementations to process
>RDFS.
>But I think it would also be wrong to forbid returning 'b' and 'c' from
>queries against some larger knowledgebase. In this case the problem is
>hard to produce, since most (every?) extra piece of RDFS can simply be
>encoded as a whole bunch of extra triples in an RDF graph, but that's
>not the case for all extra sources of knowledge.
>
>For example, if the standard were to define disjunction such that the
>predicate "(a R b) OR (c S d)" is defined to return 'true' if and only
>if "a R b" returns 'true' or "c S d" returns 'true', then it's
>impossible for a standards-compliant processor to return sensible
>results in a situation where the disjunction is a logical consequence of
>the knowledgebase, yet neither of the individual triples is.
>
>If, however, the standard were written in terms of the semantics of the
>graphs which match such a disjunctive predicate, then more advanced
>processors could legally return results that actually represented all
>the knowledge at their disposal.
>
>This is the difference between specifying the semantics of the query
>language and specifying its implementation.

-- 
Professor James Hendler			  http://www.cs.umd.edu/users/hendler
Director, Semantic Web and Agent Technologies	  301-405-2696
Maryland Information and Network Dynamics Lab.	  301-405-6707 (Fax)
Univ of Maryland, College Park, MD 20742	  240-277-3388 (Cell)

Received on Wednesday, 9 June 2004 18:11:30 UTC