[sc34wg3] Draft Reference Model
Graham Moore
sc34wg3@isotopicmaps.org
Mon, 18 Nov 2002 18:47:56 -0000
I have a few comments and offerings
1.=20
I agree with bernard, it is not clear in the RM how I model symmetrical =
relationships. Such as his sibling example.
2.=20
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
3.=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 =
where:
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 =
children?
cheers
gra
Graham Moore
vp r&d empolis gmbh
gdm@empolis.co.uk
-----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
Steve
> [Bernard Vatant]
> > > > 3.5.1.3 Well-formed node Case 3 ("a-node")
> > > > 3.5.1.3.1.2 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 =
express
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 =
...
BV
> > > 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 =
else.
I am curious to know of any serious TM application using untyped =
assertions.
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 3.6.4.2.1 "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
-------------------------------------------------------------------
Bernard Vatant
Consultant - Mondeca
www.mondeca.com
Chair - OASIS TM PubSubj Technical Committee
www.oasis-open.org/committees/tm-pubsubj/
-------------------------------------------------------------------
_______________________________________________
sc34wg3 mailing list
sc34wg3@isotopicmaps.org
http://www.isotopicmaps.org/mailman/listinfo/sc34wg3
_____________________________________________________________________
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.
_____________________________________________________________________
This=20message=20has=20been=20checked=20for=20all=20known=20viruses=20by=20=
the=20MessageLabs=20Virus=20Scanning=20Service.