Re: rule proto-proposal

From: Stefan Decker (
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 sloppiness.
>>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 
>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.  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

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

>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 
and still have declarative processing power.

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.

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



>>An example: look at
>>These people are building an Ontology for representing business processes.
>>This incorporates states, events, dynamics etc.
>>Are you saying they are not allowed to express these concepts in an 
>>ontology language
>Of course not
>>express it in RDF? (Actually, they use XML Schema).
>Sure, though I think their chances of being able to do so in RDF are 
>remote. [Added later: did you really mean *express* it in RDF? Or did you 
>mean encode the datastructures of the ontology language in RDF? Of course 
>they can do the latter, but that's not what I would call expressing the 
>ontology in RDF.]
>But look: there is a distinction between building an ontology in an 
>ontology langauge, and constructing datastructures in a datastructure 
>language. In the first case the language has a semantics; in the second 
>case, it does not (or at any rate, if it does, it is a semantics about 
>datastructures, not about the concepts in the ontology.)
>>>>And yes, RDF is a datastructuring language.
>>>Well, Stefan, that is not what the rest of the RDF community seem to be 
>>>saying. I wish y'all would get your act together and come out with a 
>>>single consistent story. If RDF is just a datastructuring language, then 
>>>what has it got to do with the Semantic Web? And what advantages does it 
>>>have over LISP (say), or XML ?
>>It as consistent as every community where different people with different 
>>opinions and different
>>background try to work together.
>That says nothing about the utility of RDF over XML (or LISP, for that 
>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