OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

topicmaps-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


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.org/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.topicmaps.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


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

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

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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC