From: Tanel Tammet <tammet@staff.ttu.ee>

Date: Wed, 01 Oct 2003 20:04:54 +0300

Message-ID: <3F7B0936.8010609@staff.ttu.ee>

To: www-rdf-logic <www-rdf-logic@w3.org>

Date: Wed, 01 Oct 2003 20:04:54 +0300

Message-ID: <3F7B0936.8010609@staff.ttu.ee>

To: www-rdf-logic <www-rdf-logic@w3.org>

Hi, Thanks a lot for the clarifications. I do have some additional questions in the following, basically checking if I now interpret the containers and collections correctly. >>As expected, mostly it is straight[fo]rward, but in some places >>I have not been able to understand what would be the >>right translation (ie what would be the exact semantics) >>of RDF and OWL constructions. Right now I have two >>main questions. >> >>First, suppose we want to say that "P" is a symmetric property. >> >>We can axiomatize what "symmetric" means by: >> >>forall X,Y,Z. holds(symmetric,X,Y) <=> >> (holds(X,Y,Z) => holds(X,Z,Y)). >> >> > >I think that you meant to say > > forall X,Y,Z. holds(symmetric,X) <=> > (holds(X,Y,Z) => holds(X,Z,Y)). > >or maybe even > > forall X,Y,Z. holds(rdf:type,X,owl:SymmetricProperty) <=> > (holds(X,Y,Z) => holds(X,Z,Y)). > Certainly. I was meaning the second of your options (to keep to triples) but messed up my example. Thanks for correcting! >>The question is whether in OWL the equivalence <=> >>in this definition should really be an implication => >>or it should be an equivalence <=> >> >>What is the _right_ axiom schema for OWL: with implication >>or with equivalence? >> >> > >The answers to these questions can be found in ``OWL Web Ontology Language: >Semantics and Abstract Synax'' (http://www.w3.org/TR/owl-semantics). >However, actually determining the answer is generally not trivial because >this document gives a model theory for OWL, and one has to investigate the >consequences of this model theory. I invite you to do the investigation. > >However, if you want to peek, the answer is <=>. OWL generally takes an >extensional stance on such questions. If the conditions for some >characteristic hold, then the characteristic holds. (RDF generally takes a >different stance here.) > I did peek :-), thanks a lot for the direct answer! Indeed, the RDF and OWL model theories are hard reading. I'd guess that for most people having some logic background (or knowing some plain Prolog) it would be hugely easier to have a classical FOL-based presentation of the semantics (as I am trying to build up for students on the blackboard while going through the constructions and ideas of RDF and OWL). I know that people have been working on this, but I have not seen a full presentation of, say, OWL semantics in FOL. Considering RDF, I have seen some presentations, for example, by Pat, but they _seemed_ to be incomplete (for example, all the seq-alt-bag business was unclear as far as I remember from what I have seen). >Note that it is possible to non-trivially infer that a property is >symmetric in OWL, as the inverse of a symmetric property is also >symmetric. > > Since you said that the definition of built-in properties uses equivalence, not implication, this must be the case. >>The question now arises: which are the right axioms >>for bag, seq and alt? >> >> > >The answer is, honestly, that there are none. RDF collections have no (or >very, very little) semantics. > > .... >>While "seq" seems fine, since it looks like being a >>plain list (ie no axioms), bag and alt pose problems. >> >> > >Even seq poses severe problems. For example, how many elements are there >in a sequence? > > .... >>Most RDF documents leave this to be understood >>"intuitively", which is not OK in RDF context. >> >> > >Agreed. That is why RDF Semantics has clarified the issue. > > OK, thanks. Looking now at the RDF semantics document, I notice sentences like: "Since the RDF container vocabulary is so limited, many 'natural' assumptions concerning RDF containers are not formally sanctioned by the RDF model theory <http://www.w3c.org/TR/rdf-mt/#glossModeltheory>. This should not be taken as meaning that these assumptions are false, but only that RDF does not formally entail that they must be true." And then: "The intended mode of use is that things of type rdf:Bag are considered to be unordered but to allow duplicates; things of type rdf:Seq are considered to be ordered, and things of type rdf:Alt are considered to represent a collection of alternatives, possibly with a preference ordering. The ordering of items in an ordered container is intended to be indicated by the numerical ordering of the container membership properties, which are assumed to be single-valued. However, these informal interpretations are not reflected in any formal RDF entailments." Using your clarifications as a guide I read these sentences now literally, and from this it seems that there are no axioms saying anything about bag-alt-seq and the RDF semantics paper clarification simply says that the "intuitive" differences between them are fake. Then the question arises as why to keep alt-seq-bag at all? Without clear differentiating semantics there is no sensible way to use the containers in any automated system, which is why we want to have RDF and friends in the first place. Is anybody trying to give more semantics for these or are there plans to discard them? >>And I could not understand the corresponding parts >>of RDF semantics paper. >> >> > >Section 3.2.2 of RDF Semantics is actually quite clear. It specifically >states that ``[t]here are no special semantic conditions on the container >vocabulary''. > >Collections are a slightly different matter. > > Just read the sections 3.2.2 and 3.2.3 again, as noted above. About collections, which at first sight seemed to be just lists, I read: "Note however that the semantics does not require any collections to exist other than those mentioned explicitly in a graph (and the empty collection). " It seems to me now that one should NOT interpret them as lists (in the sense lists-as-terms). If we interpret them as lists, this would in my mind contradict the ordinary meaning of "exists". In ordinary meaning, once we have a constant 'nil' and a two-place list constructor function symbol 'c', there does exist a one-element list, a two-element list, etc, since they are terms in the Herbrand universe. Of course, if first and rest are not function symbols but arbitrary properties with no defined axioms for them, then there are no problems with the meaning of "exists" in the above sentence. First and rest seem to be pretty useless in such a case, since I could use my own arbitrary properties in their place instead. Have I moved closer to the correct understanding of containers and collections by seeing them (now) as basically useless and potentially confusing objects in the language? Or is there something important I am missing? Regards, Tanel Tammet > >Received on Wednesday, 1 October 2003 13:04:42 UTC

*
This archive was generated by hypermail 2.3.1
: Wednesday, 2 March 2016 11:10:40 UTC
*