[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [xtm-wg] Simplification and clarification of XTM - Editors please read...
Graham, I think your are missing the distinction between "is subject" and "describes subject". A resource can only be a subject if is unambiguously addressable. Any other resources can not be reliably resolved, so it can not functions as the sole method of identity. Therefore, it can only say something about the topics, "describes subject". The set of subject descriptions for a topic represent its subject. But, as you can see, there is an important distinction between addressable and non-addressable. This is shown in the Conceptual Model. Also, I don't think that resources are topics. Resources are reified by being the subject of a topic. This topic is a proxy to the resource in topic map space, but the resource itself does not become a topic. That is my understanding. I would like for somebody to check me. > --- In xtm-wg@egroups.com, "Graham Moore" <gdm@e...> wrote: > general point.. > I have attached the revised DTD with examples in a comment at the end > that > further clarify and exemplify my comments. > a few thoughts and suggestions... > I see the way in which subject has been done in the syntax as very > clunky > and does not use the machinery of the model (i.e. resources as > topics). > Given that all resources are topics in the topic map. Something we > agreed > but has not been made clear in the spec, enables us to very cleanly > represent the different aspects of subject. > The clarification for topics as resources is : > 'if a topic has a resource ref and another topic has the same resource > ref > they are the same topic and should be merged.' > The resource ref is an optional element on a topic and if present > indicates > that the topic is a resourcetopic. > On the issue of merging, the example below says the two topics are the > same > as they have the same identity. Issue: should two topics really be > merged if > one references the other as its subject. This would imply that a topic > serves as ones of its own subjdesc. Which I think is a contradiction > to the > idea of topics being proxies to intangible subjects. i.e. the topic is > a > topic to 'the topic as a resource' and the proxied subject. A topic > can only > have one subject. > These should be merged... > <topic ID="Graham"> > <name> > gdm > </name> > <subjectIdentity> > <topicref href="#rt-1234"> > </subjectIdentity> > </topic> > <topic ID="Graham"> > <name> > Graham Moore > </name> > <subjectIdentity> > <topicref href="#rt-1234"> > </subjectIdentity> > </topic> > These should not? > <topic id="graham"> > <subjectIdentity> > <topicref href="#gdm"> > </subjectIdentity> > </topic> > <topic id="gdm"> > ... > </topic> > With this clarification the syntax in the DTD is much simpler, no less > expressive and re-iterates the idea that resources are topics. Which I > assumed would have to be made clear when we did occurrences. > On occurrences it should be made clear that the href of the occur > element > actually is a shorthand for creating a topic that is a proxy for a > resource. > The change to allow a resourceref directly on a topic enables us to > create > topics for resources without having to create occurrences. > If associations are subclasses of topics then we should have exacttly > the > same structure. I.e. names, identity and occurrences. If we have class > with > properties and a subclass of this class then they derive the > properties. If > you serialise this thing then you serialise the derived and super > class > properties. What we cannot have in the spec is contradication... > there is a section that talks about the 'properties' of a topic > association > and says that a assoc is a subclass of topic. We cannot say one thing > here > and not have a syntax that reflects this. > If someone can better explain this, (a topicassoc with names as occurs > split > into two completely urelated strcutures even though they are the > *SAME* > thing!!!! > <topic id="t-34"> > <basename> > <bnstr>Graham Works For Empolis</bnstr> > </basename> > <occur href="jsjfjgjjgjj" /> > </topic> > <assoc id="t-45"> > <role /> > <role /> > </assoc> > <!-- i'm not even sure how to relate them! --> > as being clearer than the following > <topic id="t-34"> > <basename> > <bnstr>Graham Works For Empolis</bnstr> > </basename> > <occur href="jsjfjgjjgjj" /> > <role /> > <role /> > </topic> > then I would concede that we dont need to make changes. However I > think we > need to make changes. > Clarification: > I would like to see syntax examples of the template ideas as in the > current > document. In the DTD I have supplied there are template examples that > work > with a prototyping model. I have clarifed the use of member roles. > Was it the intention of the spec to tell people what properties actual > 'object nodes', or 'nodes' should have. Or is this implementation > detail? > I am working my way through the spec and i'm sure there will be some > more > questions. > cheers > graham > Graham Moore > gdm@e... > Empolis > http://www.empolis.com > VP Research & Development Best regards, -- Luis J. Martinez IT Consultant tel: 201-583-0330 cell: 201-401-4816 email: luisjm@luisjm.com http://www.luisjm.com -------------------------- eGroups Sponsor -------------------------~-~> eLerts It's Easy. It's Fun. Best of All, it's Free! http://click.egroups.com/1/9699/0/_/337252/_/975610798/ ---------------------------------------------------------------------_-> 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