[sc34wg3] Draft Reference Model
Sam Hunting
sc34wg3@isotopicmaps.org
Fri, 22 Nov 2002 21:34:43 -0500 (EST)
Sorry for delay in responding. This mail reaises several issues, but I'am
not sure we have enough issues yet to warrant calling out separate threads
for each....
On Mon, 18 Nov 2002, Graham Moore wrote:
>
> I have a few comments and offerings
>
> 1.
>
> I agree with bernard, it is not clear in the RM how I model
> symmetrical relationships. Such as his sibling example.
Steve addresses this issue in later correspondence.
I would prefer to say "express" rather than "model". If indeed the RM
creates an "assembly language" for topic maps, modeling would probably
take place in a higher-level (application-defined) language.
> 2.
>
> 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.)
>
> 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.
My recollection of Montreal is different. While I remember thinking that
your comment to this effect was brilliant, I'm not sure that there was
consensus on it.
> 3.
>
> 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
>
> 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?
Steve addresses this in a later mail.
For those without academic or other grounding in set theory, this site
may prove useful:
http://mathworld.wolfram.com/Set.html
http://mathworld.wolfram.com/SetTheory.html
(My take-away from the set theory page is that when I hear "set theory" I
had better ask "Which set theory? And why?"
> 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 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
>
Sam Hunting
eTopicality, Inc.
---------------------------------------------------------------------------
"Turn your searching experience into a finding experience."(tm)
Topic map consulting and training: www.etopicality.com
Free open source topic map tools: www.gooseworks.org
XML Topic Maps: Creating and Using Topic Maps for the Web.
Addison-Wesley, ISBN 0-201-74960-2.
---------------------------------------------------------------------------