[sc34wg3] Pre-publication draft of XTM 1.1 CD

[Lars Marius Garshol]

* dmitryv@cogeco.ca
| 
| Actually, I am not sure why ID is allowed in case of one member and
| disallowed in case of several topics in member element.

There's no such rule. I guess that's what you meant originally. Or?
 
| I found also that in 5.16 a locator item is created if there is an
| ID and only one topic-member. It means that I can reify fact of
| being one member for a topic but I cannot reify fact of being member
| for a set of topics.

The member approach was abandoned, and so there is only association
roles. The problem with the ID on <member> when it has multiple
children is that you don't know which role it identifies.

| Why do we have a special case for one member? 

Because the syntax is regarded as a bug. The model is how we want it,
but the syntax was designed to cater for the special case when
multiple topics play the same role in the same association, and to
make it possible to directly reify the entire set without having to
model it with associations. The structure in the model reflects the
original HyTM syntax.

| It makes more sense, I think, to have ability to reify sets. 

What for? Sets occur extremely rarely, and if you *want* to model them
you can create a topic for the set, and then associate in each role
you want in it.

| I can use set reification for example to specify some properties of
| this set such as "full set", "partial set", "number of elements in
| set".  So I can represent such facts as: - paper23 has three authors
| - but...I know only two of them now - set of authors for paper23 is
| partial now

I don't think the ID on <member> is the right way to support this kind
of thing. You can easily do this with topics, associations, and
reification, without having to change the model. Why turn associations
into a complicated structure with three levels instead of two? 

-- 
Lars Marius Garshol, Ontopian         <URL: http://www.ontopia.net >
GSM: +47 98 21 55 50                  <URL: http://www.garshol.priv.no >