[sc34wg3] Draft Reference Model
Jan Algermissen
sc34wg3@isotopicmaps.org
Mon, 18 Nov 2002 20:31:58 +0100
Graham Moore wrote:
>
> One other quikie...
>
> In the RM is there a built in type 'Set'? Or are role player nodes always Sets?
Graham,
a quick answer.
No, in the RM there is no notion of setness, all there is, is the constraint that
there may not be more than one player for a single role.
This constraint ensures that any group of subjects that play the same role in a
relationship (as it understood in the world outside the graph) will be represented by
a single node in the graph representation. This is important, since this set is
a subject (the set of players of a certain role in a certain assertion) and so
there must be a node for it.
For example, if we did not have that node, how would we reason about (=make assertions
about) the cardinality of that set, in order to validate any cardinality constraints
imposed on the number of players of a certain role.
Role players are not allways sets and the graph does not 'know' anything about this
issue (there is only a subject that plays a certain role). WHAT this subject is (if it
is a set or not) is part of the semantics of the particular assertion type.
Example: If you have some class-instance assertion and you want to know what playes the
class role, you would ask for the single subject that plays the class role, you would not
ask for the set of subjects that play the class role. You wouldn't, because you KNOW that
there will be only one player of that role, it's part of the semantics of the class-instance
assertion type.
[Of course there cen be several classes of a certain subject, but that would be expressed
be *several* class-instance assertions]
I hope this gives you an idea to proceed with.
Jan
> gra
>
> -----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 message has been checked for all known viruses by the MessageLabs Virus Scanning Service.
> _______________________________________________
> sc34wg3 mailing list
> sc34wg3@isotopicmaps.org
> http://www.isotopicmaps.org/mailman/listinfo/sc34wg3
--
Jan Algermissen
Consultant & Programmer
Tel: ++49 (0)40 89 700 511
++49 (0)177 283 1440
Fax: ++49 (0)40 89 700 841
Email: algermissen@acm.org
Web: http://www.topicmapping.com