[sc34wg3] Draft Reference Model

Graham Moore sc34wg3@isotopicmaps.org
Mon, 18 Nov 2002 18:47:56 -0000

I have a few comments and offerings


I agree with bernard, it is not clear in the RM how I model symmetrical =
relationships. Such as his sibling example.


I think the role types are mandatory for 2 reasons, one general and one =
specific to tm models. The general one is that you may want to make some =
assertion between two things but not really know what that assertion is =
yet. A real world example would be to transforms someones folder =
structure into a tm. Folder structures are weak (non-existant) on what =
the relationship is, but the user probably has a good idea about it. =
Thus having empty role types and empty assoc type allows for the =
association to be refined later. A very useful property when dealing =
with iterative topicmap construction. (Personally, I like all my types =
defined and organised but appreciate that that isnt everyones world.)=20

The second reason for leaving types undefined is because that is the =
nature of scope. I think we came to some consensus in montreal that =
scope is no more than untyped associations between an association and a =
set of topics.=20


This picks up on Bernard's point regarding Sets in RM. I appreciate that =
RM does not subscribe to any mathematical set model but i wonder about =
when do individuals become sets?

I'm not sure I found it but if I have two assertions in different maps =

graham worksfor empolis gmbh
graham worksfor empolis uk

and I merge them what happens?

is it now true that=20

graham worksfor [empolis gmbh, empolis uk]

through merging, or are the two assertions seperate?

How does this differ from the example bernard gave regarding his set of =



Graham Moore
vp r&d empolis gmbh

-----Original Message-----
From: Bernard Vatant [mailto:bernard.vatant@mondeca.com]
Sent: 18 November 2002 18:05
To: sc34wg3@isotopicmaps.org
Subject: Re: [sc34wg3] Draft Reference Model


> [Bernard Vatant]

> > > >   Well-formed node Case 3 ("a-node")
> > > >   The node serves as the A endpoint of two or more =
AC arcs.
> > > Why "two or more"? There are many cases of assertions with a =
single role type (take
> > > "sibling" for example)

> We've had numerous discussions about this, and the
> following viewpoint has (so far, anyway) prevailed
> consistently:

>   A relationship *type* that has only one possible
>   membership isn't a type of relationship at all.  In
>   an instance of such a relationship type, nothing can
>   have a relationship with anything else, by
>   definition, so it's not a relationship.

As expressed before in answer to Sam, unless I miss something, how do I =
sibling-ness or any other equivalence relationship if:
1. A single membership is not allowed.
2. Having two c-nodes of the same type in an assertion is not alllowed.

>   In the realm of syntax, however, it's frequently the
>   case that a link points somewhere else to establish a
>   relationship between the link and whatever the link
>   is pointing at ...

I'm not sure to catch what you are speaking about here, Steve, but I =
guess it's not
addressing my sibling-ness issue.

> If a relationship type has two possible role types, and
> an instance of that relationship type has a role player
> for only one of the role types, that's OK.  In fact,
> it's a frequent state of affairs in the real world: the
> relationship exists, and one of the role players
> exists, but there's no role player for the other role.
> The RM4TM has no problem with this.

Neither have I. Having a casting as an empty slot waiting for the role =
player is frequent
indeed. This non-issue has been raised by Marc on topicmapmail recently =

> > > I'm curious about the rationale making role type
> > > mandatory and assertion type optional.  (BTW both
> > > are mandatory in Mondeca ITM)
> Here's the rationale (at least as I see it):
> (1) In the graph, all role types are mandatory because
>     without them, there's literally no way to tell
>     which role player is playing which role.

True. That's why I always wondered why it is optional in XTM 1.0

> (2) Assertion types *are* mandatory for all assertions
>     that determine the subjects of any of their role
>     players.

Why those in particular? And what do you mean by "determine" ?
I'm lost here ...

>     The RM4TM constrains the definitions of assertion
>     types: it requires them to say how the values of
>     the Subject Identity Discriminating Properties
>     (SIDPs) of their role-playing nodes are affected.

That is a point I would like to see expanded in Baltimore.
I think I miss the point at the moment ...

> (3) Assertion types are *not* mandatory (but are still
>     a very good idea, I think) for assertions that
>     don't determine the subjects of their role players.
>     As far as the RM4TM is concerned, if an assertion
>     has no impact on the achievement of the Subject
>     Location Uniqueness Objective, it's not very
>     interesting to the RM4TM, and the RM4TM doesn't
>     care very much about it.
>     There is one very interesting implication of an
>     assertion's being "untyped" (i.e., about the fact
>     that an assertion's type is unspecified): such
>     assertions can never merge, even if they have the
>     same role players playing the same role types.
>     This is because, if their types are unknown, it
>     cannot be known whether they are really the same.

Yes indeed. And that looks to me more like poor modeling than anything =
I am curious to know of any serious TM application using untyped =
As said before, it is something completely forbidden in Mondeca ITM. =
Assertions types have
to be declared, and the assertion type constrains the assertion pattern. =
As far as I
understand, every other TM application does more or less the same. =
That's why I don't see
the point of letting the door open to untyped assertions, except for =
sake of letting
people keep on being loose and lazy.

> > > I would like the rationale of Note 21 to be
> > > expanded. On this father-child relationship, for example.

It does not seem to me that your long answer addresses my question. I =
agree that if I want
to speak about the set of my children, this set is a subject and has to =
be represented by
a single node. But my question is why should I be forced into speaking =
about that set if
I'm not interested in it? Why am I not allowed by RM to express in a =
single assertion.
"Bernard is the father of Alice, of Claire and of Jan", without making =
any explicit
assertion about the set {Alice, Claire, Jan}. Moreover, role type of =
each of my children
in such an assertion ("child") is quite natural, but role type of the =
*set* seems
difficult to conceive and name. I'm not the father of a set, but, =
certainly in different
ways, the father of three distinct children, right? So in that case I =
suppose I have to
utter three different assertions?

So I see what the constraint "No multiple role players of a =
single role type"
enforces unto the representation in some cases, but I fail to see what =
problem(s) it
solves. Particularly, I don't see how multiple players of the same role =
type can break
Subject Location Uniqueness.


Bernard Vatant
Consultant - Mondeca
Chair - OASIS TM PubSubj Technical Committee

sc34wg3 mailing list

This message has been checked for all known viruses by Star Internet
delivered through the MessageLabs Virus Scanning Service. For further
information visit http://www.star.net.uk/stats.asp or alternatively call
Star Internet for details on the Virus Scanning Service.