Re: spruced up definitions

Bijan Parsia wrote:
> 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.
> 

If we go down the entailment route, we will need to choose which kind of 
entailment because we need to define concrete test cases.

Anything more complicated needs space to mature and will have to be left to 
"DAWG II".

We are heading (rapidly?) to last call.  It woudl help me if this thread of 
discussion turned into one or more concrete examples of what capabilities we are
enabling in the query language.  It would help me - but also it has to turn into 
examples in rq23 as well definitions.

Sorry to be processy but the timescales are short :-)

	Andy

Received on Wednesday, 25 May 2005 16:09:26 UTC