- From: Pat Hayes <phayes@ihmc.us>
- Date: Fri, 24 Mar 2006 10:52:02 -0800
- To: Lars Marius Garshol <larsga@ontopia.net>
- Cc: SWBPD list <public-swbp-wg@w3.org>
>>Suppose the basic fact is that Bill and Sue are married. Then we >>can distinguish >> >>1. Married, which is a binary relation: in RDF/OWL, a property. >>2. The fact that Bill and Sue are married: in RDF/OWL, represented >>by a triple. >>3. The particular state of being married that holds uniquely >>between Bill and Sue (and no others): what in philosophy is often >>called a 'trope' (see eg >>http://en.wikipedia.org/wiki/Trope#Tropes_in_philosophy). This has >>no standard RDF representation, but it could be described, somewhat >>artificially, as a subproperty of Married. (Described in OWL, this >>subproperty would have singleton classes as its domain and range.) >>4. The RDF triple, considered as a platonic syntactic object, which >>asserts (2). Again, there is no RDF equivalent, although some folk >>use RDF reification for this (contrary to what the standard says; >>but it does say it non-normatively) >>5. A particular token or inscription of this triple in some >>document: this is what an RDF reification is intended to denote, >>according to the RDF semantics. > >What we are after here is 2. or 3. I have to admit that I am >clueless as to what the distinction between them is. The trouble may >be that I don't see any difference between a fact of a marriage and >the state of being married. A fact is something that is true. So there is no 'fact of a marriage': there is the fact *that a marriage exists*, perhaps, or the fact *that two people are married* (notice the ubiquitous 'that'.) The state of being married is harder to describe precisely, but it is usually understood to be some actual thing in the world, a state which obtains between some other things, lasts for a time, has properties, etc.. Sometimes it is an event. We might refer to it using a noun phrase "Bill and Sue's marriage", as in 'Bill and Sue's marriage was short-lived". (The philosophical point being that if its so described then it must be a nominal, therefore according to some folk, something real.) These things, whatever they are, aren't true or false: you can say, "It is true that they are married" but not "It is true Bill and Sue's marriage". >I tried looking in Wikipedia, but, well, it didn't help. It isn't much use, I agree. Sorry I only did one quick google. This is better: http://plato.stanford.edu/entries/tropes/ As a hint, ignore the philosophical jargon (exemplification? I don't know, either) and focus on the examples :-) . >Any additional clues would be welcome. > >>This would seem to depend on what 'reification' means in TM. Can >>anyone tell me how to find this out? The description in >>http://www.isotopicmaps.org/sam/sam-model/#d0e991 is completely >>incomprehensible. > >It means either 2. or 3., but I don't yet know which. I suspect it would be 3., as reifying 2. would just get you a truthvalue. This ties in with the importance of 'roles' in TM also. So lets assume this and run with it. There is a natural mapping from RDF-style binary relational logic (each triple has two, er, topics) to what is sometimes called a role/event based formalism, in which one reifies the trope and relates the arguments to it by roles. This seems to be what TM has done. This suggests a mapping like this from an RDF triple S P O . to what in RDF would look like this: _:x type P _:x subject-role S _:x object-role O which looks quite like an RDF reification in its structure, but is intended to refer not to the triple but to the 'relationship' (which Im taking to be a trope) which it asserts to hold between S and O. So in the current case it would be this particular marriage (not the marriage relation, which embraces all marriages) between Bill and Sue, eg using appropriate role names: ex:Bill civ:Married ex:Sue . ==> _:x rdf:type civ:Married . _:x civ:husband ex:Bill . _:x civ:wife ex:Sue . Ive used a blank node, but it would be perfectly fine to give this 'thing' a genuine name, with the understanding that the result could not be fully translated back into simple RDF triples without loss of information. Notice also that the property name in the triple is now a class name. This is legal in RDF and RDFS, but would break OWL-DL; if this is a concern, some kind of systematic re-naming convention would have to be applied, such as ex:Marriage ==> ex:MarriageClass. This could be decked out with extra features, for example by associating the roles with the original property: civ:husband struct:roleTypeOf civ:Married . or by introducing a 'meta-class' of properties which have associated roles: civ:Married rdf:type struct:RoleTypeProperty . and so on. However, again, be warned that much of this would break OWL-DL. And of course Im doing this all in RDF since its what I know. >>BTW, a singular lack in this ISO TM document is an explanation of >>what is meant by "relationship", as in [...] > >It's true that this is not defined beyond the use of a common >English term. I understand that for the purposes of logic this is >unlikely to be satisfactory. Well, it is unsatisfactory for any precise purpose, not just logic. (In any case. 'logic' is just a word used to refer to precise accounts of meaning.) Like many common English terms, "relationship" is highly ambiguous, and the ambiguities matter. It is impossible to base any account of meaning on such words without giving them a more technical gloss, preferably by reference to some kind of mathematical basis. >>This could be understood as meaning a relation, as in sense (1) >>above, or a fact (or proposition) as in sense (2), or possibly as >>meaning a trope, as in sense (3), or possibly something else >>altogether. It is impossible for me to determine what the document >>actually means, and the term is not defined in it anywhere. Can >>anyone point me at an explanation of what this terminology >>("relationship") is intended to mean in TM? > >There is none. Oh dear. >>A related question: is there any kind of formal semantics for TM? >>Without one, no suggested mapping between TM and RDF can be >>authoritative. > >There is no formal semantics for Topic Maps. I understand your >concern that this means mapping from something that has no logical >interpretation to something that does, but this happens to be the >situation we are in. It does not have to be. Surely it would not be beyond the state of the art to give a precise semantics (a model theory) for TM? Defining a meaning-preserving mapping from TM to RDF would in any case give TM a kind of induced formal meaning, but it is a haphazard way to proceed. And it seems silly to be talking about such mappings before TM has a precise semantic theory, since they might well turn out to be wrong once it is given one. The construction suggested above, for example, is based on a well-known translation between relational logic and role-based syntaxes used in logic programming, but applying it here is at best a guess. But if this is not considered necessary or practicable, then I have to ask, what are the criteria for getting this mapping right? Why not just make up some trivial mapping from TM into uninterpreted triple stores and leave it at that? >I think it's worth bearing in mind that this will be the case when >mapping to RDF from pretty much any existing technology Nonsense. Almost all current knowledge representation technologies have some kind of reasonably precise semantic theory, or are based on some foundation which has one. Without it, there is no basis for software to be doing anything special with any data structures. Certainly the use of the word 'ontology' in this kind of a context has, ever since the word came into use, implied at least a foundation with a formal semantics, and in many cases the use of an explicitly formal notation. >, so this is not a failing that's unique to Topic Maps. Actually, in my experience it is. Topic Maps seem to stand out from the crowd in this respect. Pat Hayes > >-- >Lars Marius Garshol, Ontopian http://www.ontopia.net >+47 98 21 55 50 http://www.garshol.priv.no -- --------------------------------------------------------------------- IHMC (850)434 8903 or (650)494 3973 home 40 South Alcaniz St. (850)202 4416 office Pensacola (850)202 4440 fax FL 32502 (850)291 0667 cell phayesAT-SIGNihmc.us http://www.ihmc.us/users/phayes
Received on Friday, 24 March 2006 18:52:25 UTC