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: RE: [xtm-wg] DTD issues


Gaham - I said to you this morning that I need to respond to you on this
one. I think what we have is very elegant and simple and corresponds well to
the conceptual model. The diagram that is relevant is the ond called
TopicsAndSubjects.gif. The isSubject element is the lower line coming out of
the Topic bod, and points at a resource that is the subject of the Topic.
There can only be one subject for a given topic, hence this is not a
repeatable element. The describesSubject element is the upper line coming
out of the Topic box, and points at a resource that is a Subject Descriptor
for the Topic, which is related to the Subject via the mind of the author
and hopefully, if the communication is successful, the mind of the reader of
the resource also.

The Subject itself can never be *in* the syntax. But the subjectRef
*element* is very useful in that it is the syntax's way of referencing the
subject, either directly (using the isSubject subelement), or via a human
mind (using one or more describesSubject subelements), or both.

Daniel

-----Original Message-----
From: Graham Moore [mailto:gdm@empolis.co.uk]
Sent: 16 November 2000 11:22
To: xtm-wg@egroups.com
Subject: RE: [xtm-wg] DTD issues




I'm looking at the DTD from peter newcomb and I find isSubject stuff unclear
and I think redundant.

If I understand it right the distinction is made between isSubject and
subjectRef to distinguish between the topic as the identity or as a resource
proxy. I think we already have this. The predefined associations identity
and occurrence indicate the role the topic is playing. If identity it is
subjectRef if an occurrence then isSubject.

I would suggest that the syntax is unclear and can be made more concise.

perhaps something like..

<!ELEMENT topic ((resourceRef, resourceData), basename*)

The nature of these topics and resource refs is determined by the role the
topic plays in defined assocs.

I would like someone to clarify this for me or agree. :)

cheers

graham
gdm@empolis.co.uk

-----Original Message-----
From: sentto-1553146-894-974361140-gdm=stepuk.com@returns.onelist.com
[mailto:sentto-1553146-894-974361140-gdm=stepuk.com@returns.onelist.com]
On Behalf Of Michel Biezunski
Sent: 16 November 2000 07:50
To: xtm-wg@egroups.com
Subject: RE: [xtm-wg] Promotion of Conceptual Model


[Steve Newcomb:]

> The draft Dallas minutes advise that we make the conceptual model an
> Annex.  The thinking behind this decision was that we needed to be
> able to publish the Spec regardless of whether the Conceptual Model
> became available for publication.  I think we should reconsider this
> policy, and, instead, move the Conceptual Model forward, not treating
> it as an Annex, thus avoiding any possibility that implementers might
> miss the Conceptual Model simply because it only appears in an Annex.
> More to the point, the Conceptual Model is of the very essence of what
> we're talking about in this Spec; it's no less essential to software
> developers than the DTD is.  The Conceptual Model offers a vital
> perspective on the nature of the information that the DTD is designed
> to convey in interchangeable form.

Yes, but precisely, the "Conceptual" Model is useful especially to sofware
developers to optimize implementation design, while the "Topic Map Syntax
Model"
is useful especially to information managers to define their information
architecture.
We are speaking to different audiences here, and we have to make it
accessible to
both of them. It's better if we can keep them in clearly separated sections
(as Murray pointed out). Optimizing implementation is a plus, but it is not
absolutely
crucial, as long as proper interoperability is assured.

> In any event, we already have the annotated UML diagrams, and, if need
> be, the diagrams are self-sufficient.

They are difficult to understand if they are not properly documented. But
we can still add documentation later if needed.

Michel
==========================================
Michel Biezunski, InfoLoom
Tel +33 1 44 59 84 29 Cell +33 6 03 99 25 29
Email: mb@infoloom.com  Web: www.infoloom.com
==========================================



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

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


________________________________________________________________________
This message has been checked for all known viruses, by Star Internet,
delivered through the MessageLabs Virus Control Centre.
For further information visit:
http://www.star.net.uk/stats.asp



________________________________________________________________________
This message has been checked for all known viruses, by Star Internet, 
delivered through the MessageLabs Virus Control Centre. 
For further information visit:
http://www.star.net.uk/stats.asp



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

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

-------------------------- eGroups Sponsor -------------------------~-~>
eLerts
It's Easy. It's Fun. Best of All, it's Free!
http://click.egroups.com/1/9699/1/_/337252/_/974376186/
---------------------------------------------------------------------_->

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