Re: spruced up definitions

On May 24, 2005, at 11:58 AM, Pat Hayes wrote:

>> 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.

Sure.

>> , 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.

I'm down with that.

>>> 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.

Will this interpretation fly with OWL-DL?

>> 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's fine.

>>>  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.

Yes, of course. Well, not if you do my query expansion trick. Then you 
just reuse the old entailment relations. It's mostly a matter style. 
People seem reluctant to define an extended entailment relation.

> When you do, there won't be any semantic difference between a variable 
> and a bnode in a query.

Of course. In fact, I would just think of query variables as a kind of 
bnode with a particular spelling.

> 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.

Yep.

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

Yep.

> (Or, hmm, are you thinking that instantiation replaces the variables 
> but inference handles the bnodes ??

Yes. (I think.) They sort of amount to the same thing in RDF (slightly 
extended). Not in OWL, I think.

> That would be a new way to think for me.)

How pleasant for you!

>> , 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.

Really? Why so. I'm not convinced either way. The main advantage of 
avoiding disjunction is that in expressive kbs we can make the result 
set the union of results of the "disjuncts", whereas if we use 
disjunction per se we might get more. I think the two converge in RDF 
and RDFS due to the absence of disjunctive information in the KB.

>  I kind of like this metalinguistic idea myself, but I don't see any 
> clear distinction between metalinguistic instantiation and just 
> instantiation.

For me, metalinguistic instantiation doesn't involve the entailment 
relation which I think simplifies the presenation and is more neutral 
wrt kb languages.

> They both amount to replacing a variable/bnode with a term,

True. But there is a difference between how that replacement is 
justified. Again, there maybe convergence, but I think having to 
augment the entailment relation for each KB is a PITA.

>  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.

As I said before, I'm perfectly happy to interpret bnodes in predicate 
positions as we find convenient. I don't think any particular reading 
is forced on us, especially if the readings converge.

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

Can we talk about this at some point? My contention to Andy at WWW was 
that the non-entailment talk wasn't actually neutral (hence the desire 
for entailment talk). But entailment talk means using the existing 
definitions of entailment or defining extended versions. There is 
resistance to the latter approach. Of course, if CL formalizes all that 
straightforwardly enough, we could use that. *However*, then we would 
be introducing a dependancy on a non-W3C document and ignoring some 
obvious connections to existing W3C documents. (IOW, I think a CL based 
explication is fine as a non-normative appendix or note, but a bit 
tricky as part of the mainline, normative definitions).

Cheers,
Bijan.

Received on Tuesday, 24 May 2005 16:18:05 UTC