Re: [topicmaps-comment] Topic, reifiying an adressable subject as rolein an association

[Kal Ahmed <kal@techquila.com>]

At 21:52 17/12/2001 -0500, Thomas B. Passin wrote:
>[Lars Marius Garshol]
>
> >
> > Hi Christian,
> >
> > * Christian Wohlgensinger
> > |
> > | Can a Topic referenced by a <topicRef> in a <roleSpec> element reify
> > | an addressable subject?
> >
> > This is a good question. I agree with you that semantically this seems
> > to make no sense, but I'm not sure to what extent we want such
> > constraints to be part of the model itself. This is also why no such
> > constraints are mentioned in the infoset document.
> >
>When I read Christian's original post, I wasn't sure I understood the
>question.  I'm still not sure...  Literally as posed, I don't see why it
>doesn't make sense - a topic may reify an addressable subject, and that
>topic could then be referenced in a roleSpec element, what's wrong with
>that?  - and that makes me think he meant the other possiblility.  In the
>second interpretation, the addressable subject is reified by virtue of being
>referenced in the roleSpec/topicRef, but that seems to be wrong since the
>subject is't a topic in itself.
>
>Or am I overlooking a third reading of the question?

The XTM Conceptual Model makes a clear distinction of the concept of 
"Class". It is not allowed (under the CM) for a Class to be an addressable 
subject. This makes sense - it is meaningless to say that a Topic is "an 
instance of" a webpage, or a particular graphic, for example. However, it 
is not meaningless to say that a topic is an instance of a concept 
represented by a webpage or a graphic - but in that case, the resource 
should be regarded as the subject indicator of the class topic, not its 
subject.

The question raised is therefore, should this constraint also apply to the 
roleSpec definition. In other words, is it meaningful for an addressable 
resource to be regarded as defining a role (as opposed to representing the 
concept that defines a role).

At least, that is my understanding after only one coffee... ;-)

Cheers,

Kal


>Cheers,
>
>Tom P
>
>
> > I've made a note of this issue, and would like to hear other people's
> > opinions on this issue, and the possible utility of such a constraint.
> > Personally I'd be happy to not bother about it. We can probably think
> > of lots of things one could do that make no sense, but how good an
> > idea it is to require all implementations to detect and reject them is
> > another matter.
> >
>
>Well, it's an interesting area to ponder.  A processor has to do so many
>things as it is, what with all the alternative forms and all, that one
>doesn't want to make it even busier.  On the other hand, we want to have a
>fighting chance of understanding what any legal construction is intended to
>convey.
>
>In my view, there are going to be a lot of idioms that some processor will
>make use of but others won't really "understand".  One example would be if
>you needed an hierarchical, ordered list.  There are several reasonable
>approaches, but it's hard to believe that a general purpose processor would
>be able to properly interpret all of them.  This argues for spelling more
>things out in the specs.  Perhaps we could discuss alternatives for creating
>and handling such "idioms"?
>
>Cheers,
>
>Tom P
>
> > If we do decide that we want such constraints we should go through the
> > entire model and make explicit decisions about this for each and every
> > information item type, and justify them.
>
>
>
>----------------------------------------------------------------
>To subscribe or unsubscribe from this elist use the subscription
>manager: <http://lists.oasis-open.org/ob/adm.pl>