From: pat hayes (phayes@ai.uwf.edu)
Date: 05/31/01
>Pat,
>
>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 http://www-db.stanford.edu/~melnik/rdf/uml/ ) 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 inference
>>>rules.
>>
>>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
>ftp://ftp.inria.fr/INRIA/Projects/verso/VersoReport-102.ps.gz
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
>http://www.daml.org/listarchive/joint-committee/0436.html)
>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
positions.
>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.
Pat
---------------------------------------------------------------------
IHMC (850)434 8903 home
40 South Alcaniz St. (850)202 4416 office
Pensacola, FL 32501 (850)202 4440 fax
phayes@ai.uwf.edu
http://www.coginst.uwf.edu/~phayes
This archive was generated by hypermail 2.1.4 : 04/02/02 EST