[sc34wg3] Draft Reference Model

[Graham Moore]

One other quikie...

In the RM is there a built in type 'Set'? Or are role player nodes =
always Sets?

gra=20

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