Re: [xtm-wg] Simplification and clarification of XTM - Editors please read...

["Thomas B. Passin" <tpassin@home.com>]

Graham Moore wrote -

> 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.
>

If you insist that each occurrance element and each association element
should contain all the structural elements of a topic element, then you
are forcing a lot of unnecessary  complexity.  I'm against this.  An
occurrance and an association are instances of their type, at least
according to the ISO model.  Therefore they can partake of all that
type's properties, right?  Why repeat them for each instance?

Simplicity is good.  Keep it as simple a possible.  Also, remember that
a topic element ("topic link") is supposed to represent a subject or
topic, but there could be other ways to represent or refer to one.  An
association element can be considered another way to represent an
instance of a topic.


> 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.'
>

Not necessarily.  Say the resource is a paper "Basics of Topic Maps" at
location http://TMTutorials.com/basics.doc.  My topic map may have one
topic named "creator" - that is, the creators of Topic Maps - and
another named "uses".  They both point to the same resource because I
can;t or don't wnt to indicate any finer granularity.  I do NOT want
these topics merged because they are not the same.

> The resource ref is an optional element on a topic and if present
indicates
> that the topic is a resourcetopic.
>
I don't see any need for all resources to be topics.  I think that just
makes for more complexity without bringing much value.  Anyway, isn't
that what occurrances are for? To link a topic to some information?  To
make a topic a resourcetopic, you only have to say that one of its types
is "tt-resourceref" (or whatever your ID for such a topic is).  Why
invent another attribute type when there is already perfectly good
machinary to do the job?

>...
> 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.
>
Again, don't require that a resource has to be a topic.  It should be
optional.  I realize that logically every resource is an instance of
some concept or subject that has a particulary type.  But it often
doesn't need to be spelled out in a topic map document, because often no
use will ever be made of that fact.  The role of the information is
often the most important thing, and you're not suggesting that the role
be made a topic in its own right.  Are you?  It might make some sense to
allow an occurrance role to be an instance of some type.

.
> The change to allow a resourceref directly on a topic enables us to
create
> topics for resources without having to create occurrences.

See earlier comments.  Also, why have a special class of topic that has
different properties than other topics?  If you want to do that, it
should be called something else, and its place in the design should be
carefully worked out.
>
>
> 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...
>
See comments above.  These thing are provided for through the type
attribute of the association.  Also, you have to be careful about
type-instance and class-subclass relationships.  They aren't the same at
all.  And I don't think that you want to get into making class-subclass
relationships into built-in features without a lot of thought and
discussion, because there are so many notions about what is covered in
such a relationship.  There are so many possiblitites, including all
different kinds of inheritance.

Better to avoid that by using predefined templates or types that spell
out the particular variety that is meant.  Type-instance is much less
ambiguous, so it is more suitable to be built-in (as it already is, of
course).


> 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.
>
It shouldn't talk about "subclass" at all without defining it meaning -
see above.

> 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.
>
>

I don't get this example at all.  I see this as being straightforward:

<topic id='tt-graham'>
    <topname><basename>Graham
    </basename></topname>
</topic>

<topic id='tt-empolis'>
    <topname><basename>Empolis World-wide Industries
    </basename></topname>
</topic>

<topic id='at-works-for'/>

<assoc type='at-works-for'>
    <assocrl> ...</role><!-- for Graham-->
    <assocrl>...</role><!-- for Empolis-->
</assoc>

(apologies for not using the latest versoin of the xtm syntax)

Just because there is a syntax doesn't allow you to avoid thorough
engineering analysis - in this case, deciding what the concepts should
be and how they should be related.

In summary, keep it simple, avoid variant types and concepts, and avoid
built-in concepts that don't have a ready consensus about their
meanings.

Cheers,

Tom Passin


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

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

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