RE: [xtm-wg] Nikita's comments

["Chris Angus" <chris.angus@kalido.com>]

Nikita

I refer you to F.3.3

Regards
Chris

-----Original Message-----
From: Nikita Ogievetsky [mailto:nogievet@cogx.com]
Sent: 08 February 2001 18:14
To: xtm-wg@yahoogroups.com
Subject: Re: [xtm-wg] Nikita's comments


Chris,

>From what you are saying, I assume that you believe that
the following:

<association>
    <member>
        <roleSpec><topicRef xlink:href="#asserted-by"/></roleSpec>
        <topicRef xlink:href="#peron1"/>
    </member>
    <member>
        <roleSpec><topicRef xlink:href="#asserted-by"/></roleSpec>
        <topicRef xlink:href="#peron2"/>
    </member>
    <member>
        <roleSpec><topicRef xlink:href="#fact"/></roleSpec>
        <topicRef xlink:href="#fact1"/>
    </member>
</association>

is equivalent to:

<association>
    <member>
        <roleSpec><topicRef xlink:href="#asserted-by"/></roleSpec>
        <topicRef xlink:href="#peron1"/>
        <topicRef xlink:href="#peron2"/>
    </member>
    <member>
        <roleSpec><topicRef xlink:href="#fact"/></roleSpec>
        <topicRef xlink:href="#fact1"/>
    </member>
</association>

Well ... I very doubt it.
Merging rules for association members were never discussed
and I do not thing that anything of this sort should be taking place.

I may want to have those members separately.
For example I may want to reify member role of #person1
and supply some metadata for it.
If I merge member roles as you suggest I am losing this capability.
Why should they be merged? Even "implicitly"?

If a family have to sons, who said that these sones
are one and the same entity in the family?

Thanks,

Nikita.

----- Original Message -----
From: Chris Angus <chris.angus@kalido.com>
To: <xtm-wg@yahoogroups.com>
Sent: Thursday, February 08, 2001 1:03 PM
Subject: RE: [xtm-wg] Nikita's comments


> Nikita
>
> I would be unhappy about your proposal (1).
>
> I think that it would be useful to have #rolespec as a PSI, but only so
that
> a topic that is a rolespec may be classed as such.
>
> If you assume generic #rolespec as the roleSpec if one is not present then
> you are also implicitly merging all such member elements in an association
> into one member element.  I do not think that is desirable behaviour.
>
> Regards
> Chris Angus
> KALIDO Product Architect
> Tel: +44 16 9774 1504 / +44 20 7934 4960
> chris.angus@btinternet.com / chris.angus@kalido.com
> www.kalido.com
>
> -----Original Message-----
> From: Nikita Ogievetsky [mailto:nogievet@cogx.com]
> Sent: 08 February 2001 17:06
> To: xtm-wg@yahoogroups.com
> Subject: Re: [xtm-wg] Nikita's comments
>
>
> Steve, thanks for your response
> Hope you have time to read mine.
>
> My proposals intend to fix the gap
> between conceptual model and syntax.
> (same as changing member players from + to *)
> 1)
> Conceptual model requires roleSpec on a assoc.member.
> In DTD it is optional.
> Problem can be fixed if we say that
>
> if roleSpec is omitted then generic
> http://www.topicmaps.org/xtm/1.0/core.xtm#rolespec
> is assumed.
>
> 3)
> Same thing
> http://www.topicmaps.org/xtm/1.0/core.xtm#addressable
> http://www.topicmaps.org/xtm/1.0/core.xtm#non-addressable
> are required in order to justify <instanceOf> content model
> (i.e. make a bridge between it and the fact that
> it is a shortcut for an association)
> My original posting explains why.
>
> In my opinion, if we want conformance between conceptual model
> and syntax, these PSI-s are important and should belong to the core.
>
> Thanks,
>
> Nikita.
>
> -------------------------------------------
> Nikita Ogievetsky                  Cogitech Inc
> XML/XSLT/XLink/TopicMaps Consultant
> nogievet@cogx.com   --   (917) 406-8734
> http://www.cogx.com     Cogito Ergo XML
>
> ----- Original Message -----
> From: Steve Pepper <pepper@ontopia.net>
> To: <xtm-wg@yahoogroups.com>
> Sent: Thursday, February 08, 2001 9:12 AM
> Subject: [xtm-wg] Nikita's comments
>
>
> > Some responses to Nikita's comments:
> >
> > At 01:55 07/02/01 -0500, Nikita Ogievetsky wrote:
> > >1)
> > >2.3.2
> > >add default association member to Mandatory Published Subject
Indicators
> > >
> > >member: The core concept of association member; the generic role played

