Re: rule proto-proposal

From: Stefan Decker (stefan@db.stanford.edu)
Date: 05/30/01


Pat,

At 11:00 AM 5/30/2001 -0500, you wrote:
>>Pat,
>>
>>At 07:51 PM 5/29/2001 -0500, pat hayes wrote:
>>>>Hi Pat,
>>>>
>>>>At 05:58 PM 5/29/2001 -0500, pat hayes wrote:
>>>>>>Hi,
>>>>>>
>>>>>>some additions to Pats suggestion:
>>>>>>
>>>>>>1) In many applications it is important to distinguish between 
>>>>>>different kind of RDF data, eg.
>>>>>>between different sources of RDF data, one is trustworthy, the other one
>>>>>>not.
>>>>>
>>>>>That seems to me to be an assertion about the source rather than the 
>>>>>data (?) But in any case it goes well beyond the RDF or DAML semantics.
>>>>
>>>>If we built a rule language for processing of RDF data it is necessary 
>>>>to distinguish
>>>>different sets of RDF data.
>>>
>>>Well OK, but I don't see why this topic comes up particularly when we 
>>>talk of rules. If you want to distinguish sets of RDF data, why not do 
>>>it in RDF? After all, RDF has the ability to describe its own 
>>>expressions, so this ought to fit into it naturally. Why not treat an 
>>>set of RDF data as something that is referrable to by a URI, ie a resource?
>>It is indeed possible, but very cumbersome. All implementations I am 
>>aware of have opted to represent
>>the context explicitly, rather than encoding it into RDF itself.
>
>Of course RDF is cumbersome, by its very nature. The RDF encoding of lists 
>that you invented for us is cumbersome; the use of reification for 
>encoding propositional structure is cumbersome; the encoding of any 
>relation with arity >2 is cumbersome. How can you be so enthusiastic about 
>the use of RDF in all its cumbersomeness for all that, and suddenly get 
>all concerned with memory counting when it comes to contexts? I do not 
>understand what your motivation is here.
>
>>But there are two different aspects: the query and rule language, and the 
>>actual representation in terms
>>of tuples.
>>For both I vote to make the context explicit:
>>the context of RDF data is necessary in almost all applications which 
>>take different sources into account, so
>>a rule and query language should have a convenient access to the context 
>>information.
>>
>>If not an explicit representation is chosen and reification is used to 
>>represent context, the
>>amount of storage necessary multiplies by 5 - which is not acceptable for 
>>large amounts of data.
>
>Why by 5? It seems only to add one extra triple per entry, which is a 
>multiple of 2 at worst.
4 for representing the reification, one for the isTrueInModel property. 
That means 5 triples instead of one.


>>>>One example where it is important to distinguish between
>>>>different kind of sets of RDF data is when it comes from different 
>>>>sources, and that
>>>>it originates from different sources is a property of the data.
>>>>There are other applications areas, e.g. the computation of different 
>>>>semantics (see my RDF Schema
>>>>example).
>>>
>>>We really must speak different languages.
>>>(1) To speak of "computing" semantics doesnt make sense to me; and (2) 
>>>why would we want to be using different semantics in any case? Isnt the 
>>>whole idea to have a single semantics?
>>f(1) E.g. Dix and Brewka in [1] define semantics  as follows:
>>
>>"A semantics SEM is a mapping from the class of all programs into the 
>>powerset of  the
>>set of all 3 valued  structured.  SEM assigns to every program P a set of 
>>3-valued models of P:
>>SEM(P) \subseteq MOD^LP_{3-val}(P)"
>>
>>My remark above is (admittedly loosely) based on this notion of semantics 
>>as the deductive closure.
>
>Oh, come on. This is a misreading of an idiosyncratic usage in a minor 
>subarea. I don't have the book in front of me, but from the quote they 
>seem to be making a distinction between the model and the deductive 
>closure in any case.

Taking only herbrand models into account (also common in the minor subarea) 
there is a direct correspondence
between the deductive closure of a logic program and models of that program.


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

>And in any case what does it mean to say that there will be multiple 
>languages "represented" in RDF? In the example in 
>http://www-db.stanford.edu/~melnik/rdf/uml/ , the RDF graph is being used 
>simply as a graph to encode a state diagram,
>in a way that completely ignores the RDF semantics (such as it is). If 
>that is 'representation', then RDF is just being used as a datastructuring 
>language.

If I store a statemachine in a database, do I ignore the logical semantics 
of a database?
Probably yes, but I can live with it and I guess other people can also.

And yes, RDF is a datastructuring language.


>Melnik seems to be almost proactive in ignoring meaning. He says in one 
>email (referred to in that paper):
>
>IMO people who are worried about "logical" consistency forget about the
>"crystal-palace" nature of the mathematics: the set theory is formalized
>using the predicate logic which relies upon the set theory. At some
>point, people as well as machines need a built-in understanding of a few
>basic concepts to communicate meaningfully. Mathematicians needed
>centuries to develop such a "built-in understanding". For machines,
>executable code can be a good approximation.
>
>There isn't space here to document all that is wrong with this, but let me 
>just say that one really shouldnt venture into philosophy of mathematics 
>until they know what they are talking about.

If you say so.
Nevertheless, the UML in RDF representation is useful.


>>Model identifier and skolem functions enable this.
>
>Skolem functions just create new names; they don't create new languages. 
>Model identifiers denote, you tell me, sets of RDF triples. But since, for 
>you, these are just triple-encodings of uninterpreted graphs, I fail to 
>see how they  can define a language either.

Skolem function are a way to create names for model and enable the 
computation of
parameterized models (sets of RDF statements).
E.g. "mod" names a set of RDF triples. "rdfschema(mod)" names the model 
that add all triples that
follow from the RDF schema rules (see the set of rules in my first mail).


>>>>>>This needs to be reflected in the rule language - it is not 
>>>>>>sufficient to just query if a certain
>>>>>>fact is present. To distinguish between different sources would be 
>>>>>>enabled by model identifiers
>>>>>>
>>>>>>subject[predicate->object]@model
>>>>>
>>>>>I have no idea what you are talking about. What is a 'model' in this 
>>>>>sense?
>>>>
>>>>A set of RDF statements (triples).
>>>
>>>Ah, I see. What is the difference between saying, in M, that 
>>>subject[predicate->object] is true, and saying that 
>>>subject[predicate->object]@M
>>Thats identical.
>
>Then I fail to see the utility of adding the '@M', since this information 
>is redundant.
You wrote " saying, in M, that subject[predicate->object] is true"
and subject[predicate->object]@M
Thats the same.
Expressing it in the rules language requires the @expression, since we 
distinguish different
sets of RDF statements inside the rules language. Thus it is not redundant.

Expressing it in the model M itself (which is written in RDF/XML syntax) 
does not require the
the @ expression.


>>>? Can I say subject[predicate->object]@M in N where N is different from M?
>>no.
>>(actually, I think we could if we define vocabulary representing the 
>>"true in a model"
>>property and use reification. There are reasons not to do this (see 
>>above). Would it be useful? )
>
>I have no idea; I was just probing to find out what the '@' notation meant.

OK.

Stefan


>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