Re: rule proto-proposal

From: pat hayes (
Date: 05/31/01

>At 07:29 PM 5/30/2001 -0500, pat hayes wrote:
>>>>>>>(2) A single semantics for one kind of language. We will have 
>>>>>>>multiple languages represented in RDF, e.g.
>>>>>>>UML (see  ) and it 
>>>>>>>would be nice if the rule language we
>>>>>>>design is able to deal with multiple languages at the same time.
>>>>>>Again, I have no idea what you mean. How can *a* (note 
>>>>>>singular) rule language deal with multiple languages? ("Deal 
>>>>>>with" in what sense? )
>>>>>Be able to compute the deductive closure of a single set of RDF 
>>>>>statements with respect to a set of rules.
>>>>Stefan, according to you there is no such thing as the deductive 
>>>>closure of a set of RDF statements. You have said earlier in this 
>>>>thread that RDF triples have no logical interpretation, and in 
>>>>this message you say that RDF is a datastructuring language. 
>>>>Concepts like 'deductive closure' only apply to languages with a 
>>>>proof theory. What are the inference rules of RDF?
>>>I meant the deductive closure of the Facts + Rules. Sorry for the 
>>>RDF does not have inference rules, in the same way that a set of tuples has
>>>no inference rules. Together with a rule language (e.g. SQL) I 
>>>might have inference
>>Maybe we are still not following one another. As I understand your 
>>position, the rules themselves do not have a semantics (right?). So 
>>they are not *inference* rules, and it still seems to me not to 
>>make sense to speak of a deductive closure. In fact, if the RDF 
>>triples don't have a semantics (ie if RDF is a datastructuring 
>>language) then the triples are not even properly called 'facts'. A 
>>triple without any meaning assigned to it is just a datastructure, 
>>not a fact. It might be intended to represent a fact, or a picture, 
>>or a diagram, or a mathematical expression, or just about anything, 
>>or even nothing. Without a semantics, there is no way to tell.
>The same is true for a database.
>A tupel in a database may contain picture, or a diagram, or a 
>mathematical expression, or just about anything, or even nothing.
>Still it makes sense to treat a tuple in a logical way.

Im afraid I disagree. In fact, this remark sounds to me to simply be 
nonsensical. What do you mean by 'treating a tuple in a logical way' 
if the tuple has no known relationship to any kind of logical meaning?

> Even it we regard RDF as "just" a datastructuring language
>it makes sense to process the data in a declarative way using rules 
>- for an example see
>Correspondence and Translation for Heterogeneous Data, Serge 
>Abiteboul, Sophie Cluet, Tova Milo, ICDT,1997

I will read this and get back to you.

>>No, of course, but that is a different issue. You didn't say that 
>>you were storing *data about* a statemachine; you said you were 
>>storing the statemachine. That is what Melnik is doing, seems to 
>>me: he is using the 'data' not as data at all, but as an encoding 
>>for something entirely different. Now, one can do that, of course. 
>>You CAN use predicate logic syntax to encode musical notation (use 
>>depth of function nesting for pitch, the constant at the bottom of 
>>the term for length of note, and clause ordering to indicate 
>>time-sequence) but if you do that, then you have no legitimate 
>>complaint if a Prolog interpreter fails to handle key shifts, say. 
>>The Prolog isnt meant to be used that way, and that way of using 
>>the notation does not conform to its declared semantics.
>Prolog is a general purpose programming language (that's at least 
>what the prolog vendors say).

Of course it is. So what? General-purpose programming languages still 
may have intended meanings and a clear semantics.

>And I used prolog for large programming projects and can't complain.
>And all prologs I used are able to handle key shifts - otherwise 
>prolog would not be usable for programing tasks.

I meant musical key shifts, as for example when transposing from C to 
B flat. I think you would have trouble doing that in Prolog with the 
musical notation I sketched above.

>>Similarly, if you take a relational assertion language and use it 
>>to encode finite-state transition diagrams, then you cannot 
>>complain if the rule processor fails to conform to the conventions 
>>of your idiosyncratic usage; and, more to the present point, the 
>>designer of the rule language is not obliged to consider such 
>>idiosyncratic uses. If people want to write arbitrary encodings 
>>with perfect freedom, then they should be writing code, not putting 
>>data  into datbases; and they can't expect to get interoperability.
>The point is exactly allowing arbitrary encodings on a higher level 
>of abstraction
>and still have declarative processing power.

I don't think that makes sense, but in any case that is not what I am 
trying to do, or think that DAML should be trying to do.

>However, can be go back to the topic of designing a useful rule language?
>It seems to me that the difference between:
>  1) "RDF is a datastructuing language and tripels should not be 
>interpreted as facts" and
>  2) "RDF tripels are facts"
>is more than esoteric. It seems obvious that triples can be regarded 
>as atoms in a logical language,
>at least if I not misunderstood your proposal (see 
>that was also your suggestion.

They can be, indeed, and I would like to continue to so regard them. 
However, to my mind that it is incompatible with denying that they 
have a semantics, or trying to write rules that ignore the semantics. 
I still cannot understand quite how you manage to reconcile these 

>Can we please focus more on designing a useful rule language?

We got into this discussion because with our different notions of 
what a rule language is, we seem to have different notions of what 
'useful' means. I emphatically do not see DAML rules as intended to 
provide arbitrary open-ended programming functionality.


IHMC					(850)434 8903   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola,  FL 32501			(850)202 4440   fax

This archive was generated by hypermail 2.1.4 : 04/02/02 EST