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] Issue with instanceOf


My view on this: Peter Jones is right in what he says below.

The Conceptual Model does not show Scope as a subtype of topic, or of
association, or of topic map. It is indeed an animal of its own, and it
comprises zero or more topics.

Further, the class-instance relationship is a particular kind of
association (one that has the class-instance association template as its
template). Given that it is an association, it is (potentially) scoped,
as Peter rightly points out.

The question is then whether it is useful to have a syntactic shorthand
for a pointer to a topic that is a class of which the current topic is
an instance in the unconstrained scope, and then to disallow that same
sytactic shorthand if a scope is provided for the class-instance
association. It could be argued that class-instance associations are
*usually* unscoped (though there could be serious debate about that),
and that therefore the shorthand as it stands is useful. On the other
hand, allowing the syntactic shorthand also to be used when there is a
specified scope could be good, not least because it makes it very easy
to add scoping topics to the initially unconstrained scope without
having to adopt the long form of the syntax and thus radically change
the structure of the instance document.

Daniel


-----Original Message-----
From: Peter Jones [mailto:peterj@wrox.com]
Sent: 04 January 2001 12:43
To: 'xtm-wg@egroups.com'
Subject: RE: [xtm-wg] Issue with instanceOf


For reasons stated in other mails posted to the editors I do not believe
the
type of 'scope' to be either topic or association or topic map as these
constructs are understood in TMs.
Nor do I believe it can be effectively modeled using combinations of
these.
A scope is a different animal and requires a unique construct in the
processing model (whether that is there in the existing text or not I do
not
yet know as I haven't read that bit yet).

So...bearing that in mind
I'll state my question in a different way.
Should the contents of instanceOf _ever_ be unscoped (whether
unconstrained
or not), strictly speaking?

To dig back down to the fundamentals of the original little diagram that
Steve N drew in Paris...
When it comes to nailing the zero-dimensional point to the board we use
subjectIdentity.
And, IMHO, that is the only property of a topic that should be nailed
and
that therefore should not be scoped; everything else should be allowed
to
be.

Pete N wrote:
(2) is unnecessary because having a single association with multiple
types (each in a different scope) is equivalent to having multiple
associations (each in a different scope) where each association has a
single type.

Except that for some reason I might want to ensure that I have the same
set
of endpoints (members) on an association to which I subsequently add
many
types. Or a many-typed association that I want to add a new member too
under
all the types of association at once.
Amongst other things the scope mechanism is a powerful compression
factor.

Peter

-----Original Message-----
From: Daniel Rivers-Moore [mailto:daniel.rivers-moore@rivcom.com]
Sent: 04 January 2001 00:16
To: 'xtm-wg@egroups.com'
Subject: RE: [xtm-wg] Issue with instanceOf


Peter Newcomb's response points up the very issue I raised in my email
about syntax issues.

We should NOT be using the instanceOf subelement of association for the
purpose Peter Newcomb describes (which is to identify an association
that serves as a template for the current association). As Peter N
rightly points out, this is a different thing from instanceOf on topic.
Therefore (in accordance with the design decision already taken that
things that are different in nature should have distinct syntax), the
instanceOf element should not be used for this purpose. I have proposed
the use of an associationSpec subelement of association for this (by
analogy with roleSpec, which has exactly the same typing function with
respect to roles).

Peter Jones's question applies, however, to the ordinary use of
instanceOf, whether it be on on a topic element, an association element,
or an occurrence element. The purpose of instanceOf is to point to a
class of which a topic (or association, or occurrence) is an instance.

My position is that instanceOf is a syntactic shorthand for an unscoped
class-instance association. There may be merit in allowing this kind of
shorthand to be used for a scoped class-instance association as well.
This is the question I understand Peter J to be asking, and it merits an
answer. However, it's OK if the answer is to leave instanceOf unscoped,
because there does exist a longhand way of creating scoped
class-instance associations.

The longhand way of creating a class-instance association (scoped or
not) is to create an association element that has the public
class-instance association template as its template. However, given the
importance of typing to the topic maps paradigm, and the frequency with
which it is used, it is useful to have a syntactic shorthand such as is
provided by the instanceOf subelement.

Similarly, the occurrence is a syntactic shorthand for an association
between a topic and a reification of a resource, having the public
topic-occurrence association template as its template.

It is precisely these mappings between the syntax and the conceptual
model that need to be spelled out, and I have offered to create a first
draft of this. This task is intimately bound up with the declaration of
the relevant "public subjects". I was supposed to do this prior to the
Washington DC conference, but was unable to do so because there were
(still are) unresolved syntactic issues. I have raised these issues in
my earlier messages, and will allude to them again insofar as they are
relevant to the mapping between the syntax and the conceptual model,
which I shall be trying to produce in the next few dayus. 

Best regards

Daniel

-----Original Message-----
From: Peter Newcomb [mailto:peter@techno.com]
Sent: 03 January 2001 17:37
To: xtm-wg@egroups.com
Subject: Re: [xtm-wg] Issue with instanceOf


[Peter Jones <peterj@wrox.com> on Wed, 3 Jan 2001 14:34:27 -0000 ]
> why are the contents of instanceOf not scoped too?

In the case of an association element, the instanceOf element serves
to type the association.  If this typing relationship were to be
scoped, it would have to be done in one of two ways:

  1) by representing the typing relationship as another association in
     the topic map graph, or

  2) by allowing (in the conceptual model) scopes to apply to typing
     relationships even though they are not associations.

(1) is considered unacceptable because an association that models a
typing relationship between another association and its type must
itself be typed; if it is to be typed using the same mechanism as the
first association, it creates an infinite regression.

(2) is unnecessary because having a single association with multiple
types (each in a different scope) is equivalent to having multiple
associations (each in a different scope) where each association has a
single type.

-peter

--
Peter Newcomb                           Epremis Corporation
peter.newcomb@epremis.com               http://www.epremis.com/

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

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

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

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

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

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

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