[sc34wg3] Requirements for the foundational model - level 1

Tue, 6 Nov 2001 16:10:33 -0000

I have only one addition to Lars points, and a couple of general
observations...

| One of the problems we have been having is that as people try
| to "simplify" the model we are loosing the ability to distinguish
| between data sets that need to be separately managed.  Who is to
| make the decision as to what can and cannot be managed within a
| topic map?

I think that we are attempting to 'generalise' the aspects of the model
that can be. This does not mean losing any aspect, but redefining it in
a way that is consistent with other useages. The name example Lars gave
is a good illustration of this - a name is a name. But there are
different kinds of names. We can never ever be successful in making
every possible name-type a first class entity. But we can make 'name' a
first class entity and have a mechanism by which every name type can be
expressed in an interchangable fashion. Why do we make name a first
class entity - becuase we want people to be able to semantically use and
interchange topics and *know* how to find out what they are called. I
dont see that theres a problem here, we are keen to preserve the key
aspects of TopicMaps that deserve their first class status. But we
should be looking to do so in a more general way - where appropriate.

Martin these following points are not in direct response to your
comments although your comments made my think along these lines....

It is interesting to consider this balancing act - how much can be made
generally first class before we end up with names and properties. A
model is about how much abstraction you put on top of these constructs -
this is what makes topicmaps what it is, some commonly agreed
abstractions, designed to solve a problem that hasnt been addressed.

The issue of defering to XTM leads me on to my last point - we should
realise here that both 13250 and XTM are under specified becuase they do
not rigerously define a data model. It is possible that as we construct
this data model things will appear to us that have not previously been
seen. I liken this to testing the XTM samples in the XTM 1.0 spec where
we found that the DTD was nonsense in some places. Until you iron out
the ambiguities by doing something in a rigouress fashion then I think
we should not necessarily defer to XTM or 13250 -but to the model.

graham

-----Original Message-----
From: Lars Marius Garshol [mailto:larsga@garshol.priv.no]
Sent: 06 November 2001 15:52
To: sc34wg3@isotopicmaps.org
Cc: Geoff Williams; a.m.wrightson@bcs.org.uk; Graham Moore;
francis@franciscave.com
Subject: Re: [sc34wg3] Requirements for the foundational model - level 1

Hi Martin,

First off: thank you very much for these excellent question. Very good
that someone asks them.

* Requirements draft
|
| 1. The data model shall define all logically relevant aspects of
| topic map information (including all strings and locators). Anything
| that is not explicitly part of the model shall not considered to be
| part of topic maps.

* Martin Bryan
|=20
| Who is to decide what is and is not "logically relevant"?=20

We are. That is, the line is to be drawn by the data model.

| For example, Sort Names are not considered "logically relevant" by
| the XTM community, but are an explicit logical unit within ISO
| 13250.

They are logically relevant in XTM as well, they are just not
first-class objects. Instead, they are represented as variant names in
a particular scope.

| One of the problems we have been having is that as people try
| to "simplify" the model we are loosing the ability to distinguish
| between data sets that need to be separately managed.  Who is to
| make the decision as to what can and cannot be managed within a
| topic map?

This question I am not sure I understand. Can you elaborate?
=20
* Requirements draft
|
| 3. The data model shall be written in such a way that third parties
| can write specifications defining the process of building instances
| of the model from data sources other than the two standardized topic
| map syntaxes.
=20
* Martin Bryan
|
| Is ISO 13250 really a standardized syntax? I always thought that one
| of its strengths was the way it was divorced from application
| syntaxes.

It's admittedly a simplification to say that it's a single syntax.  It
is of course a HyTime meta-DTD, but I'm not sure we gain anything by
increasing the precision of this requirement. Would you like us to
change it, or did you just want clarification?
=20
* Requirements draft
|
| 2. The foundational model shall be 100% compatible with every aspect
| of the implicit data model of XTM 1.0 that is actually defined in
| the XTM 1.0 specification. This includes annex F.
=20
* Martin Bryan
|
| What happens if some aspect of ISO 13250 is not covered by the model
| (e.g.  facets)?

It must still be represented, although perhaps not in the precise form
it takes in the 13250 syntax. So sort and display names become
variants, while facets will most likely be represented using topics
reifying the resources the facet values apply to, and using
associations to represent the assignment of facet value.

So no logically significant aspect of the 13250 model should be lost,
although its representation may be a little unfamiliar.
=20
* Requirements draft
|
| 5. The foundational model shall be able to represent all logically
| significant aspects of ISO 13250 topic map documents.
=20
* Martin Bryan
|
| Who is to decide on the significance of any 13250 construct?

We are. That is, this line must be drawn as part of the process of
creating the model. We may end up having disagreements over some of
that line-drawing, though I do not really expect so.
=20
* Requirements draft
|
| 6. The foundational model shall not contradict any constraints on
| the model laid down by ISO 13250, except in so far as they are
| contradicted by XTM 1.0. In cases of discrepancy XTM 1.0 shall take
| precedence.
=20
* Martin Bryan
|
| You cannot really expect me to accept the inflammatory statement in
| the second sentence !!!!!

That's the point of having a requirements document, Martin. You get to
voice your disagreement before someone has spent a month of their life
creating something parts of the community cannot live with. So we're
not expecting you to accept this; we're expecting you to let us know
what you think of it.

It's not obvious to me what the problem with this statement is, so
it would be nice if you could outline the problem as you see it.
=20
* Requirements draft
|
| 7. The foundational model shall be 100% compatible with the
| interpretation of the ISO 13250 syntax as defined in ISO 13250.
=20
* Martin Bryan
|
| How can this statement (which has my whole-hearted support) be
| reconciled with the previous one?

Good point. It may not be possible, now that you point to it. Our
original intent would probably be reflected by tacking on ", except in
cases where contradictions in the XTM 1.0 model make this impossible."

* Requirements draft
|
| 9. The parsing model shall be defined in terms of the XML Information
| Set.
=20
* Martin Bryan
|
| Surely this will be insufficient: we will need to extend the
| Information Set to distiguish between topic map constructs.

It's just the requirement that isn't as clear as it ought to be. What
it's meant to say is that the parsing model will describe how to build
instances of the data model starting from instances of the XML
Information Set. So that's the sense in which it's defined "in terms
of" the infoset.

We'll change the wording here to make that clear.

--Lars M.

_____________________________________________________________________
This message has been checked for all known viruses by Star Internet
delivered through the MessageLabs Virus Scanning Service. For further
information visit http://www.star.net.uk/stats.asp or alternatively call
Star Internet for details on the Virus Scanning Service.