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

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

[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?

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.