RE: Objective 4.6 -- additional semantic information

RobS wrote:
>> It's getting late here, but I'll dump my case
>> I've done a test with the given kb
>>   :a :b :c.
>>   :d :e :f.
>> 
>> and a test with the given kb
>>   :a :b :c.
>> 
>> and a test with the given kb.
>>   :d :e :f.
>> 
>> and a test with the given kb which is empty
>
> Okay; so this is an example of doing disjunction in a query, and NOT an
> example of supplementing an RDF graph with addtional semantic knowledge.

indeed

> (Such an example is relevent to my complaint about "subgraph results",
> but I don't see it as relevent to objective 4.6.)

aha, hadn't checked the subject line..., right.

>> That are all RDF graphs.
>> 
>> The query is implemented with the --filter
>> option of cwm and euler, which is an RDF formula
>>   {:a :b :c} => {:yes :for <>}.
>>   {:d :e :f} => {:yes :for <>}.
>> but haven't yet thought about other designs...
>
> You still haven't explicitly said what the user's query is; I'm assuming
> it's just a plain "is either of these two specified triples in the
> graph?"

that's right indeed and there could be a language
design for that

>> The answer is definitely an RDF graph like
>>   :yes     :for <testC.n3> .
>> (where testC.n3 is actually that filter file)
>> or the empty graph for the fourth test.
>> 
>> I fail to see the harm in doing
>> "encoding the answer within the query"...
>
> I am quite happy that disjunction seems to be handled by this "filter"
> functionality (since all we really need in this case is a "union"). But
> you skipped a very big step here: the user had a query, and you encoded
> it in a clever form that happens to get the right answer. Further, your
> result is a triple in a form the user has never seen before, and you
> have to marshal that back to something they might understand. The fact
> that your answer of "true" comes back as an RDF triple that you have
> added to the graph using some hand-written code for this query is
> entirely beside the point; its RDF-ness doesn't help a bit.

I agree that that --filter formula is not the query itself.
The reason for --filter is that it is suitable for backward
and forward chaining, such as in the case where the filter is
Query implies Query.
Loosely worded, the user is getting back answers matching
the conclusions of the implications in the filter, and so
there is a connection between what he asked and what he is
getting back. 

-- 
Jos De Roo, AGFA http://www.agfa.com/w3c/jdroo/

Received on Wednesday, 9 June 2004 17:22:16 UTC