> by a
> > >member in an association unless otherwise specified.
> >
>
><http://www.topicmaps.org/xtm/1.0/core.xtm#rolespec>http://www.topicmaps.or
> g/xtm/1.0/core.xtm#rolespec
> > >
> > >This is important because <roleSpec> is optional.
> >
> > We did have a PSI in there for "role" at one time, but we took it
> > out to reflect the fact that there is no longer any <instanceOf>
> > and therefore no longer any need for a "default class" (as there
> > is with topic, occurrence, and association.
> >
> > I think this can be argued both ways, and I'm not sure it makes
> > a big difference in the here and now. Obviously, "role" will be
> > one of the candidates for any extension to the Core PSIs (as
> > will other topic map constructs like "topic name").
> >
> > >2)
> > >3.8.3
> > ><roleSpec> element needs a little more description. Currently it is
> rather
> > >unspecified compared to other elements.
> > >Particularly it would be worth to mention why we do not use
<instanceOf>
> > >here.
> > >I think it will be a very common question that people will ask.
> >
> > It's hard to know what more to say, without duplicating what's in
> > the text under the "Content model" heading immediately after. This,
> > together with the examples, make the thing clear enough in our
> > opinion.
> >
> > >3)
> > >3.4.1 and 3.8.3
> > ><instanceOf> and <roleSpec> elements are missing <resourceRef> from
their
> > >children content
> > >is it because resource can not be instantiated?
> > >In any case it breaks consistency with the conceptual model (which we
all
> > >worry about :-))
> > >because these elements are modeled as shortcuts to "instance-of"
> > >associations and as such should
> > >mirror <member> content.
> >
> > This reflects an insight (and decision) from Dallas: That resources
> > by their very nature, cannot possibly be classes of things.
> >
> > >Alternatively, I propose to add 2 mandatory public subjects:
> > >(I would rather prefer this)
> > >
> > >2.3.2
> > >-
> > >the generic class of all topics whose subject is a resource.
> >
>
><http://www.topicmaps.org/xtm/1.0/core.xtm#addressable>http://www.topicmaps
> .org/xtm/1.0/core.xtm#addressable
> > >-
> > >the generic class of all topics whose subject is not addressable (is
> > >indicated by a set of resources ).
> >
>
><http://www.topicmaps.org/xtm/1.0/core.xtm#non-addressable>http://www.topic
> maps.org/xtm/1.0/core.xtm#non-addressable
> > >(sorry, could not think of better naming at this late hour)
> > >
> > >Instances of #non-addressable topics do not have <resourceRef> in
> > ><subjectIndicator> content.
> > >
> > >Then Association templates in the future can be used to allow only
> > >instances of #non-addressable topics as "instanceOf" association
members
> > >
> > >These PSI may also be useful when modeling <occurrence>.
> >
> > Again, these belong in an extension to TM.Org's published subjects,
> > not in the core.
> >
> > Steve
> >
> > --
> > Steve Pepper, Chief Technology Officer <pepper@ontopia.net>
> > Convenor, ISO/IEC JTC1/SC34/WG3  Editor, XTM (XML Topic Maps)
> > Ontopia AS, Maridalsveien 99B, N-0461 Oslo, Norway.
> > http://www.ontopia.net/  phone: +47-22805465  GSM: +47-90827246
> >
> >
>
>
>
>
> To Post a message, send it to:   xtm-wg@eGroups.com
>
> To Unsubscribe, send a blank message to: xtm-wg-unsubscribe@eGroups.com
>
>
>
> To Post a message, send it to:   xtm-wg@eGroups.com
>
> To Unsubscribe, send a blank message to: xtm-wg-unsubscribe@eGroups.com
>
>
>



To Post a message, send it to:   xtm-wg@eGroups.com

To Unsubscribe, send a blank message to: xtm-wg-unsubscribe@eGroups.com



------------------------ Yahoo! Groups Sponsor ---------------------~-~>
eGroups is now Yahoo! Groups
Click here for more details
http://click.egroups.com/1/11231/0/_/337252/_/981664937/
---------------------------------------------------------------------_->

To Post a message, send it to:   xtm-wg@eGroups.com

To Unsubscribe, send a blank message to: xtm-wg-unsubscribe@eGroups.com