RE: [xtm-wg] XTM-ISS Important XLink difference in DTDs

["Graham Moore" <gdm@stepuk.com>]

-------------------------- eGroups Sponsor -------------------------~-~>
No blistered feet. No crowd. No travel. Intraware invites you to attend
a virtual tradeshow: Ensuring Scalable and Secure E-Business Systems.
http://click.egroups.com/1/9219/4/_/337252/_/969868722/
---------------------------------------------------------------------_->



Just some thoughts regarding

The concept of NameServer,

<!-- [Michel]: This is a shortcircuit for something we
     already provide in a more powerful way. Since
     everything in a topic map is a de facto a topic (an
     association can be seen as a topic occurrence),
     everything can be named using the very same constructs
     that we already have, with full power (several names,
     which can be scoped, etc., and with display names, sort
     names, etc.)  Applications and user interfaces have
     plenty of stuff to play with already. I propose to
     stick with what we have in the ISO spec, i.e. no names
     except for topics.-->

I think that it is provided for in an ambiguous and inconsistent fashion in
the standard.

The standard basically confuses typing with naming,

	if I have <occrl occrole="picture of graham" href="... />

	it says that this is the name or title

	if I have <occrl type="jpeg" href=".... />

	then the name is jpeg and this occ is also an instance of jpeg

	What I want to express clearly is that I have an occurrence with a name
'picture of graham' of type jpeg.

	<occrl type="jpeg" nameservice="picture of graham' href ... />

	The nameservice constructs was used as a consistent abstraction that could
be re-used across all the type/ role occurrences. It provides an abstraction
for name either defined by a topic or specificed as an mnemonic. In
modelling terms its about building a common abstraction.

	I've attached a jpeg illustrating this point.

<!-- [SRN] I agree with Michel.  It's simpler *and* it's
     more powerful to do it the same way as the ISO
     spec. -->

Its too simple, becomes overloaded and ambiguous.


<!-- [Michel] I disagree. Topics are the ONLY mechanism to
      use when expressing something "about" something else,
      be it a painting, a opera piece, or an association
      between topics. Statements about statements are
      already possible, and they can be expressed at any
      nesting level desired, not only two as proposed
      here. Associations should not have occurrences,
      because this breaks the topic map model. It seems that
      what you are expressing here is a model which has
      nothing to do with the one provided in ISO 13250.
-->


RDF has a very powerful mechanism for reified statements that is enabled
through the simplicity of the model. Topic maps self inconsistency prevents
us from 'doing' reified stataments in an sensible and easy way. In order to
define a reified statment it is necessary to create a topic for the
association. This is a hack becuase the structures do not support closure.

I don't think that the discussions needs to go onto inference rules there is
a more fundamental mis balance. And if we are to  achieve synergy with RDF
which we will do. Then this is a very important point. My guess is that the
conceptual model will show a structure of this form in order to achieve both
an organic model and synergy with RDF.


cheers

Graham

> -----Original Message-----
> From: sentto-1553146-376-969852287-gdm=stepuk.com@returns.onelist.com
> [mailto:sentto-1553146-376-969852287-gdm=stepuk.com@returns.on
> elist.com]
> On Behalf Of Michel Biezunski
> Sent: 25 September 2000 04:26
> To: xtm-wg@egroups.com
> Subject: RE: [xtm-wg] XTM-ISS Important XLink difference in DTDs
>
>
> -------------------------- eGroups Sponsor
> -------------------------~-~>
> Your family still won't know what you do.  At least they'll
> know where.
> The resources, brainpower & breadth of opportunities at Microsoft are
> unmatched. The only question is are you ready for that kind of impact?
> http://click.egroups.com/1/9223/4/_/337252/_/969852287/
> --------------------------------------------------------------
> -------_->
>
> Kal, Philip and al.
>
> > Philip Rutherford wrote:
> >
> > >
> > > It seems to me that there is an important XLink difference between
> > > STEP's DTD (tm.dtd) and Michel Biezunski's DTD (mb.dtd).
> In STEP's DTD
> > > the <topic> element is the extended XLink and it contains <occurs>
> > > elements which are the XLink locators. In Michel's DTD
> however it is the
> > > <occurs> element that would be the extended XLink, and it contains
> > > <locator> elements which are then the XLink locators.
> > >
> > > For my own application of XTMs which is in describing web
> site structure
> > > I prefer Michel's DTD because it gives greater ability to
> add resource
> > > meta data to each <occurs> element. The example below
> uses Michel's DTD
> > > to describe a simple web site containing two documents:
> welcome.html and
> > > contact.html. This DTD allows separate descriptions of
> the two documents
> > > to be added using the XLink resource type element, as can
> be seen below.
>
> Philip, sorry to disappoint you but this was due to a too
> quick transition
> from
> HyTime varlink to Xlink.
> Kal, I agree with your points and I am changing the syntax
> accordingly.
>
> I had no intention to invent my own version of what Xlink
> should do, and on
> that
> point I agree with Kal. I think the kind of feature you
> are looking for can be handled by application, but the
> resulting syntax
> should not
> wear too much on what the rules had been to have it built,
> because then it
> would
> add much complexity on many parts of the syntax. Therefore
> the syntax should
> be
> as much as possible entirely compliant with various standards
> including
> Xlink and
> everything which adds managing power should be inserted into the
> application.
> If we need to standardize more, let's discuss this as a
> long-term issue, but
> I don\t think
> it's appropriate for v.1 of the XTM spec. Sorry for the
> confusion this might
> have caused.
>
> Please have a look -- and review --  the last version of the
> interchange
> syntax document,
> which I just sent to the egroups web site, and which contains
> input from
> Holger Rath, Steve Newcomb and me. There are several points
> on which we have
> to take quick decisions,
> so please comment.
>
> MIchel
> ==========================================
> Michel Biezunski, InfoLoom, Inc.
> 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

exampleNameServer.gif