Re: spruced up definitions

>On May 24, 2005, at 11:07 AM, Pat Hayes wrote:
>
>>>Thanks for the comments and rewokred definitions.
>>>
>>>I'll process them, send you an updated set of definitions as well 
>>>as send any
>>>questions I have.
>>>
>>>One question for now - if we go with "subgraph", is there any reason why the
>>>predicate should not be a blank node?
>>
>>In the pattern, you mean? I guess not, though if we allow this then 
>>we might want to draw reader attention to the non-RDF-ish nature of 
>>those patterns,
>
>They are already a bit non-RDF-ish (literals in subject positions)

But that is just correcting a silly design error in RDF. This is rather more.

>, but further highlighting is always good. (Pink highlighting, preferably.)

I like crawling acid-green bugs around a box flashing between yellow 
and violet, myself. It has a Mardi Gras feel.

>>and that they amount to asking "does a predicate exist such that...".
>
>Well, if you interpret them that way :) I presume you don't intend 
>to interpret that  second orderly.

First orderly, as in common logic. But still its asking about the 
existence of a predicate. And I meant 'predicate' in the RDF sense, 
bear in mind.

>As I've said, I've a bit of pechant for interpreting them metalinguistically.

Comes to the same thing since the CL universe of predicates only has 
named predicates in it.

>>  That is, any answer binding must instantiate the bnode to a 
>>URIref. Or, of course, we could just prohibit them :-)
>>
>>BTW, I don't see that this is affected by the subgraph/entailment 
>>decision. Am I missing something?
>
>If we allow bnodes in predicate positions, and want to use the 
>"natural data" entailment to define queries (i.e., a query is true 
>of a kb just in case the kb entails the query

But queries have variables in them. You have to extend entailment to 
the variables. When you do, there won't be any semantic difference 
between a variable and a bnode in a query. So, if you can put a 
variable in that position then you can put a bnode there, seems to 
me. A bnode in a query is just a blank variable.

Or, you can say that an instance of the query is entailed: but then 
the instantiation is enough to get rid of the bnodes.

(Or, hmm, are you thinking that instantiation replaces the variables 
but inference handles the bnodes ?? That would be a new way to think 
for me.)

>, where the entailment function depends on the expressiviity of the 
>KB. So, if the kb is RDF, query success is defined in terms of rdf 
>entailment. But then no query pattern with bnodes in predicate 
>positions will hit (at least, not without some extension).
>
>hence my preference for treating predicate query variables as 
>metalinguistic. Then such queries are actually query schemas which 
>get expanded into a disjunction of the queries formed by 
>instantiated all the predicate query variables with the permutations 
>of properties in the kbs. (It needn't be actually a disjunction, 
>natch, it could just be a set, and then if any element of the set is 
>rdf entailed, the query succeeds).

Right, I think it would be a mistake to involve disjunction. I kind 
of like this metalinguistic idea myself, but I don't see any clear 
distinction between metalinguistic instantiation and just 
instantiation. They both amount to replacing a variable/bnode with a 
term, which itself might be a variable/bnode. The only difference 
between a bnode type variable and a different type variable is the 
way they are allowed to appear in RDF graphs, which seems to me is 
just a typographical convention.

>My main concern, of course, is make SPARQL relatively neutral for 
>kbs expressed in RDF through OWL.

I agree with you there.

Pat
-- 
---------------------------------------------------------------------
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 Tuesday, 24 May 2005 15:57:45 UTC