Re: RDFTM: RDF reification

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