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