From sc34wg3@isotopicmaps.org Sun Jun 2 14:24:51 2002 From: sc34wg3@isotopicmaps.org (Lars Marius Garshol) Date: 02 Jun 2002 15:24:51 +0200 Subject: [sc34wg3] Roadmap to the topic map standards In-Reply-To: <3CF2302B.6070808@emory.edu> References: <3CF211CC.2050005@emory.edu> <3CF2302B.6070808@emory.edu> Message-ID: * Patrick Durusau | | Hmmm, now I understand why the prose was vague. Well, the prose was vague simply because I didn't write very well. :) | Could keep the "lack of rigour" and "suitable foundations" language | or say something like: | | "Implementation experience has given rise to differing opinions on | parts of ISO 13250. One goal of this revision is remove any alleged | ambiguities or other causes for such differing opinions." | | Factually accurate to say there are differing opinions but suggested | prose neither confirms nor denies the validity of any of the | "differing opinions." I've been thinking about the feedback I've gotten and come to the conclusion that the problem really is that the document is too brief. I think I need to expand the text to make it more understandable, and your proposal gives me a good way to explain this particular part, because the problem really is as you describe it. -- Lars Marius Garshol, Ontopian ISO SC34/WG3, OASIS GeoLang TC From sc34wg3@isotopicmaps.org Sun Jun 2 20:25:02 2002 From: sc34wg3@isotopicmaps.org (Lars Marius Garshol) Date: 02 Jun 2002 21:25:02 +0200 Subject: [sc34wg3] New attempt at TM standards guide Message-ID: --=-=-= I've now written a new draft of the guide to the topic map standards. I think (hope) that it is more understandable than the previous versions, but feedback is still very much welcome. -- Lars Marius Garshol, Ontopian ISO SC34/WG3, OASIS GeoLang TC --=-=-= Content-Type: text/html Content-Disposition: attachment; filename=roadmap.html Guide to the topic map standards

Guide to the topic map standards

This document describes what is happening with topic maps standardization right now. It describes the current activities, the problems they are intended to solve, and how those problems came to be. (In the opposite order, for ease of understanding.)

The past

The first substantial result of the topic maps effort was ISO 13250:2000, an ISO standard that defined a syntax for topic maps. This syntax was an SGML DTD, which used the ISO 10744 HyTime standard for linking and addressing, and so the syntax is known as HyTM (short for HyTime Topic Maps).

HyTM is not an XML syntax, is not a fixed DTD, and does not use URIs to refer to information resources. The result was that each topic map software developer made its own HyTM version, derived from the standard HyTM DTD. These things were seen as problems at the time, and in order to adapt topic maps to the web the TopicMaps.Org organization was set up to create a new topic map syntax based on XML and URIs. The syntax TopicMaps.Org created is known as XTM (XML Topic Maps), and solves the problems with HyTM. Today, the HyTM syntax is rarely used, as most people use XTM.

In October 2001 the XTM DTD was accepted into ISO 13250, and so ISO 13250 now contains two syntaxes: HyTM and XTM.

The present

Some problems remain, however. The current ISO 13250 defines two interchange syntaxes, but does not explain how they relate to one another. As the two syntaxes are subtly different, this is a problem, as implementors are likely to map between the syntaxes in different ways, which means that the same topic map may not be treated the same way by different software.

Another problem is that both syntax specifications in the current ISO 13250 are quite informal. For the most part this is not a problem, but in a number of more subtle situations developers have interpreted the specification text differently, and this causes interoperability problems. If different implementations interpret the same topic map differently topic map applications may only work with a single implementation, which defeats the purpose of having a standard in the first place.

ISO SC34 has also resolved to create two new topic map standards:

ISO 18048: Topic Maps Query Language (TMQL), a query language for topic maps. This language is intended to be a kind of SQL (or XML Query) for topic maps, and will greatly simplify topic map application development by making it much easier to extract information from topic maps. A requirements specification has been created.
ISO 19756: Topic Maps Constraint Language (TMCL), a schema or constraint language for topic maps. Using TMCL one can write schemas for topic maps that constrain what is allowed to say in the topic map, such as "a person must be born in a place," "a person must have at least one name," and so on. A requirements draft has been created.

Both of these standards need to explain how the constructs in them are evaluated, but the existing ISO 13250 does not provide a suitable basis for such definitions. For example, when TMQL defines the "find all base names of topic X in scope Y"-operator it needs to explain carefully and formally what that operator does. This could be done in terms of the XTM syntax, but it would then be difficult to see how to apply it to the HyTM syntax. The explanation would also become very involved, as XTM provides many different ways to express the same thing, and merging must be performed before queries can be done.

So while the community is generally satisfied with the two syntaxes, their specifications are in need of improvement on three counts:

Not all developers interpret them the same way.
They need to clearly relate the two syntaxes to one another.
They do not provide suitable foundations for the TMQL and TMCL standards.

ISO SC34's solution to this is the topic map data model work that was started in May 2001, and is now beginning to produce tangible results, in the form of N0298R1 and N0299.

The future

ISO SC34's current plan is to revise ISO 13250 into a multi-part standard. A key part of this new edition of the standard will be what is known as the Standard Application Model (SAM), a formal data model for topic maps. This model will be based on the same formalism as the XML Information Set. This model will define the allowed structure of topic maps, as well as how to perform key operations such as merging and duplicate removal. The SAM will allow SC34 to solve all the three problems described above.

The problem with the interpretation of the syntax specifications will be solved by writing new syntax specifications based on the SAM. The new versions of the syntax specifications will describe how to build an instance of the SAM model from a document in a given syntax. This will be done very formally, in a way that leaves much less room for interpretation. (The syntaxes themselves will stay the same. The only thing that will change is that their interpretation will become much clearer. DTDs will still be used to define the syntaxes; SAM is only used to define their interpretation.)

Rewriting the syntax specifications in the way described above will also solve the problem of how to relate the XTM syntax to HyTM, and vice versa. The SAM will now serve as a common point of reference for the two syntaxes, and comparison of parts of the syntaxes can be done by comparing the SAM models they create. This solution will continue to work even if new topic map syntaxes are introduced, and it provides a way to relate non-standard topic map syntaxes (such as LTM and AsTMa) to the standard ones.

The SAM provides a much more suitble basis for TMQL and TMCL, since it unites the different syntaxes and provides a much more convenient basis for operator definitions. Defined using the SAM the "find all base names of topic X in scope Y"-operator would become something like "traverse the [base names] property of topic item X and return all base name items whose [scope] property contains topic item Y". (In practice the definition is likely to be somewhat different, but this is the basic idea.) TMQL and TMCL will then also be applicable to any topic map syntax that has a mapping to the SAM model.

Canonicalization

Although the new specifications will be clearer than the previous versions there will still be necessary to verify that implementations actually do conform to the specifications. This is best done by creating a conformance test suite, much like those already created for XML and XSLT. It is easy to create a set of topic map documents in the XTM and HyTM syntaxes, but harder to define what their correct interpretation is.

One way to do it is to create a so-called canonical syntax. In this syntax, every logically equivalent topic map would be represented as exactly the same sequence of bytes. This means that in order to see how a topic map engine interprets an XTM file, one could import that file into the engine, and then export it using the canonical syntax. The test suite could then consist of a set of XTM and HyTM documents with their corresponding canonical representations, and conformance testing could be automated.

The new ISO 13250 standard is going to contain just such a Canonical Topic Map syntax. It is expected that a conformance test suite will be developed, either within OASIS or within ISO, once the necessary infrastructure is in place. There also exists an early proposal for such a canonical syntax.

The Reference Model

The new ISO 13250 will also include a model known as the Reference Model, which is a more abstract graph model of topic maps. In this model, names and occurrence resources turn into topics, and they are related to their topics using an association-like structure. The result is a model that uses fewer constructs than the SAM, and which can be extended without changing the metamodel.

The Reference Model provides a mechanism for explaining the relationships between different knowledge representations, such as topic maps, RDF, and KIF. This will make it easier for topic maps to interoperate with these other knowledge representations.

It is planned that the SAM part of the standard will include a normative mapping of the SAM to the Reference Model. The TMQL and TMCL standards will thus relate to the Reference Model through the SAM. Obviously, it is very important that the SAM and the RM are consistent, and much work will go into ensuring that this is the case.

Overview

Below is shown a conceptual diagram of the relationships between the different parts of the new ISO 13250, as well as TMQL and TMCL:

The parts of the new ISO 13250 standard will be:

Part 0: A guide to the structure of the standard (Lars Marius Garshol)
Part X: The Standard Application Model (Lars Marius Garshol and Graham Moore)
Part X: The Reference Model (Steven R. Newcomb and Michel Biezunski)
Part X: The XML Topic Maps syntax (XTM) (Lars Marius Garshol and Graham Moore)
Part X: The HyTime Topic Maps syntax (HyTM) (Lars Marius Garshol and Graham Moore)
Part X: Canonicalization of topic maps (Currently unknown)

Meanwhile, at OASIS...

In order for topic maps created by different parties to merge correctly it is crucial that these parties use the same identifiers for their topics. This is unlikely to happen by itself, however, and therefore three Technical Committees (TCs) have been formed within OASIS, in order to work on something called published subjects. These are URIs and descriptions for concepts considered important by some publisher.

The three OASIS TCs are:

Published subjects TC: Creates guidelines and recommendations for how to create, publish, and maintain published subject sets.
XML Vocabulary TC: Creates a vocabulary (or ontology) consisting of published subjects for the domain of core XML standards and technologies.
Geography and languages TC: Creates published subject sets for geographical and linguistic concepts. These published subject sets will be based on existing code sets such as ISO 639 and ISO 3166.

The published subjects activity within OASIS will layer on top of specifications produced by ISO SC34, and will not in any way interfere with what SC34 is doing.

--=-=-= Content-Type: image/png Content-Disposition: attachment; filename=roadmap.png Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAdYAAAFiCAYAAABLQfk5AAAABGdBTUEAALGPC/xhBQAAAAZiS0dE AP8A/wD/oL2nkwAAAAlwSFlzAAALEgAACxIB0t1+/AAAAAd0SU1FB9IFGwkaFHn8XUMAACAASURB VHic7N13VBRXG8fx72IXK1hRBMSKXbGhIij2qDFFTWJXlMS8ii3RqBGNGo0ttogK9hhLTGyxS1Ow gaLY6CjYsQIiIuz7B5GEiAi47CzwfM7hHJidmfsjcXl27ty5V6VWq9UIIYQQQiP0lA4ghBBC5CVS WIUQQggNksIqhBBCaJAUViGEEEKDpLAKIYQQGlRQ6QBC5BZhYWHcvHkz3dd8ouDxi5TvT+5ex+N7 kVk+f21LW2o3s6Z7jbfvY2pqiqmpaZbPLYTQHpU8biPEm67eS2Sn89w0227FqLkb++5j2/YZjkFF 4yy3GXjOnUA/zwz3qVxChVHJtNs++/p7ahmqstyeECJnSGEVAnB2dmb79u2pPz9+WYhOQ79Ls0/5 qtUxqFRN29HSeHg7gujbEWm2HXaZhWGxf97GAwcOZNiwYVpOJoR4TQqryFdCQ0OJjEzppt21/yhH PX0AaP+JA8279FMymsac2r8Z7z3rAOje0ZpeXW0BMDExwczMTMloQuQLUlhFnnfkyBFOnToFQNQz NffiUrbXa90Z80ZWCibLeUHnvbh+1g1I243crl07OnTooGAyIfIuKawiT/rll1/YuXMnAMZNO1Ox bmsAKhibUzYb9z/zgod3bhB9KxyAO5dPcOtiSsH94osvGDFihJLRhMhTpLCKPCE6OprLly8zZ8lq Im/fxabvV1h2+lTpWLnCmQO/cuJPFwC6dmjLh906Ym1tjZ6ePI0nRHZIYRW53urVq7kecZfQx2ra f+JA6XKVlI6UawVfOMm1M8doUklFu7ZtsLOzUzqSELmOFFaRa508eZLp06dj0X0UFczqU6VGfaUj 5RkPrnqRFObF8ePHOXz4MIULF1Y6khC5hhRWkau87vKdvcSZohVq8uHoH5SOlOct+aoLdm2b06e7 nXQRC5EJUlhFruHs7EzgjXuEPlZj86kDpQyly1dbQvy9uXr6qHQRC5EJUlhFrrB8+XICEypQwawe RubS5auUB1e9SA4/gZ2dHS1btlQ6jhA6Sfp0hE7z9DpBnea2XHtZhcZ2/aSoKqy8hTUVe0zFyflP Tp8+o3QcIXSSXLEKnfTkBez96yBHT12i/YBvlY4j0uGxaQ41S7/i888/p2bNmkrHEUJnSGEVOudl Eiza7oXf2dPY9htNkWL6SkcS6XgRF8ONa34Eu29lm+syihYtqnQkIXSCFFahU4KDg3EYP43iRrXp /eUspeOITNo9bzhL53yHubm50lGEUJwUVqEzrl69ymLXHVj0+IpSBhWUjiOy4MmD2wQeWsM3Dl9I t7DI92TwktAJh68+Zdr8FdTpYi9FNRcqU96Imp2GM2nmAuLj45WOI4Si5IpVKO5ZAnTsYMuole5K RxEaIN3CIr+TK1ahuN/+PIBJ825KxxAaYjP8B+b9spmgoCClowihiIJKBxD5m6enJz7nL2Pbb7TS UXJccnISi0elnbGoTe9htP5goEKJckaZ8kY8VZcgKCiIWrVqKR1HCK2TwioUExgZzYTZK3BYsDPH 23oRF8P/2pbKcJ8BU52p0ciKKjUbaLz96FvhrHDsza2QgDTb67R4+2LjC0bYEOTnmfrz2gsZ37WJ DLrID/2bolYnA7Da9xV6BQq8R+rs6zxoIr8s/w4DA0OsrForkkEIpUhhFYpZsX4Hlp11Z83ULXMc qFitJkNmrqdG4zYaO++DqDDWzxjKrZAAylepTqt/XaHWato+0+fx2bsBq15D3vr6jkXjU4uqLvjo f3P5ZdOPxMbG0LlzZ6XjCKE1UliFIi4/APe/duK4WvsDlgZOW01Fk7RdlJ6/O3Pu8Hbu3Qwm9KKP xgtr8Hkv9PQK8NXiP6haq1G2zuOzb+NbC+up/Zu4ee38e6TMGWaWnTly5DcprCJfkcFLQhHBwcEY VFXmeUeTus2obWmT5mvkvG20+8gegN9//obwy2c137BKla2i2svBidqWNgT6erDX2emN1+NjnhLo 68HzmCdMXKtbI6uL6pfkBYV5+PCh0lGE0Bq5YhWKOL51KXafj1U6Rhr9Jy7hxB9rM73/yT9deXw/ KvXn8lXNadVjQNp9dq8jyM8DALU6mX2rZ6a+Vq6KGa0/GJSptqx6DibQ1yPd1yKDL+K9Zz2tew5G pdKtz8oVTWpx0csQHx8fevbsqXQcIbRCCqvQujuxEPEUcus0EOGXz7Jr6bfcvHae+Lhnqdv1Sxmg Uqlo2f2L1G3ee9YR4u8NgDo5Oc0VZ90WHTNfWHsNYf2Mofjs20gT2w8xrt049bXtCxxT9vlgECqV 6n1+NSGEBkhhFVr34MEDXhUoTmEdm1z/ZtBFAMpXrU5R/fRHEIcFnObHQSmjXKvVaUqxEin7qZOT CTrvhcvUAcTHPsWm71cAGNduwovnsUQFXUSlUlGr2T+DlbLaLWxcuzGRgf4E+nqkFtbIwItEBvpj WNmE4qXKkvA8Nmu/tBYYVDQmPPIOSUlJFFBolLIQ2qRb/UYiXwj09cCwsgnljEyVjpLq6umjrJ6U MkK5/ScOVDark+5+r68O67a04+uf9zBxrTsT17ozYY1bajfwtoXjUvf/fPJyPh23EACVXoHU/Seu dafvhEVZythv4pKUDAvHwd8Tpu1YNA61Wk3rnoOoVqdJls6nLZad+7Ju+36eP3+udBQhtEKuWEW+ s3n2KIrql0yz7UFUKE8e3KZ6g1Y079I/w+PN6rdgiJMrZStWTd2mV6AA/b9Zilqt5uzBrexcMolP xy3QaG7j2o2x6jUEn70b2LZwHNXqNOHm9QtUrdWQNr2HabQtIUT2SWEV+c6Na37pbq/RyIpvN3i/ 9bhdyyYTFnAGs/oteBAVxoOosHT3U6vVRP3draxJxUuWobalDf7uuwny9eBF7DOexzyh9QeDdOrq X4j8Tgqr0Doj83rEul0l5tF9Siqwko31xyMpXa4yAEmvEjngOheAfpN+ztTx4ZfPstDeNsfyZcSq 52B89m4g0NeDyL+Ld79JSxTJklmhF09ha9WUwoULKx1FCK2Qwiq0zqi6BTGPHxDz+IEyhfWjkZhY NANS5u8tql+SP5ZNYfsCxwyvWHVFv4lLmNW/KaCm38TFOveIzX+FXvJhoE0zihQponQUIbRCCqvQ OrMyYFFO6RQp9PQKULuZDQaVjAm56MOPg1oz6qcdGFQyfusx9a26MnblQS2mTMu4dmNqW6aMLq7V zEaxHEKI9On2R12RZzVo252AkweUjgFA9YatGDzDlTLljQgLOM3GmcN5cv/WW/e/HxlCyIWTWkz4 ptcji3V1JPBrTx7cpjSx1K5dW+koQmiNFFahCF0qrAAWrTox6u9Vdq6ePsrjdAqr9UcjqVzdgvuR IQT7v72wJiW9YueSSTmWNTd5+uAOpVUxsnycyFeksApFWFWFehYW3A69onSUVDUaWTFm+V8A/DTc mqjgtEu8la9anVpN2wHwx7IpODQvTKCvR5ovl6kDcLAslKVRwT8Nt8a+iQr7JiqCzntp7hf6j79c 5qS28+eKqTnWzr89uR2Kubm5VtoSQlfIPVahmOlzFrBh5U8kxMdhVr+F0nEAqFCtJjUatyHE35tV Ez9m6H+WkPt88goSnsdx+sAWkl4lKjY6ODc4e3ArTQ1icRj1pdJRhNAquWIVimlctThtm9Un4koO rCSTTRWr1WTYD5uobFaH+zeDWTd9EHfCr6W+rlegIP2/WcrEte4YVbd44/h2fUYwca176mxL+dW5 I9tpUCYW+xHDlY4ihNap1Oq/50YTQiFLly4lTF2NBjZ9lI4iNCDiqi8JF7azYIFmZ54SIreQK1ah uLFjx5IccwffIzuUjiI0IML3CJ06dVI6hhCKkcIqdML/hvSVwpoH/LFsCl992oHOnTsrHUUIxUhX sNAZXl5euO47TeV6bdIMGBK670VcDGd2LWd03w60atVK6ThCKEpGBQudYW1tTVxcHBsOHOXJ/VtY du6rdCSRCWcObiX2djDDellJURUCuWIVOujes0S2bnQhOLEiTTt8pHQckYFzh7fRoHQMrZs3pVmz ZkrHEUInSGEVOmv58uXs2X8Q65ELMDKvp3Qc8S9RwQHcD7tEozKxjBo1Suk4QugUKaxCp8XHx/Pd rPmEPVHR/hMHShlWVDpSvhfi783LoKPUNauCvb290nGE0DlSWIXOi46OZofHZTa4OFOxWk16f/WD 0pHyrZ+/6kKHNs1xmjIeAwMDpeMIoZOksIpc5eTJk0yfPp163R0ob1aPKjXqKx0pzws678WdyyeI unCMQ4cOybqqQryDFFaRK61c5czhi3dRqVRYfzyK0uUqKR0pzwm5cJJrZ4/TuKKadm3bYmdnp3Qk IXIFKawiV0pWQ+itaG6FXGb2ktUUrWDOh6NnKx0rz1jyZWfs2rWkT/eOWFtbo6cnc8kIkVlSWEWe 4O3tzbRp07DoPoriZStRwbgGZStWVTpWrhEVdIm4Z4+4c+Ukt/yPc+TIEQoVKqR0LCFyJSmsIk9Z vXo11yPuEPZEBUBFk1q06PqZwql01/61P6BOTqZGWTUlC0O7du3o2LGj0rGEyNWksIo858UrCAwO 5cGdSDa5B3H20G8ULlo8dRHz/G6xgx3JSUkArJw3jQIFCtCwYUMZ5SuEhkhhFfnC8+fP6dGjBwAW 3UZS3KAy5Y3NMahorHCynPXwzg2ib4UT+yCS60fWAXD06FEKFpTZTIXIKVJYRb6zZs0abt++za0Y Ffefp2yzaNUJ80ZWygbTkCA/LwJ93QGopA+VS6ipVq0aw4YNUziZEPmDFFaRb4WGhhIZGQnArv1H Oerpk/pawcJFcFx5SKloWbJwZAf419u4u501vbrYAmBiYoKZmZlS0YTIl6SwCpGOhIQEunbtmmab nZ0dKpM2PH6R8bHV6jSlWIlSWWqvcgmIiIggIiLirfsYFoOEEE88PDzSbHdzc0OlUmWpPSFEzpHC KkQmHTt2jJMnT75zv6BHKuISs3buppUgM29FGxsbbGxssnZyIYRWSWEVQsMuXLjA06dP39ielJTE t99+y8KFC9M9zszMDBMTk5yOJ4TIYTI0UAgNa9KkSbrb27ZtC0gBFSKvk3nKhNACNzc3IiMj8fPz Y/PmzUrHEULkICmsQmiBm5sbN2/eBGDdunUEBAQonEgIkVOksAqRw44dO8acOXNSfw4PD8fT01PB REKInCSDl4TIQcnJyQwZMuSN7t8CBQrw6tUrhVIJIXKSFFYhcpBarU69Ov33qGCVSkX79u0VTieE yAlSWIXQklevXtGtWzeOHj2qdBQhRA6Se6xCCCGEBklhFUIIITRICqsQQgihQVJYhRBCCA2SwiqE EEJokBRWIYQQQoOksAohhBAaJIVVCCGE0CAprEIIIYQGSWEVQgghNEgKqxBCCKFBUliFEEIIDZLC KoQQQmiQFFYhhBBCg6SwCiGEEBokhVUIIYTQICmsQgghhAZJYRVCCCE0SAqrEEIIoUFSWIUQQggN ksIqhBBCaJAUViGEEEKDpLAKIYQQGiSFVQghhNAgKaxCCCGEBklhFUIIITSooNIBhMgLHsbDy6SU 729ev0B87NM39klKSuLx48d4eHike45yVcwwrGxC5RI5GFQIkeNUarVarXQIIXKDY8eO4e3tne5r gQ8hLjHl++y+pVQqFQBNK719n/bt22NjY5Ot8wshtEMKqxDp8AhLYObwrmm2VW1iRyWLNu88tlqd phQrUSrLbUbfjuDh7YgM97kd4MntSx5pts3Z7IZVVVWW2xNC5AwprCLfCg0NJTIyEoBd+49y1NMn 9bWChYvguPKQUtGyZOHIDvCvt3F3O2t6dbEFwMTEBDMzM6WiCZEvSWEV+c6aNWu4c+cOUc/U3ItL 2VavdWfMG1kpG0xDgvy8uH7ODYDKJcCopApjY2OGDRumcDIh8gcprCJfeP78OT169ADAottIihtU pryxOQYVjRVOlrMe3rlB9K1wYh9Ecv3IOgCOHj1KwYIyblGInCKFVeQ5L15BYHAoD+5Essk9iLOH fqNw0eKMWf6X0tF0wmIHO5KTUoYwr5w3jQIFCtCwYUMMDAwUTiZE3iCFVeQZUTGwc+Nqbt66S+jj lH/WlUxr06LrZwon01371/5AclISNQ1UlCoCbdu2pWPHjkrHEiJXk8Iq8gRvb2/GTJpGs16jKF2u EhWMa1C2YlWlY+UaUUGXiHv2iDtXTnLL/zhHjhyhUKFCSscSIleSwipypWQ1hN6K5lbIZWYvWU3R CuZ8OHq20rHyjCVfdsauXUv6dO+ItbU1enoySZsQmSWFVeRKK1c5c+TSPdRqNe0/caB0uQxmVRDZ EnLhJFfPHKNJJRXt2rbBzs5O6UhC5ApSWEWucvLkSaZPn0697g6UN6tHlRr1lY6U5wWd9+LO5RNE XTjGoUOHKFKkiNKRhNBpUliFzouOjmaHx2U2uDhTsVpNen/1g9KR8q2fv+pChzbNcZoyXkYRC/EW UliFTouPj+e7WT8R+liNzadfUsqwotKR8r0Qf29eBh2jrpkR9vb2SscRQudIYRU66W4sLFiynIsn D2I9cgFG5vWUjiT+JSo4gPthl2hUJpZRo0YpHUcInSKFVeicyCeJTFngQinDijTt8JHScUQGzh3e RoPSMbRu3pRmzZopHUcInSCFVeiUgwcPsuHAWcoa18Wyc1+l44hMOHNwK7G3gxjWqw2dOnVSOo4Q ipPCKnSGl5cXrvtOU7leG2o0fvfybEJ3vIiL4cyu5Yzu24FWrVopHUcIRUlhFTrBw9OTxVvd6PXl TKWjiPfwx7IpTLPvjVVrKa4i/5LCKhQX+Qx6drHl61XuSkcRGuCxaS6DulrSuXNnpaMIoQiZp0wo boPzUtp8OkbpGEJDWn38PzYf9uXUqVNKRxFCEbIoo1BMYmIiy1et5W6hajSx7aN0nDTUyckEnfdK 9zX90gZUrdkwU+e5ef0C8bFPAahWpwnFSpTOcP/IQH+exzxJ/bm2pc072wj084S/O55qW7YHVJnK llOK6pekeEVzfP0DaNGiBQUKFFA0jxDaJl3BQjE+QdGMGf0lDgt2Kh0ljaunjxLk58lfLnPSfb2C cQ1a9RiAnl4BethPe+t5rp91Y/2MITy6GwlAuz4jGPT92gzbXjC8/T8FXaVi7fnkDPf32beR9TOG phbWNX5JqHRkwvyzB7fS1CAWh1EjlY4ihFbpxjtQ5EuL5sygl4OT0jHSCAs4zcaZw99aVAHuR4aw 19mJ/S4Zr6Zz7ezx1KIK4L13Q9bCqNVsXzguw11O7duYWlR1TYtun3MlpgyrVq1SOooQWiVdwUIR PlFw5epVuo3TnRmVQi76MH9IymM+5o2smLzB+419XiW+5OevugBwO/TKW88V9+wxj+7cRKVSUatZ e6JvhfP4XhRRQRepWqvRO7OUMzLlecwTAn09eHg7AkMj0zf22bd6FtfPuWNcuzGRgf6Z/C21q4yR OaHnzyodQwitkitWoYiAkwdo0La70jHS2L7AEQCLVp1w+GlHuvsULFSYiWvdmbjWnU8cf3rruW5c 9eX0gS3oFSjIxLXutOoxgOTkJHYsnpipLFa9hlK1ViMiA/3x2bfxjdcf3rlBoG/KKOp+E5dk6pxK KF2+Mk/VJQgKClI6ihBaI4VVKEIXC+trFq06UaZClXfuZ9VrSLrbk5JesXNJ+gX0xjU/Tv+1OVM5 MiqYD29HEOjrQb+Ji1GpdPdtXKa8EU8pSWBgoNJRhNAa3X1Hijwr/AlcjVY6xds9iArlRVxM9k+Q nExU0CUAJq5Nuar8cPRsajRuw/Nnj3l4+0amTlOtdmMA9jo7Eejrkea1Bfa2AFSt1VjpQcBCiP+Q wiq07nbYVUqUKUfJsuWVjpLG6ytQz99Xs2vZ5Gyfx/vvrts6LTpgUKnaG+e/fs6dR3dvvvtEKhVW PQcDpOkO9vl7wFKtZu0pV8U02zm1xbyhFW4+50lISFA6ihBaIYVVaN3t0CuULFuekgYVlI6SRpu/ ixiA5+/OLLS3Tf3atfTbTJ/H5+/Rv3VbdMSgkvE/508trG48vJOJwso/xdjnXyOKX39f27I95YzM Mp1LKeaNWuPu48fLly+VjiKEVkhhFeJvhYvpM2XTKWpb2lCkmD6Bvh6pX4c2/IR9ExX2TVTMHdiS QF8P4uOevXGO6FvhxMc+Rb9UWQwqV0v7okqVOiI4s6N4a1va0HPUDAAW2tuyb/VMAn09qNWsPb0c ZF5lIXSRFFYh/qV6g1ZMXOtO3/GL6DlqBj1HzaDHiKlp9gm/fDblKvbnb944/sSfa7kdegUTC0ta dR+Q5jU9vQL0Hb8QgO0LHTOdqbalDYZGpkT/PWAJwKrX4IwPEkIoRp5jFVpX29KGh38tIPp2BOXS eT5TF7T7yD71e3VyMnVb2gGQlPiSJX8/x+q1ay1F9UulPnYTceUcpw/8mqnzJycns2PRBPpOWPTO fWtb2lDOyDT1mVaANj2HZOG3UZbvkR0M6/cBxYsXVzqKEFohhVVoXfny5SmY9JyX8XFKR8kUlZ5e mjl7v9t8BudJn/Lo7k2igi+lbn89KQSkTIto3ySD4bpqNVFBFzOdYeJa99TzTVzrDqrcMxT40b1I zOrWkjmDRb4hXcFC6yqXANOM56LXaWb1W9Cy2+dptiUnJWX6+dTXHtwKI8gv/Yn+0/O6azq9WZiE ELpDrliFIjp+PpYlixYwaPoapaOk2r7AkX6Tfs7WscnJrzj91xYAPp+8AiPzjKdq/O2nMdwKDiDo vCe1mllnqg1dm1c5M+7dCKKC6iFWVlZKRxFCa6SwCkXUrFmTR1HBSsdII+SiD/ZNVLT/ZBQtu31B zabt3tjn5rXzXDt7jIPr51GwcBEcVx4CIDIwpVu3XBUzalvavLOw1m7WnlvBAUTfiiA+9uk7l5PL rV7ExVCUlxgaGiodRQitkcIqFFG/PNj2+BTfozuw7NRX6ThpeP6+mpO7170xGhjgxB8uPL4fBfzz XCr8M89wuz727yyqAP0m/ozbthV471lHm15D0i3ieUG47xEGde2sdAwhtEoKq1DMVEd7tm5YywX3 P3ViofN+k35OXd0m6VUie52d3rqv9Uf2fJzBJPwC/lj+HdOG98TKqrXSUYTQKimsQjGVShWiWaN6 XPzrDAnxcRQppq9onhqNrFh7IWVt0y1zvuRuxPU39vliykoqV7dIs+3EH2spWLgIXQZNpPvwKZlq S69AAaZv9WPH4gnsdXZiwprjABjXboxKTw9DI5NM5y5eosw/o5Z1YLDwi7gYzvyxnOkjetK6tRRV kf+o1GodXSVZ5BsHDhzgN/fLtP/izQkXRO4TcdWXhAvbWbBggdJRhFCEPG4jFNe9e3csmrRk76oZ SkcRGuC/dxUODg5KxxBCMVJYhU74qkdjCr54wJP7t5SOIrLp0d1I9i8cyc71KzA3N1c6jhCKka5g oTOuXr3KYtedPEkqRtch0i2cmzx5cJvAQ2v5xuFzatasqXQcIRQlhVXolODgYDZ5hODve4reX85S Oo7IhD+WTSbpSSS/LJglV6pCIIVV6CgvLy9c952mcr021GjcRuk4Ih0v4mI4s2s5o/t2oFWrVkrH EUJnSGEVOuvgwYP4nD7Dff26NO/cT+k44l/OHPiV2LshDOtpRadOnZSOI4ROkcIqdNqrV69Y4eyC 88btDJ7hQvmq0tWotLOHfqNhmTisWjSladOmSscRQudIYRW5wpVomDluBImqQtSw7oephSVFipdQ Ola+8ejuTR5EhXF+2xz6fvoJo0aNUjqSEDpLCqvIVa5fv862bdu4/lBF6aq1ad6lv9KR8ry/XOZQ vugrjEqomTZtGgULyoRtQmRECqvIlU6d9eWXvb6cO7ydQd+vpYJxDaUj5TlnDm7lxB9rWf7jVMyr V6d69epKRxIiV5DCKnI9e3t7ol8UoEb7/tJF/J5ed/n6/Tabz/r3w97eXulIQuQ6UlhFnvDvLuL4 V1CvdWeqN5QJ4DPr9F9beBAVSkV9pMtXiPckhVXkKb6+voTei2XjH4cJu3Qa80ZW9Pl6jtKxdNZi h04kJ71ijP0ALGqZU61aNenyFeI9SWEVedarZPjlTx/+XDEVvYKFadovZUk3E4tmFC1eUuF02hUf +5Sb1y8A4PfbD6iTkwE4evSoXJkKoWFSWEW+kJCQwI8//ghA4EMVz1+BRatOmDeyUjhZzgo670Xg OXf0C0Etg5S3+vfff4+enqy/IUROkcIq8h0/Pz9iYmLYtf8oRz19AGj/iQPNu+SN2Z1O7d+M9551 AHTvaE2vrraULl2aJk2aKJxMiPxBCqsQgLOzM9u3b0/9Wa9AIZr2/y7NPuWrVsegUjVtR0vj4e0I om9HpNnm++ss4J+38cCBAxk2bJh2gwkhUklhFSIdiYmJzJmTdtDT7VgV9+LefWybD4dhUNE4y20G nnMn6LxXhvtU0ofKJdK+ZWfMmIFKpcpye0KInCGFVYhMCgsL4+bNm2993dfXl0mTJlGtThOKlSid 5fP37GJLDzvrDPcxNTXF1NQ0y+cWQmiPFFYhNMjFxYUJEybw7NmzN15r3Lgx/v7+ADRt2pRFixZh ZmaGiYmJtmMKIXKQFFYhNKxNmzb4+Pi8sd3d3R1bW1sAPD09cXNzQ6VSoVKp+P7777UdUwiRQ+QB NiG0YPjw4bi6uqb+PH78eHx9fQkPDyciIiK14C5dupSGDRsqFVMIoQHyMJsQGnDhwgVcXV2xtbVl 5cqVqcVRpVIxYcIEXFxcCA8PT93fz8+PZs2aoaenh62tLe7u7ri7u+Pq6srQoUPx8PDgyZMnSv06 Qoj3IF3BQryn48ePc+LECWrUqMGAAQOAlBmNOnfuTKFChXj58iVubm4MHTr0jcFPtra2rF+/Ps19 1vDwcDZu3IhKpcLU1JTBgwdr9fcRQrwfuWIVIpsSExOxtbXl1KlTjB8/bdq6DwAAIABJREFUPrWo AlhaWjJgwACWLFkCgJubW7ojis3MzHByckp3W+/evVGr1dja2qYOehJC6D65YhUiC5KTk/Hy8uL4 8eOcOXOGI0eOvLGPWq1m/fr1FC5cOLXYurq6smXLFiDlKnXs2LGULp3ySI6joyNDhw6lUaNGb23X 0dGRixcv0r59e2xsbLCxsdH8LyeE0AgprEJkgYuLC1FRUdjZ2dG2bdt093F1daVw4cIMHDgw3den T59Oly5dUo9Xq9XMnDkTW1tb2rdvn2H7Hh4eeHh4oFKpUousEEK3SFewEJlw9uxZbG1t0dfXx8nJ 6a1F1cXFhaJFi761qKZHpVLh6OiIm5sbly5dynBfGxsbnJycaN++PZ6entja2iKfjYXQLXLFKsRb PHr0iEuXLuHi4kKVKlWYP39+hvsfOXIEPz8/pkyZkuF+/71i/bfMdAv/V4cOHVCr1QwaNIgmTZrQ uHHjTB8rhNA8eY5ViHQkJiayfPly1Go18+fPp0qVKhnun5SUxKlTp+jQocN7tbt48WLs7Oxwc3PL 9DGv9924cSO7d+9mz549DBo0CDMzs/fKIoTIHrliFeI/Vq9eza5du1i0aBENGjTI1DFjx45l+PDh mZrcITw8nFmzZrF+/fp0X9+wYQMqlSpbj9k8ffqUCxcusGnTJkqUKMGyZcuyfA4hxPuRwioEEBoa SlhYGHPnzmXUqFH0798/U8c9evSIJUuW0L9/f+rVq5fp9l5PCvE269evR09P772eYQ0ICGDMmDFA SvezmZmZXMUKoQVSWEW+FxwczK+//krhwoX57rvv3n3Avxw+fJjz58+/877qf72rsML7Xbn+1w8/ /EBSUhIqlYrp06ejpyfjFoXIKVJYRb7m4OBAcnIy06dPx9g4a2uoJiYm8uWXX/L9999TrVrWFkDP TGEFzRbXGzduEB4ezg8//MBnn33GiBEj3vucQog3SWEV+Y6fnx9+fn789ttvODs7U7t27SyfIyws jNmzZ7Nu3bpsZUhKSqJLly4cO3Ysw/38/f3Zs2cPY8eOpUyZMtlqKz1btmzB1dUVY2Njhg0bRsOG DTEwMNDY+YXIz6SwinzlyJEj+Pj4UKtWLT7//PNsnSMkJIQtW7YwYsQIqlatmq1zZLawQsqkEJ6e nsyYMSNbbWUkMjISV1dXVCoVVatWZfjw4RpvQ4j8Rm60iHzh+fPn2Nra4ufnx4QJE7JdVCGlsBYt WjTbRTWrbGxs6N27N46Ojho/t7GxMU5OTvTp04ciRYpga2vLuXPnNN6OEPmJXLGKPCspKYkTJ05w 5MgRLl68yF9//fXe5zx79iy7du1652QRmcmW2SvW1/z9/dm9ezeOjo4a7Rb+r2+++YY7d+6kXr1a W1vLYCchskAKq8izVq9ezZ07d+jSpQutW7d+7/MdO3aMM2fOMHXq1Pc+V3JyMrNmzaJDhw5YW1tn +riZM2dqZY7gqKgoXFxcgJQpF9u0aYOdnV2OtilEXiEfQ0We4+3tja2tLQYGBjg5OWmkqJ49e5Yz Z87wv//9TwMJQU9Pj3bt2uHp6Zml4wYPHszGjRtzfH7gqlWr4uTkhJOTE7a2tpw5cwZbW1sSEhJy tF0h8gK5YhV5QnR0NJcvX2b16tVUr16dOXPmaOzc8fHxfPzxxxw4cEBj54SUBdJ9fHyYPn16lo8d OnQoM2bMwNTUVKOZ3qVLly40b94cOzs7SpUqRdOmTbXavhC5gcwVLHK9Fy9esHLlStRqNUuWLKFS pUoaPf+vv/7KF198odFzvi8nJyfWr1/P4MGDtTqb0uHDh/H29ubo0aMA7Nu3j88//5yaNWtqLYMQ ui7PFtbDYfAqOeX75WM+ICE+Lsvn6OUwk2atrbHO2rP/QotWrFjB/v37WbhwIfXr19f4+VevXk2p UqX47LPPNH7u92FiYsKQIUOYOXMm69atQ6VSaa3tNm3a0KZNG2JiYvDz82PBggXo6enh7OystQwi 571MgqPhKd/Hxz5l5bgPs3WeQd+70KCOOZaVNRhOx+WaruCI+zFEXPVLs+2X9b9x6WrQO4/937J9 FClWIstt7l01g6DzXhnuYz/gE5o1+meO2MLFilOvcQtKF8lycyKTQkJCCAkJYf78+YwePZpPPvlE 420kJyezbt069PX1c7Sofv/993Tq1Il27dpl6/jx48czcOBAmjRpouFkWXP9+nW+/PLL1KtXY2Nj zM3NFc0k0kpWQ0jkfW6HXU2z3WnBSu7ej87w2GIlSjN6ye5stbtx1ggeRIZmuM9Ux5EYV/mn8pYo Y0jdeg3QL5StJhWns4V169atBAcHp/7sfw+SktNGbdntcyqa1NJ2tDR8j+7kduiVNNvKF1dRrfQ/ P3/88cc5cjWVH12/fp1t27ZRrFgxvv322xxr5/nz53zyyScav6/6X+9bWCFlpLC1tTW2trYaTJY9 W7duJSgo5cOuSqViypQpFC5cWOFU+deKFSt4+PAhAIlJEPCANwa+dej3NSXKllMiXiqvXat58uBO mm1VS6moqP/Pz/b29hgZGWk5WfboVGGdPHkyZ86cAaCm7eeUNvrnvk1R/ZKY1G2mVLRMe/niOeGX z6bZFnZyF49uXAZg2rRpdOzYUYloud6IESMoVKgQU6dOzfHJGcaMGYO9vX2ml43LLk0U1qdPn7J0 6VJ69uyp+JXra5GRkYSGhvLjjz/y4Ycf8uWXXyodKd8YOHAgUVFRANTv9TVFSxqmvlbKoAKVq1so FS3TYp885FZIQJptVw+u5fmj2wCsWrWKOnXqKBEtUxQprJcuXeLRo0cALHf5lSuBIQB8PGYeZg1a ajuOVu1f+wPXz6YsTD38849o3iTlD3fdunWpWLGiktF0kq+vL76+vmzfvh0XF5cc7158+PAhixcv ZuDAgVp5465bt46CBQsyaNCg9z7X+PHjGTBggM6N1N2xYwerVq1KvXpt0KABhoaG7z5QZOjMmTPE x8cD8P385dyPTvmbOnz2ZspW1M6sYErZMseBuxGBAEweMwJT4yoANG3alFKlSikZDdBiYd2yZQuh oSn97CGP1Dz9+3G4Vj0GUMG4hjYi6Jzzx3cRFZzyqcysjAqDYinb+/Tpk6kFs/O6gwcPcubMGerW rUu/fv1yvL3ExETmzp2LnZ0dbdq0yfH2XsvsSjfaPpem/fjjjyQkJKBSqahUqRKjRo1SOlKus2zZ Mh4/fgzAlQdqXrxK2d7xszHol86fiyic+GMtj+/fAqCOoQr9v+88DB8+XGvTjv5XjhfWzp07k5iY SK0OAyhVOeVqo2rNhvn2H8Hb3Am/xrOH9wAI9/6DhxEpBfe7776jU6dOSkbTumfPntG7d2+6devG 6NGj0dfXf/dBGhAXF0ffvn01MvVhVmiyGG7atIlXr14xbNgwjZwvJ1y+fJmAgADWrFnD7Nmztfoh Jje6f/9+6gfLBr3HUKREWQCqN2hJoSLFlIymc25eO0983DMArh12IS46peCuXLkSCwvtdYHnSGH1 8vLiwDEvdh88zrhVRyhQMJcO7dIBB1zn8iDYlx8mj8nT3cWJiYl4e3tz8OBBrl+/zp49e7Tafmho KHPnzsXV1VWr7YLmrzI3b97Mq1evGDJkiFYfw8mOqVOnEhYWxqhRo6hfvz7lyik7iEZXvHjxgtOn T7Npx14CQm8xav52pSPlar/+OJqyhRIYM2KAVrqLNVpYT5w4gZubGxfuqjFv0o66LWSQjibEPXvE 8a3LMC2jooZRWcaMGaN0JI375ZdfuH//Pt27d6dFixZabTs4OJhff/2VkSNHKjLqMCe6bzdt2kRS UhJDhw7V6Hlzwt27d3F2dk79ENCyZUu6du2qcCrl7Nmzh7N+/gTcV9PYpjfV6ujGgLTc7n5kKKf/ 2kxtQxWN6pozYMCAHGtLY4XVzs6OCnWtqNKoA7Watdf5T8q50Z3wazy4cZ2APcuYMmUKnTt3VjrS e/P09MTJyYkxY8bQp08frbcfHx/P2LFjmT59OsbGxlpvH+D8+fNs2bKFxYsXa/S8mzdvJjExUae7 hf/t8uXLREdHc/r0aQ4fPsy+ffsoUSLrz5/nVvfu3aN///6YtupN5bqtqN6wldKR8qSb1y9wL/g8 QW5bWLFiBfXq1Xv3QVn0XoXV09OTA8e82HPIjfHOR9ErkGcnctI5B9b9yP3As8yeMpY6depofBq/ nPTgwQOuXLnCL7/8goWFBU5OToplOX36NHv27OHHH39ULENycjKdOnXi+PHjGj1vQEAAv//+O46O jpQtW1aj59aGnj17Uq9ePbp27Urbtm0pWDDv/X153eW7cfseroTfYeS8bUpHyle2zvua0gXiGWuf MslK6dKl331QJmS7sG7atIldp8Ko2cSaOi06aCSMyJrnzx5zbOtSTMuo+GGKo8b+UeSkuLg4Fi5c iFqt5quvvqJChQqKZTly5Ai+vr589913imWAnCuskDLewd3dnenTp+fKNVXPnDnDwYMHU3vA+vbt S926dRVOpRm7d+/m7PmLXL6vponthxjXbqx0pHzpQVQoNz03Y1SqQLYWxEhPlgtrQEAAY8aMoVbH gVj2GCpdvjrgbvh1Qv5aygaXVUpHydDPP//M0aNH+emnn3Kk+yUrTp06hbu7O//73/8oWbKkolly srACXLx4kXXr1rF06dIcOb82eHt7k5iYyPbt23n58qUig8w06dChQ+zwCqRS3ZZUbyBdvkorWRiC Anxxc57E8OHD3/v+a6YLa+xLuHr5IlMXraffpJ/fq1GheU+j73J513wG9+tNq1atKFq0qNKRgJSB QUFBQSxcuBBHR0d69+6tdCROnTrFvn37mDt3rtJRUrm5ueHt7a2xT8z/FRAQwM6dOxk3blyu7Bb+ t7CwMIYPH07fvn2xtLSkefPmSkfKtOvXrzNszGSM6ram69Ccm5JTZN/J3a5YmxVh2ODsF9dMFdbY l+Cy2ws3Nzd6jvoelSr3dSnlB5GB/lxw303bmmX4ZoKj0nG4cuUKO3fuRF9fn0mTJikdJ5UuTqKQ 04UVYM6cObRs2RI7O7sca0ObduzYwdWrV1N7zSZNmkTx4sUVTvV2/v7+LN24m6YfjaNYSd2/bZOf ee9ZhymR2NraYm1tneXjCzhlYuRIx44dufssCbsvHClcVHf/4eZ3pctVoralDTfuPeH88d9p27at YlkGDx7MpUuXcHR01KlHJ1atWoW1tbXiXdH/FR4eTmRkJO3bt8+xNkxMTFi5ciU9evTIlfdb/6te vXo0b96cQoUKYWpqiqOjI9HR0bRqpXtdq/369cPrYhjNPnakRBl5VlfXGdduTGIyBJ1zo1y5clme PyDDK9YbN24wZvJMPvjGRa5Sc5krPoep8Pwa47520Fq38NmzZzl37hy///47GzZswMTERCvtZkZS UhKurq6UKVOGvn37Kh3nDdq4Yn1t2LBhTJ8+XasLpGvLn3/+ybJly5g0aRI1a9ZUfAH2u3fvMtlp Hg37TqGUQd6c3CWv277AkYXfDKVRo0aZPuathfXGjRv8uGIDpjaDKFcl770B8wN/jz1USwrXSrfw /v378fX1pX79+jmyPur7WrNmDSVLltS5BctfCw8PZ9OmTQwZMiTHP5BERkbi6urKwIED8+yaqQsW LCAuLg6VSkX58uX56quvFMmxbt06vG8XpPUH77/IglCGWp2M54ZZjPy4Q6a7hd96GTrmWydMbQdL Uc3FGtv05r5+XebNm5djbTx69AhbW1sCAwP55ptvdLKoAvz22286W1QBzMzMSEpK4saNGznelrGx MUOHDmXu3Lm8evUqx9tTwqRJk7C3t6d9+/aUL18eW1tbPDw8tJrh9u3bHPS5TL3WXbTartAslUqP ivXa4enpmelj0i2sqw9cJK5AacoZmWoqm1BInVZduFeqCXMX/MyLFy80cs6XL1/i4eHBxIkTsbe3 x93dnQkTJujkwJGHDx/y3XffsXr1aqWj6BQTExMMDAzw9/dXOkqOqVKlCjY2Nnz66ae4u7vj6elJ 37598fDw4P79+znefs9PvqDL14spZShdwLld3RYdCUuugsv6TZna/43C6unpidfhP+k/cYnGwwll 1LPqwgHvS9y5c0cj51uzZg0eHh589tln7Nq1SyPnzAkJCQmsWLGCnj17UqtWLaXj6JwFCxZw8ODB HHt+VtfMmDGDlStX4uHhwapVq1i5cmWOtfXnn39Sv732p+gUOadN72H4RCaxcePGd+6b5h7rxYsX +cn1T1p+6kjxkmVyNOS/3Qm/xq9zU+6BOK48RMHCRTLcf+nX3UlMiKfP13Mxb9Q6S23djwxl06wR 2co5esluipVIGSa/cnwf4mOeAGBY2YShszZkeOyju5Gsm55yn6VsxaoMn705Wxmy627EdYL2/cwm V+dsn+P48ePMnj2b8ePH07NnTw2myxn/+9//UldNyQ0iIiKYOXMm69ev11qbz549Y9myZXTp0iVX PQ/6vq5evcrVq1dTi+uuXbswMNDMUpYHDhzgd+8QWvQe9c6/Ze/r6uljHHCdk+Xj9EuV5ctFfwAp M7j9MuGj1NdqW9rQc9SMDI8P8vNir3PKPjWbtqP3l7My3D/kwkl2/5J2YF7hYvqMWbY/3f1DL57i zxXfUahIMcauOPDO30db1MnJbJv07slc0ky+uWyvP4XLmWi1qAK8iHtGoK8HAMnJSe/cP/jCCRKe xxL7NDrLbSXEx6a2lVVJiYmp34f6exPz+AGQUljv3QymYrW3j0CcO7AFT6PvAlDRRPtXT5VM61D8 i5kMcXBkntPkTM8tfO/ePa5du8by5ctp0qSJzj3/+TahoaHEx8fnmqIKYGpqSkREhFbbLFWqFNOm TUt9zji/FFcLCwssLCxSxwR89NFHVK9enQ8++AArKysKFy6crfM+fBbPRrdAqpjXy/GiChDz6F62 /p6VMvzn/f8q8eUb52j3kT1lyqe/0lPsk2gWjPjnsbC3ra0d+ySaLbMd8Dv+9l4t+yYpzyAPcXKl Te9/FouIfRpNoK8HRYrr1iIMKj092tgvZNK0WUybNPat08imKazeezcwcW3u+MOZXaUNK6b7aSzm 0X08dqZMCdh1yDfpLiBcuFj69xAf3rnBsS1L+OK7X9J93e/Y77x4HvseqTWjlEFFClRtyoEDB95Y 8eTSpUu8evWKpk2bpm6LiYnB2dkZtVrNmjVrMDQ01HbkbAkMDOS3337jhx9+UDpKrrFgwQKdnDhD W/744w98fX3Zv38/np6eNGvWjA8++OCt+2/YsIEhQ4a8sf1s4G1uh16h04BxOZj2H1VqNkj379mt kMucP76LosVL0mng+DdeL5pBwQr09cDffTc2fdMfSe2z991doYkJ8Wyd93VqUa1kWofmXfql2cdr 1+rUi41tC8alKay6rFqdJuxx/5OLFy++dZRw3lsu4h1KGVail4PTG9ujgi+lKaz6pTNXRHqOmsHx rUvx99iDZadPqd3c9o19/I7tQr9UWaw/HsnRzZpdGkwTHjx4QP/+/ZkwYUJqYV24cCFeXl7Mnz8/ V016HhcXx5IlS5g2bRqVK1dWOk6uMmLECNauXYu9vb3SURRhaWmJpaUlPj4+nDp1ikWLFlG1alU2 b37zts2cOXOIjo5m4sSJabYHP9JW2hRVazakas2Gb2w/e3Ar54/vooh+iXT/3r1Nv0k/s32BI8d+ /ZkGbbtjmM4AVp99G6jVzBr90oZccPsz3fNsnuPAucMpi7MP/t4FswYtqVIjbe9RI+sPePE8Fo8d v3DZ53CmM+YGqYOXbG1tmbjGTcks2fb4XiSBvh7cuOr3zn1D/E8S6OtB7JOsdyOnx8jcAtP6LXjy 4HZq1/C/ef6+mnOHt2HeyIpKCnQB/1frDwaxbq83YWFh/2xr3Zpr164xYsQInJ2dsbW1pW7duuzd uzdXFdWQkBDGjh2Ls7MzVatWVTpOtjRq1IiLFy8q0vYXX3yBvr4+rq6uJCcnK5JBF1hZWTFhwgTc 3d2ZO3cutra2LF++nLNnzwIp/51CQkKYNGkS06ZNIyEhIfXYjTNHMHiGi1LR35tZveYYVbfg3s1g El48f+P1rfP+x92IQGo3s6FshSrpnmPbT2M5tW8TJcqUw2Hh77TtM/yNogpgYmFJbUsbRv20g7a9 h2r8d8lJvb+cxcgJb78PrQdwJzZlPuDc6tG9KLbMdmD52J5cyeCTz7nD21js0Ik/lk0m5rFmCiuQ OoLa9+hOEuLjUrfHPonm0omUm/P9JurmwgV79+7l8ePHqT/PmTMHd3d3evTooWCq7Fm5ciWjR49W OsZ7Wbx4MePGaacbMT2ff/45RYoU0eoAKl1mbGyMu7s7RkZGHDhwgJkzZxIQEJD6+pw5c3jwIOUD dcRTePnuISI6rXjJMvR0SCkYPns3pHntdthVIq6cpViJ0vT6cuY7z1WzSTuadfw4U+3mtYVdUgtr TC4urOYNW1PRtBZPo+9w5VRGhXU7iQkvMGvQispmdTSew+/Y7yT8615q7JNoLnmlP+pNFxw5cgQH BwcePdJy/1UO8Pb2pmLFiopPYZcXDBgwgGLFirF27Vqlo+iMjz/+mG+//ZaYmJg0hRVI/SAU8QQS 89CF/n8L652wq4RfPpvhMcHnT6Te2/1wdMYjhfMyPYB9q2em3ADXgbVVR7fWx76JKsOvhHQGAlWp 0QC9AgU4umUJ/p5733j92K8/c8F9N0WKl6CCcQ2NZq5c3SJ14NJC+3/usS4YkfL9yHm/Ubpc5kbh asMQJ1d6ffoFnp6ebzzbGhUV9d5rEWqbt7c3Bw8eZPLkyZQooVujCHOrxo0bc/PmzTzxoUtToqKi WLRo0Rvbf//9dz744APm2ndm+OzMTSCgyyw79cWm71fEPH7A6m9S5tWOfRyN86RPATIc4BrzJJrH 92+hV7AgRua5Z0R+dkxYc5wOHTqk+1qeGbzU5+s5uG1bwYu4ZxnuV6GqOR36f63x9k0tLDEyr8ez R/e4dOIvEhPiSYiPxcTCUif/gb14kUChQoWYMePN+wQNG745GEJXHTp0CH9/f2bPnq10lDzFwsKC Ll26sHz5cqZOnUrBgnnmT0W2GRgYpPt+ee3PP9MfyJMbNWzbHb+jO7kdeoWIK+cI9EuZzq9B2+6U MqigcDrdp3PvlsxMELHs6+68TIh/Y3v/SUvY4DSc3SumUrdFR4oU0wfgfmQI7ttTHgTPqb5803rN MTKvx+3QK1w6sZ/nzx6T8DwWU4tm6d64V1rp0qXJxIqBOu/w4cMMHjxY6Rgao6enx6BBg9i4caPi v1fbtm0pVaoU48ePZ9myZYpm0QWGhoYZvmdCQ0O1FyaHNWjXg5Jly3P77+7f193CDdp2o6QU1ncq CGBoZMqN2xEKR0lRs2m7d675qipQIN3tNZq0o4KxObdCLnPjqi+1mqU8xBxy4ST3I0OoUqM+phaW Gs/82qj52wny88RzZ8rsRpVM6zBgavZnOsopdyMCqVe3ttIx3surV69wcXGhTZs2NG7cWOk4GmVi YsKJEyeUjgGk9F44ODgwbdo0xo8fr7HZifKi4bM34/CJbZ6ZC2CiiwfjO1Rg67yUHr5mdp9g20/z vX251aKRHbl+Lv3/13oAVj0H47NvI7x9adZcoWK1mtj0TRkVun3hPyMrty1MWTat91c/5PhMHlY9 h/zzfa8hb91PSYc2/ITT1G+UjvFeXFxcKFOmjM6uppOXWFhYULJkSc6cOaN0FKFFRYoWx7JTyn3V wkWLY9n5U4UT5R56ALUMwPDNiYZytXs3g3HfvpLdK6eR8Dzu3QdoiFWvf7rv2vTKO12UumTFihWU L1+e/v37Kx0l3/jss8/4448/0jyzKdJqXBGK6tzNtewrXEyfZq8La7HiWHbq+85jajVpR9OOH5EQ F8Oe/8wNnJ/oAZQoDC2aNSYySJkH0zWp04BxNG7fi4TnsdyPDOFWyGWSk15h94UjTWw/zPH2K5vV Ze0FNWsvqNPMx6krnj28R+VypSlatKjSUbIlOjqaqKioPNf9+2+2trYkJSVlaf3HnFatWjXWrl3L V199lWZyEfGPMkVhmJMLG2dmb5EPXWTZ6VPWXlCzxO3NyW/SU6JsOcpWqEpS0isCfT14fD8qU8dF Buau5Qv3rPqeNYve/ixv6sxLS5YsSdN9mps17/oZBQsXISzgNHcjAildrhL1rGSxYYArpw7Tzao+ RkbpT7Cty+Lj41m5ciV9+vTB3Nxc6Tj50qxZs9i0aRPBwcFKR9FJNeUWNPXbdKWUYUWCL5xk0yx7 nj28m+H+V3wOs+bbvNX7lO5C57ldi679KVS4KGGXTnM34jqlDCtR36qr0rEUV6wgNMrFay5PmjSJ jz/+mJYtWyodJd+qUqUKw4YN46effpJu4XS0qG2EkXk9rp46onQUxdRv042RP/4GwGXvQywf05Pd K9/sFt70gz0L7W3ZOGsET6I1s1a0Nty8foE65QvSqFGjt+6T5o7Adpef+cnVSevrseYE49qNCfr7 2atJaz2UDaMjLpw8guHjW4yZMkXpKFkSHR3NwoULGTdunFyp6oBq1aphaGiIv7+/fMj5D8NSxRjc oTa/e1/n1cv2Wlk6ThfVbm7LN+tOsHbyZ0Rc9SXiqi9/ubz9WfNaTdNfJSbheWzq0nJvU7hocVae 0s44GnVyMt5rJ75zPdY0V6yNGjWidjk9bl6/kKPhtKHf3/P3ihT+HnsoH3uVKbmsqAKcOHECIyOj fFVUbW1t8fDwUDrGW82bN49jx45x9OhRpaPonO7du9PT0phTf65WOoqiajZpy6Dv19Jt6Lfpvl6w cBF6jppBz1EzGDl/m5bTZc+p/RsZNGjQO/dTqdVpn7GJiIhg7OSZfPDtOlRamuLwRdwzblw7D6R8 clHpZdxDHXzhBMlJSVSp0YASZdJf3m3BCBuC/Dz5cPRsug39Fr0JfS4hAAAgAElEQVQCGQ/XS4iP I+LKOQBqNG5DgYKFMtw/5KIPSYkvMTKvR8my5TPc97UnD25z70YQhYsWx6x+i0wdowlXfA5TPu4a 4//nkOsGLcXExPDNN98wbdo0qlRJfzWNvErX10eNiYlh+fLldOjQgVatWikdR+c0s7Lly1+U+f/3 7NF97oRdpWChIpg3ap3hvkmJLwm56AOAWf0W75xH4LX7N4N5fP8WJcuWx8i83lv3S056RfCFk29s 1ytQkJpN2qZ7TOyTh9wKCUj3tTfOo1eAmk3bZWrf9+G9Zx1tqhVkxNBsFNbXevcfSutBMyiXznp8 uu5WyGV+HNSK4qXKMnLeNmo0bqN0JMUkvnzBud2r+bRdLbp166Z0nCwJCQlh/vz5+XYyeF0vrK9N njyZDz/8UIrrf9y+fZux3y+k9WffUsowFw9uEFw7e5wy93yYPj1zjxC99dJwwldD8d6zTmPBtGn3 iqkkxMfRzO6TfF1UAU79uZpeLUxyXVG9du0aW7ZskTmAc4F58+blylsMOc3IyIhuVvUzXHFL6D61 Opl7V07Svn37TB/z1sLaqFEj6pQvmOvut/oe3UnIRR8qVKuJbb/cvTbn+zq0fj792tXmww9z/vld Tbt27RqGhoZUrJh/P+kvWbJE0bVZs2LUqFE4O+ve9J1K6969O0lR53n26J7SUUQ27Vg4nknDPsTa Ov0BVul5a1fwa+PHj+dMyEN6OjhRzsjsvUPmNN+jO/HY8QsVqtVg0PT82YUYFnCau9fO0Ne6Nl27 5r7HjLy8vDh27BizZuXf9RwB1Go1HTp0yBXdwQDbt2/n2bNnDBs2jAJvmc87v+rXrx/JJY3+7hbW vYljRFpqtZpH1zx5HujOJ598QoMGDbJ0/DsLK8CxCzf4fet6TG0GU66K7hfX/OyC+25KP/anRdPG ufJK9eDBgwQEBPDNN7l7LmNNyG2FFWDr1q3ExcVhb2+vdBSd4+/vz9KNe2j6kSPFSpZWOo7IgPee dZiob9KhQ4csXam+lqnCCnDjxg3GTp5JDCX47FtZQkoXXfY+RMX4QMZ9PSrXjf6FlCvV06dPM3r0 aPT19ZWOo7jcWFgh5cr18ePHODg4KB1F51y/fp1hYyZjVLc1Xd/yGIpQ1sndrlibFWHY4AHZPkem Z14yMTFh92/r+Pk7e9xcZxDo60Ema7LIYXfDr7Nz2odUjr3IlIljc2VRTUxM5MqVK9SsWVOK6r+Y mpoSERGhdIwsady4MZGRkTx8+FDpKDqnTp06+BzZzYhujfDZsZSwgNNKRxJAycJwJ9CXX8fZYlfj /YoqQAGnLK52XbFiRcqXKMCti+54eXmhTk6W7mGFPH/2mEMbfqJQ9GVWLZlPx44dlY6UbatXr6Zc uXKyDNy/qFQqypQpw549e7CxsVE6TqaVK1eOYsWKsW3bNqysrOR+azpq1KiBOuYut66c5KSXJ8VL lqF0Obn3qoQHUaFc3L2ckrGhrFu3joYNG773OTPdFZweT09PDhzzYs8hN8Y7H33nJAxCcw6s+5H7 gWeZPWUsderUoVKl3PumXLp0KdWqVaNPnz5KR9E5Hh4eeHp6MmPGDKWjZFlAQABr1qxh+fLlSkfR WS9evOD06dNs3L6HK+F3GDkvd8xAlFdsnfc1pQvEM9Z+IE2aNKF0ac3c+36vwvpvdnZ2VKhrRZVG HajVrL3WZm3KT+6EX+PBjesE7FnGlClT6Ny5s9KR3tvvv//O3bt3+frrr5WOopNyc2EFCAoKYsOG DUyYMAFDw/RnSRMp7t27R//+/TFt1ZvKdVtRvaFMuJETbl6/wL3g8wS5bWHFihXUq/f2WaOyS2Or 2xw7dowv+3ZCP8qDv9bM4trZjCcpFpkX9+wR+1bP5MGZ7dTQi8Td3T1PFNXnz59z5coV/t/encfl lP0BHP9ECS0olRaJStmS7HvZ92UsZRjLWCfxE2VfQpkhZJDsxjAz9uw7ZV8m+xKyRmmxRVqQfn80 ntFU2p6n+1Tn/Xp5vXruPfeeL6rvveeee7716uXd8o5C3qpcuTK6urqcPXtW6lCUnoGBAQEBAXRr UBGV+wfZs2JmvltHQJlFPX3AnhUzib+xi6YV1QkICFBIUgU53rF+7eTJk+w/epKdB47h6nc403V3 hYztXzOH6JAgZk8cTZUqVQrUggkjR47E2dlZYd/cBcGbN29YtGgR3bp1y7fF3Z8+fYqnpyc+Pj6U LJm1dWgLuy9DxL9v2c2NB2EMn7tZ6pDytT9+HkkZtURGD+mHnZ0d2traCu1PIYn1a23atOHjx49U btEPbUNzdAxN0TOupMgu860PifE8unEBgGv+PnyMe8vkyZNp3bq1xJHJV3R0NN7e3jg7O2NmZiZ1 OErPw8MDe3v7fDWBKT1Dhgxh0qRJhapKkTxERUXh6OgIQI2uo1HXLEM5MytKlTWUODLl9D7mFc9C rpOc9IlLm7wA8PX1pWrVqnkWg8JnGx0+nFLwd+PGjVwLDuRc0D+zHfWNadp9iKK7V3rvY15yfNNS ANSLQtWyKdc52/7aoPCrKim8f/+eZcuW0atXL5FUC5nZs2ezYsUK+vTpg5WVldTh5Bv6+vqyd5kX L17M/fvXOPlPrWljyxrYtfhOyvCUQlRoCBcO/AmAdjEwL5OMmpqaZO+AK/yO9WsfkiDkUSjRzx7y KDSMuUtWAzBm2UFU1QpXQeDrJ/dyeMMC9MvqMGvCKABKlChR4AtHR0dHM3LkSLZs2SJ1KPlGQblj BTEsLA/xn+DOnbvEvHjOxcs3WPvXDjRLl2WE91apQ8tzJ7at4O9Dm6hubYHL4L4A6OjoyOWVmdzI 08SakbZt2/LhwwcsHfpSyshCtr24hhYVqtSWMLLc+ZAQx6ObF1Nte3hmO68e36RTp06MGzdOosik ERISgre3NytXrpQ6lHwnv5SQy4opU6bQsWNHGjVqJHUoBcaLFy/o1asXADW6jEJdS0e2T1tHH8NK eTcMKm+xMS8JC0ldmzX44Crevwxn+PDhODk5SRRZxpQisX7xxx9/EBISIvsc9wnuvkz/tZ1KNg2p 1lA5Zsa+ex1N4JZlabZ/PbT7Rc+ePalevXpehaY0bt26xdatWxk5ciR6elkrDC/8qyAlVoCff/4Z Ozs72rZtK3UoBc6SJUtSrXr1OgEex6T/e7RG046YVa2TV6F9U8STu/x9MO17vNrqYF469e/RYcOG YWRklFehZZtSJdb/evfuHZcuXUp339ET59i293C6+7qN9FRIHVZf127Ex8ak2W6or8cMd+c020uW LCleJSFlZuvUqVOZPHmyUv8wKLOCllhjY2NZunQpTZs2pXHjwl0zWdGioqK4fft2uvv+3LGPk+eC 0t03aOY6dI3M5BpLYnwsS0Z3TnefTdXKOA/qk2a7rq5utqvLSE2pE2tOTZkyJcP35kqUMaBah/QX B4+6e5HQoAMZnnfnzp1yW5mjMMnvixwog4KWWL+YMmUKHTp0EMlVCQ0aNCjDdarLmFbBvGnvNNvL aUL01YNcuHAh3eM0NDTYu3evPMNUSgUysX5LREREhgWZ69evT/v27fM4ooJt37593L59G3d3d6lD ydd+++03njx5IvtcoUIFBg4cKF1AclRQLxoKstu3b8smIAYHB/Pu3TvZ6Fz79u0L/CTMzBS6xCrk nYCAAC5duoSzs7OYAZoDY8aM4dq1a7LPgYGBsq+bN2+e6nN+tnXrVqKiohg5cqTUoQg5sGPHDsLC whg1apTUoSgNuS1pKAhfi4yMZPny5bi5uYmkmkM+Pj68efOGwMDANEk0v67ClJ5evXphYGDAihUr +PTpk9ThCEKuicQqKMS2bdtk0/+FnFFRUcHf3z/d91d9fHzyPiAF6tmzJ6VKlWLNmjVShyIIuSYS qyB3Pj4+lC9fXtRWlQMzMzPWrVtXoO5QM+Lk5ISuri5Lly6VOhRByBWRWAW5+fDhA76+vpibm9Ol SxepwykwzMzMuHLliiy5BgQEFNiyjLa2toSFhfHixQupQxGEHBOJVZCblStXYmBgIJKqgmQ0LFyQ WFhY0LVrV3x9fUlISJA6HEHIEYUvwi8UHtu3bxevTcjBlStXGDt2bLr7Hj9+jKurK6VLl053/7Fj xyhSJH9fLzdo0ABNTU3c3NzEsLCQL4nEKuRaVFQU8+bNY/369VKHolQePXqU6t3Tz58/4zxhdqbH lbeqRV+fnF2gVGvQkuTkz99s4zt3GkW/Sr4VKlSgYsWKOepPUapXr46rqysTJ07Ezc2NsmXLSh2S IGSZSKxCrsTGxuLn54eTkxOmpqZShyOZpKQkPD09U20Le5dMROy/n4sUKYrbKsXe0Y9beSzTNktW zubz5yTZ53KaYKyV+pntlClTUFWV9teDubk5hoaGnDp1iu7du0saiyBkh0isQq6MHz8eFxeXPC0i rCw+fvxImzYphSBUihSldp+pqfabG1eknmEFKUL7pk7DpqX6/Op5KNFhD1Nta9O2Hcn/JN9Dhw5R rFixPIvvaz169MDLy4tWrVqhpaUlSQyCkF0isQo5du/ePZKSkgpNUn348CGhoaHcunufJav/oKiq Gq5++f+Zso6hKTqGqUcbrOrYy76uZd+WpI8fGDWkL9WsLDA1NaVSpUp5EpuJiQl+fn4MHTqUCRMm YGFhkflBgiAxsaShkCM3b95k27ZtuLi4FOjnX2HvYNvG1byJCpMN7eqbWtCgQz+pQ8tzF/b/QWRo SKqh40aNGtG6dWuF9x0ZGYmfnx+Ojo5UqVJF4f0JWSeWNExLJFYh216+fImHhweTJk0qsGXgAh8m MnNwO94mgl2nIZTWN0bPpBI65Qrvc+QvXkWEEv0sZeg44vZZnl05gpWVVYbFLeQlLCwMT09P5s2b J4aFlYhIrGmJoWAh23r27FkgX6u5GHQJ392XuXDgT1SLqTPGt+D9HeVBp5yp7ALDqo499J9MxOM7 WNd1AOBXr8lYmFfC3Nxcrv0aGxujp6fH1atXadq0qVzPLQjyJBKrkC179uyhU6dOUochVyEhIfz5 55/ceZGMplFlhc/cLYjKmVnL/t1WrJmDbrEzmGirMGnSJLlOfJo1axZz584lNjZWlHgUlJZIrEKW HTt2jHv37vHTTz9JHYpcBL+AWW4jiP/0GUv772ncqjbFNcQQY251GDyZV5FPiX76gPYdO9Pzu25y /Z5xcXHB19cXDQ0NmjVrJrfzCoK8iMQqZMmxY8c4d+4cU6dOzbyxkrt06RJnL17Cd+1f9JuynHJm VlKHVODoGJRHx6A8VnXsCTq8Beu6DizynISlhXmuh4g1NDQYP34806dPBxDJVVA6YvKSkCUODg75 +rlqUjIcvniPiwf/4s6LZLSMKlOv/fdSh1Wo7F/7M7pqiZhoqzBx4kTU1dVzfc78/n1ZEIjJS2mJ xCpkasGCBVhZWeXrZ6tDhw3n3iuo164PFarWpnhJMeQrhdeRT4l6+oDYK9vx812S6/P5+/vz9OlT Ro8eLYfohJwQiTUtMRQsZCgxMZGVK1fm26QaFZvE7aBTbNtzGLOO46hfobLUIRV6ZQzKU8agPJH6 xljXdeCngU6MHD44x8sndu/eHX9/f/z8/BgyZAhqampyjlgQsi9/l8EQFGrlypUYGxvny6T67B1M W7CahZsC0arZGQORVJWKgaklbqsCuPWuFCtXr8nVubp3746uri6rVq2SU3SCkDsisQrpmj9/PpUq VeK7776TOpRsi3wPs+YvQ6WkDl1GeGBu01DqkIQM1GvnRHCcDg4ODpw5cybH5+nduzeGhob8+uuv coxOEHJGJFYhjcjISJ4/f46tra3UoWTb6dNnaG7vQBFNPeq07iV1OEIW1GzRi74+Afz82wFOnc55 crW1tSU8PJzo6Gg5Rif818ePHwkMDJT9uXXrFiEhIbKvBTF5SfiPt2/f4uPjQ+fOnbGzs5M6nGw5 dOgQGw9fofkPE6UORcihExt+oW9rW9q1a5ej4y9evMiBAwdwd3enZMmSco5OAIiLi2PQoEFs2bIl zb7u3buzY8cOCaJSLuKOVUhlwoQJ9O7dO98l1TNnzvDHkSs06OEidShCLjTo4cKfR69y+vTpHB1f r149evbsibu7u5wjE74oWbIkvXv3ljoMpSYSqyAzZMgQxo0bl++qhyR8+MTyAzfRKGeBeklNqcMR ckG9pCbN+k3kl/WHOHkqZ8m1WrVquLu7M378eDEsrCA9evTAxSX1RayOjo64W/2HSKwCANevX8fE xAQdHR2pQ8m2NWvWUFKrFLVb9ZQ6FEFOuo2czcTJ0zJvmAEzMzMqVKhAYGCg/IISUunQoQP6+vqy zwMHDpQuGCUjnrEKREdH4+npycSJEzE0NJQ6nGxZunQp9z6Uw6aF9En18a2/2bZoPAAVqtahl6v3 N9uHBl9my8Jxue533MrjqKik1EddMKwlycmfATC2qEGfCYu/eWz4g1v8+UvKnYdRpWp8P2lpruOR l+sB26ms9jzNnVFWhYWFMWfOHLy8vChdurScoxMAbGxsuHHjBgDXrl3DxsZG4oiUg1ggopC7e/cu Pj4+Cq+lqQi3nrxg/+UwmnTP2UQXeTOrVpf6HfqydeE47gYFoqFdhg6DJ6fb9nNSErO/rw1AhSp2 9BzjzYLhLXPYczKQkljvXgok+XNKYo2NecmLsEeUNa6Y4ZGz+tiR9PEDAJ8+JOawf8WwcejBpWPb WbR0OS4jhmR7EQljY2N8fX0ZNmwY7u7uWFpaKijSwisgIICyZctiYWGBpqZ4DPOFSKyFnLe3N5Mm TZI6jBwJuXIabV0D9MtbSB2KTNPuQzizax0Prp0l+OIxGnT8AZ1y5dO0O7vnN9nXjm6LKGNgQufh M9K0exn+mLN71gOkux9A5Z+k+l9hITc4vWst3Zxnp7v//L4NJCclZfZXklTtlj1YNvY7BvR1pEyZ Mjk6h5eXF76+vvTq1Ytq1arJOcLC7ctEpiZNmlCpUiWpw1EaIrEWYocPH6ZatWoYGRlJHUqB4uju w5x+9blz8Th+bj2YsvFiqv2nd65ly4KUIeDGXX/EpLINJTRL0WWER5pz3Q0KlCXW9PZnpPe4BWz1 cef83g3UcuhGhSq107Q5t3cD5SpaY27TkFP+q7P+F8xn9PT0GDZsGHPmzMHT01MMC2fRhyQ48ijl 6/jYGHxdu6XbLjo6msuXL2c4can/9NXUsDanTv56ypQrIrEWUocPHyYoKIjJk9MfqlR2b968Ydbi 9Tgv9Jc6lDQqVquHq99hfH5qQ+idKzy7dw2TyjUBiHv7mrtBgcTHxlClXksGeuRuOb+MmFSuialV LZ4EXyLu7es0+/evmcPt80ew7+1MGX0ThcQgL84Ld9CxiwNnT+W8io2RkRF6enpcvXoVe3t7+QWX j3xOhvtPowh/eDvVdg9vXyKiXnzz2BKapRjpk7N//7WzhhD99ME320wZM4zyxv9mXs3SulSpVgON fLr0s0ishdCuXbt4+PBhvk2qAPdeSR3Bt+mZVMLSrikhl0+xbNx3DJq5Dku7ZjwJvsT5fRtQUSlC w879FRqDo/si5v3YlHN7N2BdtwUqRVJeAngV8ZTgi8cAcHLz4dDvCxQah7KYMWMG3t7evH//no4d O0odTp5YunQpL1++BOBjEtyIhv/OV+3m5odmmbIKi2HA9MxHQ45sX8GbU3dTbTPR3oGBxr+fhw4d mm9G10RiLWQOHz7Mw4cPGTFihNSh5EqI0idWc36ctZ6lY7oQdv8m9y6fwty2MVsWugHgNP5XGnZS bGL94tze3xnosQYVviTWUO5cPJ4nfSubkSNHsmzZMkqWLImDg4PU4SjEDz/8wLNnzwCo3sWF4sbV Zfvq2OpjWKmqVKFlqFmP4ak+x755Sdj9G8R+tW3oKHfiXoUD4Ofnh7W1dR5GmD0isRYiCQkJBAcH Y21tTYkSJaQOJ1d8XbvjvES5C1yXNa5IZbvmhN2/yU7fqez0nSrbblW7ucL7t6zVhG7Os9m5bBre Q+yZsC5lwYX5Q1MSiqvfYYqqFVN4HPLQZtSv/O9//8v1IvslS5bEzc2NWbNmAeTr5HrhwgXi4+MB mD53CVEvUq42B3tuoLmBcg/vZ0aztC5WdexTbfv684hpI4h4nHKHO3H0EMzKGwNgZ2eHtrZ2XoWZ IZFYC5EVK1ZgampK+/btpQ6l0OgzYTEJcW85t3cDAHrGlRg4ax3GljXypH/L2s3QM67Eq4in3Ll4 nNdRYXz+nISlXVP0TArvLM7p06fj4OCQ7xLr4sWLef065Zn5rehkEj6lbO8xcRUapfLf4i451W/K v68HBuxYxeszgQBYHzmBxj/XioMHD8bERJoLDJFYC6CIiAj69OnDhAkTZIuZz507FxsbG5FU85hK kSI06NhflljLmlSisl2zPOu/sl0zyppUIvjCUe78fZxHNy+Q/PkzlrWaomdinmdxKCNXV1d8fHxw dXWVOpRvioqKwtHREYAaXUejbpyyCINDu/qoqefvkSd5aPrdUNnXocGXiX3/FoARrhN5/yIMAF9f X6pWzbshcJFYC6CEhARZSSd/f39iYmLQ19cvUEnV2KIaYfdvYmxRPfPGEnp86298fmot+xx84Sjr Zw6m97iFlNAslScxjF1+hOF11Ni32gsAC9vGdHfxypO+5eVVWAiWFvJ9X7lLly7s3r0bX19fhg4d SrFiyjMsnpCQwPnz5/l9y25uPAhjeA5n5BY2plX+LR7y9dDxyJkjKaOWyOgh/fJkuFisFVzADRw4 kMePH1OrVi2pQ5GrbiM92bUs52vJ5pXN81PuhqzrtaDTsJR4T+9cy7OQG3kaR+MuA2VfN+o8IE/7 loegHUsZNWqU3M/bpUsXDAwMWLlypdzPnVO7du1i9py5LNwUiEmzHxg+d7PUIeV7fSf5UsdxEgs3 BTJ7rg8bN25UaH8isRZwMTExLF++nOfPn0sdilw1MJY6gsyd8l9N2P2bVKham4Eea+kyYia9xqa8 2rLZe0yextLo68T61dcC9OzZE1NTUxYuXChpHJGRkTg4OLDz/COSLdrSZYQHptYF64JYSvrlzeky woMSNbpw6lEiDg4OCivMLoaCC6D/TsiIiIhg7Nix2Nra5rtF9jNioKVKBeNyvI58RhklnAF5+/wR fp81FBUVFaxq26NrWAEAqzrN0TWswJPgSywc3oqxK47mSTwWto1ZdSV/1tsIf3CTGjUUuxShra0t J0+eJCoqKlXFFkX7MuS7fvMubj16zjAx5Ktwpta1MLWuRd3Ogxk124VSReP539AfqFWrFqVKyefx jLhjLeBKlSrFjBkz+OuvvwpMUgXQ1NRkQI+2XDq6TepQ0vj8OUk2WalIUVV6jZ0v21ehSm0adPoB gOiwh9y7dFKSGPOTnb7T+cUr/fWO5cXU1BQnJyf8/PyIjY3N/AA52LlzJ7P+GfI1tR/AsF825Um/ wr++n7iUen0ms3lfIIsXf7sSVHaIxFqATZgwgYMHD+Lh4YGtra3U4RQaf80dzfl9KYnV0d0nzf4m XX/E2LIGL8IesW76QJ6FXM/rEIV01KlTh169ejF+/HiF93Xw4EF2X3wClilDvuWtxM+nVPRMzLEf 5AGV2+Pg4CCX569iKFiJxX2EmHQqecW8iCDi8Z0MjytdujQBASlDSl9mCAOoFStOJZsGadrrl4Si +fASq2Hrbuy/vJRLR7cpTZHzF2GPuHfpBADdXbxw6D0yTZuyxhWZ/tcVhtdR5UV4SnsTS1HH8r8S 42K5sMOXxbPG5riyTXZVrVqVSZMm4ebmxvjx4+U+LHznzh1+HD0RoyoNaTdoglzPLeTcuw9gaFWH vj4BHN25hg/rN/LjgH45Pp9IrErgRRyEvoUjGxaSEPcuzfb0fKs+ffn6XVm4KTDdfSoqh9Jsq1YW 1P/znVCzWWfaN7NDvWim4UvGQAOmu7vQuY2DUiTW6GcPWDd9EOEPbqFnYo5lraYZtlUpokLDTv05 t/d3Ns37HyU0tGmYD2frKtL5Hb70bVWTJk2a5Gm/5cuXx9LSkmPHjtGnTx+5nffq1av8un4nfaat p4RW3rxqJWRfk26DObVrLU9nzsTBwYFmzbL/3rlK8rd+QwtyN3v2bI4fT71O65c709b9xlJcQyvT c5Qqa0g5M6ts9/3xQwIPr5/PUttrJ/YQH3oZ1f/cyY4bN45OnTplu29FOnX6DHPXH6DbSE9J43j/ 9hXP7qUM62po62BS+dt3oXFvX/P03jUASmqXofw/FXBStXn3hqd3rwKkWeItPfcunSA5OZnylWtS Ujtrd3mvnocSHfaQEpqllGYW6k7faYzv35ZmTfM2qX4RHh7Ozz//jIeHB7q6urk+n6OjI5+1jGjY ZwLauuXkEKGgSMnJybwKPkHc3QB69uxJjRrZWylNJFYFCA8P5969e0REvcDD2zfVvk5Dp2Jdr6VE keXe4Q0LuH5yr+yztpYm86an1BatV68eJUuWlCSuM2fOsML/FPW/c0G9pKYkMQjy8TryGWc3erHB zxtNTWn/L4cPH864ceOoXLlyjo6PiIhgoscv2PSehLaOgZyjE/LCZu8xzB8/iJo10174ZkQkVjna tm0bt27dIjoOQmOS0SpTFgdHF6nDUqjEuFgO/Z4y67WangrFVaFjx47UqVMnz2NxdXVFq35/pbnr ErIv5kUEwQdW4DbUUSmql7x8+ZIlS5bQo0ePbN+1AKxdu5Yz4ap5VslIkL/k5M+c+G0Ww3q0yPKw sEisuXQ5AqYN607cuzdUatITnQrVKK1nhEGFnF3h5mePbl7kQ0IcTy7uIzokCIAxY8bQtWvXPOn/ /v37jJn6C90mZl7/UVBOO38ZwiLPiVjIefnC3Hj+/Dk///wz06dPp2zZrNctDQ8P53/T5/8z/Cvu VvOz4IvHKB15lmnTsrbam0is2RQWFkZISAjPI6OZOX8ZAPwd+TsAABp+SURBVM4L/SmpVVriyJTT 0T8WcTVwF7VrVmNov54UK1aMRo0aKay/9+/f06pdJ4xqtcXByYXiYlhY6SXGxfL4dhD3T2xig998 yYd/0+Pp6UnDhg1p2TLrj3FqN3Lgp2ViwYeC4syutTQ2VWXIoMxHH0RizQZvb2+eRMcR+jYZLR19 HHo7Sx1SvhH+4BZBR7aiVgRsDFTo0KEDdevWVUhfMYmwbNMhgi5dpv2PkxTShyA/Jzb8grlWAk5O Tkox/JuRhQsXYmlpSefOnTNt6+/vz86LT2nqODoPIhPyytnd62heoQgDBnx7Br9IrFng7+/P4sWL se3pTtnylhiYWkodUr6V9Okj96+eIfTv/SRG3mPnzp0K6edtIvj6n2X9ginY9/6JOq17K6QfIXf8 l05h0sAONGnSWOpQMhUfH4+fnx82Nja0atUqw3b79+9n25n71Os6HNVi6gqL593raFaMz9n39Y+z 16NTzhSAtdMH8Op5KAAltUrjvND/m8fGx8bg69oNgOIa2rgs2vXN9utnDSH66YNU2xwcR2b6ilzg Vj+CDm+hkk1Dvhs155tt80ry589scm/NsWPHvtlOvMeagS9DvuNmeFO5fhv6ijU85aKoqhpWdeyx qmNPfGwM1nUdcOrWntb2jWncWH6/XLXVYZJTIyY5BbBs2TKuHP4L/UrVMbbImwLjwrddO7aVm3uX 4enpKdf/d0UqUaIEY8eOxcsrpeRetWrV6N+/P48fPyYkJASAl2/jWX/8Lsbm1RSaVAE+fUzkblBg jo79kBAn+/rxzb95/igYSEms4Q9vY1Qp49qlcwc1Iez+TQA0SqX/KtLj20HcPHMwwwpUd4MCUS+h wajFe9Evb5Huet/RTx+ktFOixzkqRYrQeOh83KfOYqr7/zJcW1gk1nTMmzePJy/iefo2mcFzt1Ks uDSvkBR0JTRL4bYqgBun97PgjyMcPXqU9u3bU69ePbn24+zsjN+KlRw4up3Lx3bQ9LuhlNYzkmsf QtY8uH6O2+cO065mOZYE5M+L1SlTpmBjY4OZmRlHjx5NNdHq4t1wwh/conU/xRdPL6GhTefhM9Js T4x7x+ENKZV6Wji5pJv8NEunPwkr7t0b9iyfyfB56Zequ3F6P29fRWUa2/qZg2XvdKupF6fdwH9X mYp4fJe/D20iMf4984c60Hvcwjz595IXU+ta7Arw59q1axnOEhaJ9Ss7duxgyZIl2PYaj7G1BbXE kG+eqNGkA1UbtOb+1TMsWLudBC8vdu369vBSdo0YNoxWYS8Ju3+DOb+6oapjpjTDS4XF4lEdaVav Jq6ObWjaNONVqfKDV69eceNGSk3dsLAwvL29cXd3J+RV3sVQXEObLiM80mx/Ex3+VWIdleU3FFr1 HcOV4/7cDQrgauAubO3Tzua/cfoAnz4k0uWnmez2S5vUAY5vWkL004f/9O9C3baOWNj+u9BH7JsX NO85nN9nDyMqNITALb7YNOtUoB6xicQK3Lp1ix+c3bFu0F4M+Uok1RDx+7f0+dGZ4f17U7duXTQ0 NHJ9fhUVsDTRxdLEHnt7e86dO4eLswN2nYdiYlEDY0sxRKwIIVdO8fzmaZ5ePsz5Q/skW0BEHuLj 47lw4QJeXl6EhYWl2n737l0A1s8ckm9nAhtUqIy5bSMuHviLN1FhafZfOrqNgM1LqVK/JUbm6Zfx u3zcn7/mjqZoUVU6DZ1KV+e0VYk0S5fFqo490zdd4ef+DQi7fxPP7+uw5HSM3P9OitL1p1kMG+rA nb/T/7/Oh0uvy09kZCQzZ85k7qqtDJ23nRZ9RkkdkkDKEFfVzqNYuCmQ+YuWKqSPhg0bsvtQANVK vSfm8nb2rJjJm+hwhfRVGD24dpY9K2ai/vgY/drWJiAgIF8nVYC4uDgCAwOJjIxMd//jGPiQlMdB yZmT2yIArp/ez7vX0bLtHxLiCDq8FQDHf9p8i7qGVrpJNVWbEhp0c/HKRbTKq1An1tHuU4k1bo5d VxfU1EtIHY7wFcOKVegywoN4o0ZMnz5dIX0Ya8EY56FMcRuFq2Nzjvi5s2PxRIX0VZj86tKe2Bv7 cHVszozp02jTpo3UIcmFrq4uHh4ebN68OU1psf3797Nq6xE+fpYoODm7cWpf6sQaH0fQkS3fPCbh /TvZZCWnLCRfAIuajajTuhcfEt7jv3RKzgNWMoVuKDg2NpagoCCWr99M0xELKV4y80XvBelY1GpK SDLUa+LABFcXevToIfc+dHV1sbdPGSI+f/48k1wdeP1BjdaDJgNQoYodxTW05d5vQfAq4inRzx7w /mU4wQdXAXDxyH5KlCi4F6pVqlShSpUq9O3bFy8vL/bs2cOFCxeYM7QN8w6GSh1ermjp6DN83mZW jHdk/hB7Fh5PmajkPdQegO8nLsHYojoRT+6mOTbp00fCH9wCyHJ9Wc3SZSljYMLnpCTC7t+Qz18i j4xbeYwWLVqkKaoChTCxei/y5cqzeOp2+Z9IqvmEpV1THOwD2LVhOZ8+bcbR0VFhfTVo0ICAgABu R35ki58X4bFw5J/6qlXqt8LCNn+8GqJI96+eIfjCUSCldJ+RZjKVjY1Zlk9n+ebGlClT+Omnn1i8 eDH+/t9+/zO/MKpUDbNqdQl/eJugI1tRL6HBu9fRGFWqilk1+c7YL6gKVWKdNm0an8zb0qWTNKWo hJx79hZsOw3h6O7VqG7frpA7169VNVDDw8ODdx/g9rXLxL9/i//+A8z3nYpZtXr0HDNXof0ro+2/ TuDRzYu0sW+Mq2PKAgmmpqZUqlRJ4sikpaOjg4eHBw8ePMi8cT5gZJ6SWB/f+ptLR7aipaPPu1dR VLZrRsXqIrFmRaFJrIsWLeKVTm1q2Yqkml8VLapK/e4j2L5pKR+TtuPUW7HJFUCrGNSvaweAvb09 ABcvXmSCqwMqRYpSu89UIOXF8cp22S+IrKzuXT5J8ueUB4aXNnmRnPSJuXPnUq9e4bugyKrBnhsY 0dMBt1X5/8697yRf7gUFEnQkZcKSZpmyjPDeKnFUymXBsJYZzgouFIk1IiKCkPAYDBsp7zqkQta1 cHLh4Pbl8HkTTk5Oed5/vXr1CAgI4NOnT3h6phRXTwb2/OeHzLpuCyztlP99zZArp7hzMfVzIluD ZFT++frwwQOoqhaKXxXCVxp1Gci2ReMBaNx5oLTB5DOF4qdl9Pip2PaaiH555SlFJeSOXRsnNi8c JEli/UJVVRUPDw8APn/+zMmTJ1Pt33XwCPP9/p3RXKRIUcauOJqXIaZr4YhWfE76972Qdi2a4OqY umpLs2bNKFKkUL80kG22BlC8AP1G/TqxNuoyMNP2xTW06eo8i13LprNp/hjcVqad1PNf96+eIehI yup23V0KzoItBejbIH3dunWj5bj1lNBKf01HeXkTHU7kk3u8eh7K2ulpKx/8NH87GqV0MKpUFS0d fYXGUhiU1CqNVZdxTJ/9C+NdXSQvNVakSBHZUPEX9vb2+Hz1OSkpiVatHDI9l5aBGVatvl09IyNB f86CTOpqXD99RNyBKkDp4vCjx2rWzxzCgBn5vyawVhk9Vl3Jeo2WoqqqGJlXB+DJrSDCH9yUfU7P 56RP3Lt0gteRzyiuoY2xRcZtlc0uv+msXDAzw/0F+qfr/PnzaJvZoqqu2MWw372OZsPsYVw/tS/D Nn5uKc8Da7fswcBZ68SMZDmwqNWEGNVYli5dysSJyv/+adGiRQnIwszZR48esX79+hz1cfzYMVRU VDJvKCiEpY7UEUjLsKI1FWvU59GNCyx378XAmb9RqUb9dNsGbF4me3e1cRbuiPOTQpBYa6FWrLhC +1k9pR+3zx0GQNewAoNm/ZZq/95Vs2XPsC4d206fCUtEYpWT8nXa8Yvf3HyRWLOqYsWKsiFmIX+p Z2WEkXk1bp87TNWGBWNhjOwwrFiFIV4bWeTcjueP7rBmSj/KVbRm1K97ZG3uXz3DTt+pPL4dBIBD b+d8tQJT6J0rWOupUrNmzQzbFNjEGhsby8t3CWiWT7+Kgzy8iQ5n9eS+3A0KpLSeEUO8NmJVN+1Q n1UdewCundzD+plDFBZPYfQ2EfTMqnPz5k2qV88/Q0lCwaSrXYIBLazYduYOnz40V3jpOGWkX94C qzr2qKmXIPzBTaKe3mdorbSjKEWKqtJh8GS6Z5JUr5/cm+7xX6vRpD2jl+zPVdxZkfz5M2dWuRXe eqwhISGcvxuJY2fFvdB/NWAnd4MC0Sqjxw/TVqabVL9Ws1ln+k5ehrpG6ueBT4Ivcf3k3jTtTa1r UbN5l3TPdSXAn2f3rlPeyhZb+67EvXvDsT9/le03qVyTWg7dMowlPjaGo3/8u+yYsaUNdi26p9v2 2sk9hAZfxtiiOnYte5AQ944j/1TPgJT33jIrWqxInX7yZOrUAQormi4I2dGhQwcSE/3Z6b+Cpo6j pQ5HEgNmrOb5ozv8fWgTJ7at4O3LiDRtHBydM02qyubc3vX0798/03YFNrGeT1ucQWE0y+hh07Rj ltrWbpn63cvXkc9YNel7Ip/cS9O2VFlDjmz0Yfi8LWiV0Uu178rxnZzb+zuNuw7i+cNgrgbu4uGN 87L92rrlUCtWnOqN26U578Hf5nElwJ+H179ub8DxvxYzxGsjpfWNU7W/dmIPp3asol7773kR/pjL x7bz4No52X4tHX1U1YpleBEgCIVN9+7d8fR2kCSxapbWlb1Lm14B8f8aNPs3PsTHZbm8HEBlu2a4 rQqgqKpahm0MK1rTZYQHNs06kRgXC0Bi/HuWjO4EQKNMXuGx7/0TNs06ZSmejAquy9OZXWtpbKrK gAGZJ1aV5ORMphDmU6MXbuVldBQOjiMVcv7wh7eZ0SOldNLCY5E5nukbGRrC1K6VMaxYBW1dg1T7 Yl48J+LxXUrrGTFu5XHKmVnJ9q2dNoBze3+XfVZTL06lGg0A+JiYIEuyzgv9ZXeuHz8ksHfFLPav /RnVYuqY2zSUHf/2ZSTPHwWjVUYP9zUnMKxYRbbv99nDOLVjleyzqloxzGs2AuDTxw88uHYWgGG/ /EXdtnn/+ktifCwnV7ixwHMqJiaZ/yIRhLwQHh7O/6bPp2GfCWl+tgur+HcxjG5WGoCBHmtp3HUQ AJ+Tknj+KFhpZwYHXzxG6cizTJs2LUvtC+wda8DmZfxvhfKvgKJZSofOw2dQu2WPNDVBQ+9cZt30 QTwLuc6h9d4ZTuGv5dCNynXsafX9/wB4Gf6YiR0rArDZe4wssb57FcX+tT8D0G7geLr+NEt2jmch 11k3fRChdy6zb7UXQ7w2kp6azTpTuU5z2vwwDoCYFxG4tTYEYJO3qySJVb2EJnq27dm2bRtjxozJ 8/4FIT1GRka0b1SdM+cO0bBT5nc5hYGqujp12zrx96FNbJzzE68iUooWfPyQSPiDm7gs2i1xhGkl J38m8tZpuvbI/FW5L8Qb4BLTKKVLlxEe6RbaNrW2w6SyzTePr964Pf2m+MmSKoB22XK0H5R2luwm 73+Tzn+HYUwsbTCtUguA4AtH0311qEr9lvwwdYUsqabEr0OnYVm7ihOEwqZDhw4kPbvM21fp13At bNSKFef7iUuo3aonnz4ksnu5B7uXe3Dgnwt+ZbRl/ljcf+xGs2ZZX7K0wN6x5jfPHwXz9mUkN07t 49Dv87N8XKmy5dDWLZdqm1qx4pSrmHb5xqd3rwIw0GMNeiZpF04fMH0194JOEPX0PjEvnqfZr6Vj QCk9w1TbVNWKYVSpapbjFYTCpFy5cvy2fBGOjo581jL6Z1i4XOYHFmCapVPWHf599lCiQu/Lthtb pL25kEpycjKvgk8QdzeAhRMHU6NG9mIrsIm1eqO23Dp7iGqN2kodyje9j3nJ8U1LuXRsO2Eh+ase obL4+CGBt4+v0sBJuf+vhcJr8+bNXL16lV/Xr8DuuzEKXwkuP+g/bVXmjSRydvc6KiSH0rJly2wn VSjAibVao7ac2PW70ifW2JhX7F7uIfts07Qjbfq7yT7vXzOH2+ePSBBZ/vEpMZG3j6/QoMEMqUMR hAzZ2toyoXhxfhw9AKMqDWk3aILUIQnpOL1zDc0qqvPjAI8cn6PAPmPtqOD19o0qVaXvJF8AvIdm /aH2f80fYg+krFjiExDNqMV7sapjL/sjZhMKQsFhbW3N2cM7GdK+Jme3/JrqFTlBOlrF4PndIP5w daCVhTo/DuiXq/MV2MRqaGiIpVEpIh7fUXhfsa+jv7lO8NcuHdtOQty7NNs7Dp2KZmnFrRL1tauB u4l7+zrN9msndvP+7as8iUGeLh2WpnycIORUu3bt6FKvAoQcZM+KmbL5D0Lei372gMB1M+HeAQIC AujXL3dJFQpwYi1XrhyVjUoT8fiuwvqwdeiGVR172SL8dzMoevvFtZN7+GOOM4nvYxUW07c4uaes tHQ1cBfv00msV0/s5n3MK6o2aJXlBS+UwWWRWIV8qFu3bkyfPBFXx+aEBq5n5UTxPZzX/vzFhYt/ zcGxY3NGj5bfYh4F9hkrQBl9E2JuR/A56RNFisr/r1pazwi3VQH4OLfl9rnDzB/WItNF+P+rvJWt bM1hVbVisrvWN1FhrJ6S+yunr1WsUR/DitY8f3SHnwc0ZPjczbJ9t88f4bT/GlSLqVO5tj2lyhp+ 40xZE3R4CysmOAJQp3Vvhs/bnMkR2Rf19D7WVuZyP68g5IXixYtjb2+Pvb09kZGRODk5YNagK4ZV GlDJpoHU4RVIoXeuEBlymXvHN7J06VKqVasm9z4KdGJt37Unv23oRmJbJ4XOwhvitZHfZgzi+ql9 vHz+hPnfeOZau2WPVGsFD/b8nXXTB3Ht5B6Wu/dK1dbU2o7PSZ94FnJdLnFq6xgw7JdNrJsxiNA7 V9KNs21/NzoOmSKX/hQt4vEdnp/dxOJ5nlKHIgi5ZmBgQEBAALt27eLipYPsOXeIms27YGpdS+rQ CoSopw+4sH8jlXWSaVrFghVZKOGYUwU6seprwBJvT8bNmUqv8UsU1s+XRfgjn9xj2bjv0n1++XWh 869LxmmU0uWHqSv4MC2e4AtHZdtHzNuCsaUN+1Z7yi2xQsri/EN//otn967J7iYBqjZoTYfBkzOs naiMnj+6g6VRacqVK9zvBQoFS9euXWnbti3nz5/n9y0bOLDul1SjS0L2/fHzSMqoJeI6pB92dnZo a2srtL8Cu1bw165evYr7/PU4uvlIHYogJw+unkb1wSFmz54tdSiCoFBRUVE4OqZcBNfoOhp1zTKU M7OSy+Oaguh9zCuehVwnOekTlzalVM/x9fWlatW8W8imQN+xfpEykSllhnA5s7QrEgn5y80zByn1 +hozRVIVCgF9fX0C/hm2XLx4MffvX+PkpRMAGFvWwK7Fd1KGpxSiQkO4cOBPALSLgXmZZNTU1GT/ bnmtUNyxAjx79oxxU71oNswb9ZKamR8gKK1N3mNYMH4QNWvWlDoUQchz8Z/gzp27xLx4zsXLN1j7 1w7ZMoGFzYltK/j70CaqW1vgMrgvADo6OtjYfHuNdUUrNIkVYNq0aXwyb4u5bROpQxFyICnpE0G7 V9PORo8ePXpkfoAgFBIvXrygV6+UyY81uoxCXUtHtk9bRx/DfLyed2zMyzTLvQYfXMX7l+EMHz5c KV+1K1SJFWCG51yuhiVQp40jhuksVC8oJxNt2LVhOfbWZWTPmwRBSGvJkiW8fPlS9vl1AjyOUUm3 bY2mHTGrWievQvumiCd3+fvgpjTbtdXBvHTqNDVs2DCMjIzyKrRsK3SJNTY2lqCgIJav30yTofNS zdAVlFPI5VMErJ3OBFcXcacqCNkUFRXF7du309335459nDwXlO6+QTPXoWtkJtdYEuNjWTK6c7r7 bKpWxnlQnzTbdXV1c7QQvpQKXWL9mmP/oZg264uxeXU0y+TNcoJC9ty/copij44wa9aszBsLgiA3 gwYN4vHjx+nuK2NaBfOmvdNsL6cJ0VcPcuHChXSP09DQYO/evfIMUykV6sQaGRmJn58fD9+o0LDP eNTUS0gdkvCP54+CCTq8BTuT4syYIqqACIIyuX37Nlu2bEl3X/v27alfP/+8D68IhTqxfnHr1i1+ cHbHukF7WvQZJXU4hV78+7ecXTOR4f17U7duXTQ0NKQOSRAEIctEYv3Kjh07WLJkCba9xqNnYoG+ qaXUIRUaSZ8+cv/qGUKDDpDw/A67du2SOiRBEIQcEYk1HfPmzePJizievVOh7QB3ihUvKXVIBdqN 0/t5evtvbPST6dChA/Xq1ZM6JEEQhBwTiTUDYWFhhISEMG6GN5Xrt6Hl9/+TOqQCJz42Bl/Xbjh1 a09r+8Y0btxY6pAEQRByTSTWLPD392fx4sXY9nSnbHlLDMQQcY7Jhnz/3k9i5D127twpdUiCIAhy JRJrNnh7e/Mk+j1P36mgWUYPh97OUoeULyTGv+fw7/MBUFWBGvrJdOzYkbp160ocmSAIgvyJxJpN X4aIn0dGM3P+MoB0i5sXdnFvX7NsXMri4FqaGnjPcAOgWLFiNGrUSMrQBEEQFEokVjl48uQJAwcO BKC4dlmqdx4JQLHiJalYvWBPxPn08QMPrp0F4GNCLNe2LwCgTJky7NixQ8rQBEEQJCESq5y9ePGC pUuXApCYBLdfpKzRqVFKlxZOLlKGJjcJce84smEhAKpFoIZeyreQpqYmbm5uUoYmCIIgOZFYFSgu Lo6LFy8CEBn9khnzlqba33HIVKrUbylFaNly+PcFXD/17zJkpbQ1mTttHCCGdgVBEP5LJFaJhL6F X7w8Cb54TLZNXUuHGl0yX/mpVFlDyplZZbvPjx8SeHj9/LfbxL3lmr9Pqm1tfhjH6B86oaGW7S4F QRAKHZFYlcirV69YvHhxpu1exkPo2/TLQH2LWhGorvft/25tbW3Gjh2b7XMLgiAIKURizYciIiK4 c+dOto8rXrw4DRo0UEBEgiAIwhcisQqCIAiCHBWROgBBEARBKEhEYhUEQRAEORKJVRAEQRDkSCRW QRAEQZAjkVgFQRAEQY5EYhUEQRAEORKJVRAEQRDkSCRWQRAEQZCj/wNW31nE6Qlz5QAAAABJRU5E rkJggg== --=-=-=-- From sc34wg3@isotopicmaps.org Tue Jun 4 18:48:41 2002 From: sc34wg3@isotopicmaps.org (Mason, James David (MXM) ) Date: Tue, 4 Jun 2002 13:48:41 -0400 Subject: [sc34wg3] 13250, Second Ed. Message-ID: <28D46344A4EFD411AAAB00508BDF65EC089EDE04@exchange10.ctd.ornl.gov> I've posted the link at http://www.y12.doe.gov/sgml/sc34/document/0322.htm (If you're downloading, notice that the actual file is in http://www.y12.doe.gov/sgml/sc34/document/0322_files; the text of the standard is http://www.y12.doe.gov/sgml/sc34/document/0322_files/iso13250-2nd-ed-v2.pdf. Steve and Michel: Notice that I've changed your page header (just in the PDF, not the FM source) so that it says ISO/IEC 13250:2002 because this amendment has resulted in a new edition of the standard (as in the case of HyTime, too). Jim From sc34wg3@isotopicmaps.org Wed Jun 5 11:30:55 2002 From: sc34wg3@isotopicmaps.org (Michel Biezunski) Date: Wed, 5 Jun 2002 12:30:55 +0200 Subject: [sc34wg3] 13250, Second Ed. In-Reply-To: <28D46344A4EFD411AAAB00508BDF65EC089EDE04@exchange10.ctd.ornl.gov> Message-ID: Jim, I have tried to download the files you mentioned and it seems as if the server was not working. Do you need me to produce a new FrameMaker with 2002 instead of 2000? (Note that I already changed 1999 to 2000 to comply with comments that we received (from Japan I think). Michel =================================== Michel Biezunski Coolheads Consulting 1527 Northaven Drive Allen, TX 75002-1648 Email:mb@coolheads.com Web :http://www.coolheads.com Voice: (469) 675-1000 Fax : (972) 359-0270 =================================== > -----Original Message----- > From: sc34wg3-admin@isotopicmaps.org > [mailto:sc34wg3-admin@isotopicmaps.org]On Behalf Of Mason, James David > (MXM) > Sent: Tuesday, June 04, 2002 7:49 PM > To: sc34wg3@isotopicmaps.org > Subject: [sc34wg3] 13250, Second Ed. > > > I've posted the link at http://www.y12.doe.gov/sgml/sc34/document/0322.htm > (If you're downloading, notice that the actual file is in > http://www.y12.doe.gov/sgml/sc34/document/0322_files; the text of the > standard is > http://www.y12.doe.gov/sgml/sc34/document/0322_files/iso13250-2nd- > ed-v2.pdf. > > Steve and Michel: > > Notice that I've changed your page header (just in the PDF, not the FM > source) so that it says ISO/IEC 13250:2002 because this amendment has > resulted in a new edition of the standard (as in the case of HyTime, too). > > Jim > _______________________________________________ > sc34wg3 mailing list > sc34wg3@isotopicmaps.org > http://www.isotopicmaps.org/mailman/listinfo/sc34wg3 > From sc34wg3@isotopicmaps.org Wed Jun 5 13:22:46 2002 From: sc34wg3@isotopicmaps.org (Lars Marius Garshol) Date: 05 Jun 2002 14:22:46 +0200 Subject: [sc34wg3] 13250, Second Ed. In-Reply-To: References: Message-ID: * Michel Biezunski | | I have tried to download the files you mentioned and it seems as if | the server was not working. It works fine for me, Michel. Probably it's just some temporary problem. -- Lars Marius Garshol, Ontopian ISO SC34/WG3, OASIS GeoLang TC From sc34wg3@isotopicmaps.org Wed Jun 5 14:14:24 2002 From: sc34wg3@isotopicmaps.org (Mason, James David (MXM) ) Date: Wed, 5 Jun 2002 09:14:24 -0400 Subject: [sc34wg3] 13250, Second Ed. Message-ID: <28D46344A4EFD411AAAB00508BDF65EC089EDE16@exchange10.ctd.ornl.gov> I just tired http://www.y12.doe.gov/sgml/sc34/document/0322_files/iso13250-2nd-ed-v2.pdf, and it worked. Likewise the lead-in, http://www.y12.doe.gov/sgml/sc34/document/0322.htm. Our sever is occasionally cranky, and the net gets bogged down. I don't really need for people to download anything except those two files; ISO won't want anything else. If you want to do a new FM file, that's fine; I just changed the PDF, and that's good enough for ISO. Jim > -----Original Message----- > From: Michel Biezunski [SMTP:mb@coolheads.com] > Sent: Wednesday, June 05, 2002 6:31 AM > To: sc34wg3@isotopicmaps.org > Subject: RE: [sc34wg3] 13250, Second Ed. > > Jim, > > I have tried to download the files you > mentioned and it seems as if the server > was not working. > > Do you need me to produce a new FrameMaker > with 2002 instead of 2000? (Note that I already > changed 1999 to 2000 to comply with comments > that we received (from Japan I think). > > Michel > > =================================== > Michel Biezunski > Coolheads Consulting > 1527 Northaven Drive > Allen, TX 75002-1648 > Email:mb@coolheads.com > Web :http://www.coolheads.com > Voice: (469) 675-1000 > Fax : (972) 359-0270 > =================================== > > > > -----Original Message----- > > From: sc34wg3-admin@isotopicmaps.org > > [mailto:sc34wg3-admin@isotopicmaps.org]On Behalf Of Mason, James David > > (MXM) > > Sent: Tuesday, June 04, 2002 7:49 PM > > To: sc34wg3@isotopicmaps.org > > Subject: [sc34wg3] 13250, Second Ed. > > > > > > I've posted the link at > http://www.y12.doe.gov/sgml/sc34/document/0322.htm > > (If you're downloading, notice that the actual file is in > > http://www.y12.doe.gov/sgml/sc34/document/0322_files; the text of the > > standard is > > http://www.y12.doe.gov/sgml/sc34/document/0322_files/iso13250-2nd- > > ed-v2.pdf. > > > > Steve and Michel: > > > > Notice that I've changed your page header (just in the PDF, not the FM > > source) so that it says ISO/IEC 13250:2002 because this amendment has > > resulted in a new edition of the standard (as in the case of HyTime, > too). > > > > Jim > > _______________________________________________ > > sc34wg3 mailing list > > sc34wg3@isotopicmaps.org > > http://www.isotopicmaps.org/mailman/listinfo/sc34wg3 > > > > _______________________________________________ > sc34wg3 mailing list > sc34wg3@isotopicmaps.org > http://www.isotopicmaps.org/mailman/listinfo/sc34wg3 From sc34wg3@isotopicmaps.org Fri Jun 7 15:55:39 2002 From: sc34wg3@isotopicmaps.org (Marc de Graauw) Date: Fri, 7 Jun 2002 16:55:39 +0200 Subject: [sc34wg3] Which set is the unconstrained scope? (SAM-issue 'scope-unconstrained-rep') Message-ID: <01C20E44.2B927A20.marc@marcdegraauw.com> I have raised an issue in private conversation with Lars on the unconstrained scope, now listed as "scope-unconstrained-rep". Description: "How should the unconstrained scope be represented? Essentially, it is the scope made up of all subjects, that is, the universal set.". I would like to expand on this. (Since this is an old issue, it was probably raised by others too.) The current text of the SAM mentions: "If the scope of a topic characteristic assignment is the empty set the statement is considered to have unlimited validity, and it is said to be in the unconstrained scope." I remarked that this should be the universal set rather than the empty set. (Or rather, since scopes consist of topics, it should be the set of all topics.) Lars agreed that this was an issue but was concerned about the repercussions for applications. When an iteration over the elements of a scope is defined, this would imply an interation over the universal set, which is not desirable. The current positions on what the unconstrained scope is are: - ISO 13250: all the topics in the entire topic map ("This International Standard does not require that scopes be specified explicitly. If the scope of a topic characteristic assignment is not explicitly specified via one or more scope attributes, the scope within which the topic characteristic applies to the topic includes all the topics in the entire topic map; this special scope is called the unconstrained scope.") - XTM: does not say anything about which set the unconstrained scope represents. ("Every characteristic has a scope, which may be specified either explicitly, as a set of topics, or implicitly, in which case it is known as the unconstrained scope. Assignments made in the unconstrained scope are always valid.") - PMTM4: The scope comprised of the null set of topics -- the "no-topic" scope - DRM: nothing, scope is for the SAM - SAM: the empty set, see above The ISO 13250 defintion is strange, since the unconstrained scope here is defined to be equivalent to the scope made up of all topics in the Topic Map. I.e. when we have a topic map which consists of two topics: Netherlands Marc de Graauw then ISO 13250 would imply that this is equivalent to: Marc de Graauw Netherlands Since both Topic Maps will behave differently when merging with a third one, I do not see how this could be correct. It is also strange to use a topic to scope it's own name as a general principle, although this would be correct in some circumstances. Further, the second Topic Map would seem to suggest that the basename "Marc de Graauw" is not valid outside the defined scope (or not known to be valid), while the first Topic Map would seem to suggest that there is no known limitation to the validity of the basename "Marc de Graauw". Though strictly speaking this interpretation is up to applications, it still seems counterintuitive. The reason it is undesirable for the unconstrained scope to be the empty set is that applications may very well decide to ask questions such as "is that scope a subset of this set of topics?". Since scopes are sets, such questions are natural. If the unconstrained scope is the empty set, no scope would be a the subset of the unconstrained scope when it would be more natural to expect every defined scope to be a subset of the unconstrained scope. One can expect a lot of applications to use scope in such a way that a topic characteristic assignment in scope {a, b} is valid to a wider extent than an assignment in scope {b}. Since assignments in the unconstrained scope are always valid, it would seem more natural to define the unconstrained scope as {a, b, ... all other topics ... } then as {}. There is, I think, a natural solution to the representation of the unconstrained scope. We must distinguish between explicitly defined scopes and implicitly defined scopes (XTM already does, and ISO 13250 speaks of explicitly and not-explicitly specified scopes). Then an explicitly defined scope is a scope element (in XTM) or attribute (in HyTM) or any corresponding data structure in an application with topics as elements (elements meant here in the mathematical sense, as elements of a set). An implicitly defined scope is one required by the processing of a Topic Map syntax, i.e. the unconstrained scope when no scope is explicitly defined. Then we could say that iteration is allowed over explicitly defined scopes, and not over implicitly defined scopes. If that route is chosen, then there are several possibilities on the unconst rained scope: 1. It is the empty set, which is undesirable IMHO. In short, it forces applications to implement behaviour which is at odds with what the standard says. 2. It is the set of all topics. Any topic is an element of the unconstrained scope, and any set of topics is a subset of the unconstrained scope (though not necessarily a proper subset). The elements of explicitly defined scopes are accessible by applications, the elements of implicitly defined scopes (the uncontrained scope) are not. 3. Say nothing about the 'settiness' of the unconstrained scope. Explicitly defined scopes are sets of topics, what implicitly defined scopes (and thus the unconstrained scope) are is up to applications. The only thing that matters about the unconstrained scope is the consequences it has on merging. 4. The unconstrained scope is the set of all topics that are 'known' to be relevant for a Topic Map to an application. These would include: - all topics in the Topic Map under scrutiny - all topics in Topic Maps that are to be merged, either through elements (in XTM) or through user-driven or application-driven merging. This is an adaptation of ISO13250 which removes the undesired effects described above, but retains the idea. An advantage is that the unconstrained scope remains accessible, i.e. an iteration over the unconstrained scope is possible. It does not remove other peculiarities of the 13250 definition. The unconstrained scope will change when a topic is added to a Topic Map, and the unconstrained scope will be a different thing for different Topic Maps. I think 2 would be the best route unless there are difficulties involved which I have overlooked. Marc From sc34wg3@isotopicmaps.org Fri Jun 7 18:42:08 2002 From: sc34wg3@isotopicmaps.org (Bernard Vatant) Date: Fri, 7 Jun 2002 19:42:08 +0200 Subject: [sc34wg3] Which set is the unconstrained scope? (SAM-issue 'scope-unconstrained-rep') References: <01C20E44.2B927A20.marc@marcdegraauw.com> Message-ID: <012c01c20e4a$c4ce0500$0cfef9c1@montrouge.mondeca.com> Marc Your analysis is very interesting, although I don't share your conclusions. I don't think I ever expressed on that point, so here goes. Saying that the unconstrained scope is an empty set is a non-sense, saying it's the set of all topics in the topic map is as silly as can be, as you very well show ... and saying it's universal is arrogant :)) What is the natural (implicit) scope in a topic map? Well, it's obvious enough : it is the topic map itself ! All unscoped characteristics I consider valid in the limits of the topic map I built, but I can't infer of their validity outside its borders. So what? If I want to explicit this implicit scope, it contains *exactly one* topic, which represents the topic map itself. It's not empty, and it's not universal. In mathematical terms, if TM is the topic map : unconstrainedScope(TM) = {reified(TM)} This reified topic map, explicited at merging time, will be the only topic to be considered by It seems to me both intuitive, clearly defined, scalable, and does not seem to raise any philosophical nor implementation or merging problems. Moreover, demanding that merging explicits this implicit scope through a reification of the original topic map(s) keeps the more simple track one can imagine of the merging: original topic maps are represented as topics in the result of the merging. And this is a very generic principle. Merging is like gathering information from a third party ... If A asserts (x killed y) with no restriction, this means it is valid in the unconstrained scope of A. Any third party using this assertion should say : (according to A) (x killed y) Bernard - ready for the flame war :o) ------------------------------------------------------------------- Bernard Vatant Consultant - Mondeca www.mondeca.com Chair - OASIS TM PubSubj Technical Committee www.oasis-open.org/committees/tm-pubsubj/ ------------------------------------------------------------------- ----- Message d'origine ----- De : "Marc de Graauw" � : Envoy� : vendredi 7 juin 2002 16:55 Objet : [sc34wg3] Which set is the unconstrained scope? (SAM-issue 'scope-unconstrained-rep') > I have raised an issue in private conversation with Lars on the unconstrained > scope, now listed as "scope-unconstrained-rep". Description: "How should the > unconstrained scope be represented? Essentially, it is the scope made up of all > subjects, that is, the universal set.". I would like to expand on this. (Since > this is an old issue, it was probably raised by others too.) > > The current text of the SAM mentions: "If the scope of a topic characteristic > assignment is the empty set the statement is considered to have unlimited > validity, and it is said to be in the unconstrained scope." I remarked that > this should be the universal set rather than the empty set. (Or rather, since > scopes consist of topics, it should be the set of all topics.) Lars agreed that > this was an issue but was concerned about the repercussions for applications. > When an iteration over the elements of a scope is defined, this would imply an > interation over the universal set, which is not desirable. > > The current positions on what the unconstrained scope is are: > - ISO 13250: all the topics in the entire topic map ("This International > Standard does not require that scopes be specified explicitly. If the scope of > a topic characteristic assignment is not explicitly specified via one or more > scope attributes, the scope within which the topic characteristic applies to > the topic includes all the topics in the entire topic map; this special scope > is called the unconstrained scope.") > - XTM: does not say anything about which set the unconstrained scope > represents. ("Every characteristic has a scope, which may be specified either > explicitly, as a set of topics, or implicitly, in which case it is known as the > unconstrained scope. Assignments made in the unconstrained scope are always > valid.") > - PMTM4: The scope comprised of the null set of topics -- the "no-topic" scope > - DRM: nothing, scope is for the SAM > - SAM: the empty set, see above > > The ISO 13250 defintion is strange, since the unconstrained scope here is > defined to be equivalent to the scope made up of all topics in the Topic Map. > I.e. when we have a topic map which consists of two topics: > > > > > Netherlands > > > > > Marc de Graauw > > > > > then ISO 13250 would imply that this is equivalent to: > > > > > Marc de Graauw > > > > > Netherlands > > > > > Since both Topic Maps will behave differently when merging with a third one, I > do not see how this could be correct. It is also strange to use a topic to > scope it's own name as a general principle, although this would be correct in > some circumstances. Further, the second Topic Map would seem to suggest that > the basename "Marc de Graauw" is not valid outside the defined scope (or not > known to be valid), while the first Topic Map would seem to suggest that there > is no known limitation to the validity of the basename "Marc de Graauw". Though > strictly speaking this interpretation is up to applications, it still seems > counterintuitive. > > The reason it is undesirable for the unconstrained scope to be the empty set is > that applications may very well decide to ask questions such as "is that scope > a subset of this set of topics?". Since scopes are sets, such questions are > natural. If the unconstrained scope is the empty set, no scope would be a the > subset of the unconstrained scope when it would be more natural to expect every > defined scope to be a subset of the unconstrained scope. One can expect a lot > of applications to use scope in such a way that a topic characteristic > assignment in scope {a, b} is valid to a wider extent than an assignment in > scope {b}. Since assignments in the unconstrained scope are always valid, it > would seem more natural to define the unconstrained scope as {a, b, ... all > other topics ... } then as {}. > > There is, I think, a natural solution to the representation of the > unconstrained scope. We must distinguish between explicitly defined scopes and > implicitly defined scopes (XTM already does, and ISO 13250 speaks of explicitly > and not-explicitly specified scopes). Then an explicitly defined scope is a > scope element (in XTM) or attribute (in HyTM) or any corresponding data > structure in an application with topics as elements (elements meant here in the > mathematical sense, as elements of a set). An implicitly defined scope is one > required by the processing of a Topic Map syntax, i.e. the unconstrained scope > when no scope is explicitly defined. Then we could say that iteration is > allowed over explicitly defined scopes, and not over implicitly defined scopes. > > If that route is chosen, then there are several possibilities on the unconst > rained scope: > 1. It is the empty set, which is undesirable IMHO. In short, it forces > applications to implement behaviour which is at odds with what the standard > says. > 2. It is the set of all topics. Any topic is an element of the unconstrained > scope, and any set of topics is a subset of the unconstrained scope (though not > necessarily a proper subset). The elements of explicitly defined scopes are > accessible by applications, the elements of implicitly defined scopes (the > uncontrained scope) are not. > 3. Say nothing about the 'settiness' of the unconstrained scope. Explicitly > defined scopes are sets of topics, what implicitly defined scopes (and thus the > unconstrained scope) are is up to applications. The only thing that matters > about the unconstrained scope is the consequences it has on merging. > 4. The unconstrained scope is the set of all topics that are 'known' to be > relevant for a Topic Map to an application. These would include: > - all topics in the Topic Map under scrutiny > - all topics in Topic Maps that are to be merged, either through > elements (in XTM) or through user-driven or application-driven merging. > This is an adaptation of ISO13250 which removes the undesired effects described > above, but retains the idea. An advantage is that the unconstrained scope > remains accessible, i.e. an iteration over the unconstrained scope is possible. > It does not remove other peculiarities of the 13250 definition. The > unconstrained scope will change when a topic is added to a Topic Map, and the > unconstrained scope will be a different thing for different Topic Maps. > > I think 2 would be the best route unless there are difficulties involved which > I have overlooked. > > Marc > > > > _______________________________________________ > sc34wg3 mailing list > sc34wg3@isotopicmaps.org > http://www.isotopicmaps.org/mailman/listinfo/sc34wg3 > From sc34wg3@isotopicmaps.org Fri Jun 7 20:45:14 2002 From: sc34wg3@isotopicmaps.org (Marc de Graauw) Date: Fri, 7 Jun 2002 21:45:14 +0200 Subject: [sc34wg3] Which set is the unconstrained scope? (SAM-issue 'scope-unconstrained-rep') Message-ID: <01C20E6C.A51F1650.marc@marcdegraauw.com> [Bernard Vatant] > Marc > > Your analysis is very interesting, although I don't share your conclusions. I > don't think > I ever expressed on that point, so here goes. > Bernard, Thanks for your reply. I am happy to see that one of the experts in the field agrees with me on some accounts and even happier to see he disagrees on others ;-) > Saying that the unconstrained scope is an empty set is a non-sense, saying > it's the set of > all topics in the topic map is as silly as can be, as you very well show ... > and saying > it's universal is arrogant :)) Possibly. I do fear that saying it's universal is will cause all kinds of problems, it's just that I don't see them yet! > What is the natural (implicit) scope in a topic map? Well, it's obvious enough > : it is the > topic map itself ! > All unscoped characteristics I consider valid in the limits of the topic map I > built, but > I can't infer of their validity outside its borders. > > So what? If I want to explicit this implicit scope, it contains *exactly one* > topic, which > represents the topic map itself. > It's not empty, and it's not universal. I briefly thought about this solution, but quickly - maybe too quickly - dismissed it. I think there are 3 problems with it: 1) It is kind of strange to put this in a standard like the SAM. It would either require Topic Map authors to reify their Topic Map, or have a Topic Map merge process do it for them. While it is certainly often useful to reify your Topic Map, _requiring_ it would seem unnecessary. 2) What if you really want to say something that is valid always and everywhere? What if I want to express "The subject with identity 'MdG' has as its name 'Marc de Graauw', always and everywhere!" Your solution would automatically scope it down to the containing Topic Map. 3) It scales in strange way when we expand scope. Let me explain. When I have a topic map with: - a single genuine topic, name='Marc de Graauw' - a topic reifying the Topic Map, say 'The Scoping Problem Topic Map' - five themes, say 'nl', 'en', 'fr', 'de', 'es' First I have as the scope of the name 'Marc de Graauw' the set {nl}. Next I find that this name is valid in English as well, so I scope the name with {nl, en}. Et cetera, the scope becomes {nl, en, fr} and {nl, en, fr, de}. Then I find the name is valid in Spanish as well, and since it is valid in all languages under scrutiny, I decide to say the name assignment is valid in the unconstrained scope. Then I have as scope all of a sudden: scope = {The Scoping Problem Topic Map}. Alle the previous steps seem to bear a natural relation to each other, the last step does not. When (if) we want to build applications that are able to say: the scope {nl, en, fr} is a subset of the scope {nl, en, fr, de} and do something useful with that information? It would require special processing rules to do this with the reified Topic Map as scope because of this scaling problem. It is certainly a useful approach, but I think it is more an approach for a Topic Map author, not one we could use in a standard. We could, however, say nothing in a standard about what the unconstrained scope is (solution 3 in my list), and let Topic Map authors use the solution you describe whenever they wish. > > In mathematical terms, if TM is the topic map : unconstrainedScope(TM) = > {reified(TM)} > > This reified topic map, explicited at merging time, will be the only topic to > be > considered by > > It seems to me both intuitive, clearly defined, scalable, and does not seem to > raise any > philosophical nor implementation or merging problems. All true. There is another advantage: while the Topic Naming Constraint is under fire, it is very often useful (the more I think about it the better I like it). I think the problem is not so much the TNC but using the TNC *in the unconstrained scope*. Your approach would remove that problem. > Moreover, demanding that > merging > explicits this implicit scope through a reification of the original topic map > (s) keeps the > more simple track one can imagine of the merging: original topic maps are > represented as > topics in the result of the merging. > > And this is a very generic principle. Merging is like gathering information > from a third > party ... > > If A asserts (x killed y) with no restriction, this means it is valid in the > unconstrained > scope of A. > Any third party using this assertion should say : (according to A) (x killed > y) > > Bernard - ready for the flame war :o) Shoot! > > ------------------------------------------------------------------- > Bernard Vatant > Consultant - Mondeca > www.mondeca.com > Chair - OASIS TM PubSubj Technical Committee > www.oasis-open.org/committees/tm-pubsubj/ > ------------------------------------------------------------------- > > > ----- Message d'origine ----- > De : "Marc de Graauw" > A : > Envoye : vendredi 7 juin 2002 16:55 > Objet : [sc34wg3] Which set is the unconstrained scope? (SAM-issue > 'scope-unconstrained-rep') > > > > I have raised an issue in private conversation with Lars on the > > unconstrained > > scope, now listed as "scope-unconstrained-rep". Description: "How should > > the > > unconstrained scope be represented? Essentially, it is the scope made up of > > all > > subjects, that is, the universal set.". I would like to expand on this. > > (Since > > this is an old issue, it was probably raised by others too.) > > > > The current text of the SAM mentions: "If the scope of a topic > > characteristic > > assignment is the empty set the statement is considered to have unlimited > > validity, and it is said to be in the unconstrained scope." I remarked that > > this should be the universal set rather than the empty set. (Or rather, > > since > > scopes consist of topics, it should be the set of all topics.) Lars agreed > > that > > this was an issue but was concerned about the repercussions for > > applications. > > When an iteration over the elements of a scope is defined, this would imply > > an > > interation over the universal set, which is not desirable. > > > > The current positions on what the unconstrained scope is are: > > - ISO 13250: all the topics in the entire topic map ("This International > > Standard does not require that scopes be specified explicitly. If the scope > > of > > a topic characteristic assignment is not explicitly specified via one or > > more > > scope attributes, the scope within which the topic characteristic applies > > to > > the topic includes all the topics in the entire topic map; this special > > scope > > is called the unconstrained scope.") > > - XTM: does not say anything about which set the unconstrained scope > > represents. ("Every characteristic has a scope, which may be specified > > either > > explicitly, as a set of topics, or implicitly, in which case it is known as > > the > > unconstrained scope. Assignments made in the unconstrained scope are always > > valid.") > > - PMTM4: The scope comprised of the null set of topics -- the "no-topic" > > scope > > - DRM: nothing, scope is for the SAM > > - SAM: the empty set, see above > > > > The ISO 13250 defintion is strange, since the unconstrained scope here is > > defined to be equivalent to the scope made up of all topics in the Topic > > Map. > > I.e. when we have a topic map which consists of two topics: > > > > > > > > > > Netherlands > > > > > > > > > > Marc de Graauw > > > > > > > > > > then ISO 13250 would imply that this is equivalent to: > > > > > > > > > > Marc de Graauw > > > > > > > > > > Netherlands > > > > > > > > > > Since both Topic Maps will behave differently when merging with a third one, > > I > > do not see how this could be correct. It is also strange to use a topic to > > scope it's own name as a general principle, although this would be correct > > in > > some circumstances. Further, the second Topic Map would seem to suggest > > that > > the basename "Marc de Graauw" is not valid outside the defined scope (or > > not > > known to be valid), while the first Topic Map would seem to suggest that > > there > > is no known limitation to the validity of the basename "Marc de Graauw". > > Though > > strictly speaking this interpretation is up to applications, it still seems > > counterintuitive. > > > > The reason it is undesirable for the unconstrained scope to be the empty set > > is > > that applications may very well decide to ask questions such as "is that > > scope > > a subset of this set of topics?". Since scopes are sets, such questions are > > natural. If the unconstrained scope is the empty set, no scope would be a > > the > > subset of the unconstrained scope when it would be more natural to expect > > every > > defined scope to be a subset of the unconstrained scope. One can expect a > > lot > > of applications to use scope in such a way that a topic characteristic > > assignment in scope {a, b} is valid to a wider extent than an assignment in > > scope {b}. Since assignments in the unconstrained scope are always valid, > > it > > would seem more natural to define the unconstrained scope as {a, b, ... all > > other topics ... } then as {}. > > > > There is, I think, a natural solution to the representation of the > > unconstrained scope. We must distinguish between explicitly defined scopes > > and > > implicitly defined scopes (XTM already does, and ISO 13250 speaks of > > explicitly > > and not-explicitly specified scopes). Then an explicitly defined scope is a > > scope element (in XTM) or attribute (in HyTM) or any corresponding data > > structure in an application with topics as elements (elements meant here in > > the > > mathematical sense, as elements of a set). An implicitly defined scope is > > one > > required by the processing of a Topic Map syntax, i.e. the unconstrained > > scope > > when no scope is explicitly defined. Then we could say that iteration is > > allowed over explicitly defined scopes, and not over implicitly defined > > scopes. > > > > If that route is chosen, then there are several possibilities on the > > unconst > > rained scope: > > 1. It is the empty set, which is undesirable IMHO. In short, it forces > > applications to implement behaviour which is at odds with what the standard > > says. > > 2. It is the set of all topics. Any topic is an element of the > > unconstrained > > scope, and any set of topics is a subset of the unconstrained scope (though > > not > > necessarily a proper subset). The elements of explicitly defined scopes are > > accessible by applications, the elements of implicitly defined scopes (the > > uncontrained scope) are not. > > 3. Say nothing about the 'settiness' of the unconstrained scope. Explicitly > > defined scopes are sets of topics, what implicitly defined scopes (and thus > > the > > unconstrained scope) are is up to applications. The only thing that matters > > about the unconstrained scope is the consequences it has on merging. > > 4. The unconstrained scope is the set of all topics that are 'known' to be > > relevant for a Topic Map to an application. These would include: > > - all topics in the Topic Map under scrutiny > > - all topics in Topic Maps that are to be merged, either through > > elements (in XTM) or through user-driven or application-driven merging. > > This is an adaptation of ISO13250 which removes the undesired effects > > described > > above, but retains the idea. An advantage is that the unconstrained scope > > remains accessible, i.e. an iteration over the unconstrained scope is > > possible. > > It does not remove other peculiarities of the 13250 definition. The > > unconstrained scope will change when a topic is added to a Topic Map, and > > the > > unconstrained scope will be a different thing for different Topic Maps. > > > > I think 2 would be the best route unless there are difficulties involved > > which > > I have overlooked. > > > > Marc > > > > > > > > _______________________________________________ > > sc34wg3 mailing list > > sc34wg3@isotopicmaps.org > > http://www.isotopicmaps.org/mailman/listinfo/sc34wg3 > > > > _______________________________________________ > sc34wg3 mailing list > sc34wg3@isotopicmaps.org > http://www.isotopicmaps.org/mailman/listinfo/sc34wg3 > From sc34wg3@isotopicmaps.org Fri Jun 7 22:16:49 2002 From: sc34wg3@isotopicmaps.org (Bernard Vatant) Date: Fri, 7 Jun 2002 23:16:49 +0200 Subject: [sc34wg3] Which set is the unconstrained scope? (SAM-issue 'scope-unconstrained-rep') References: <01C20E6C.A51F1650.marc@marcdegraauw.com> Message-ID: <002b01c20e68$a3f930c0$6601a8c0@bernard> Marc > 1) It is kind of strange to put this in a standard like the SAM. It would > either require Topic Map authors to reify their Topic Map, or have a Topic Map > merge process do it for them. While it is certainly often useful to reify your > Topic Map, _requiring_ it would seem unnecessary. Reification might not be required. Another way would be (have been) to have as direct child of itself. And when this element is not explicited, then the default scope would be the reified . or something like that. > 2) What if you really want to say something that is valid always and > everywhere? What if I want to express "The subject with identity 'MdG' has as > its name 'Marc de Graauw', always and everywhere!" Your solution would > automatically scope it down to the containing Topic Map. Well ... "valid always and everywhere" is something I would never dare asserting. Or publish a PSI for your notion of "always and everyhere" and use it as a scope. > 3) It scales in strange way when we expand scope. Let me explain. > > When I have a topic map with: > - a single genuine topic, name='Marc de Graauw' > - a topic reifying the Topic Map, say 'The Scoping Problem Topic Map' > - five themes, say 'nl', 'en', 'fr', 'de', 'es' > First I have as the scope of the name 'Marc de Graauw' the set {nl}. Next I > find that this name is valid in English as well, so I scope the name with {nl, > en}. Huh. Your proper name is not attached to you in a specific language. Why do you scope it with your native language? > Et cetera, the scope becomes {nl, en, fr} and {nl, en, fr, de}. Then I find > the name is valid in Spanish as well, and since it is valid in all languages > under scrutiny, I decide to say the name assignment is valid in the > unconstrained scope. OK. We meet here. > Then I have as scope all of a sudden: scope = {The Scoping > Problem Topic Map}. Alle the previous steps seem to bear a natural relation to > each other, the last step does not. When (if) we want to build applications > that are able to say: the scope {nl, en, fr} is a subset of the scope {nl, en, > fr, de} and do something useful with that information? It would require special > processing rules to do this with the reified Topic Map as scope because of this > scaling problem. I'm afraid I miss your point. Maybe we should test that on less academic examples :)) > It is certainly a useful approach, but I think it is more an approach for a > Topic Map author, not one we could use in a standard. We could, however, say > nothing in a standard about what the unconstrained scope is (solution 3 in my > list), and let Topic Map authors use the solution you describe whenever they > wish. Hmmm. I don't know if it's a good idea. This scope issue is too tricky to let poor authors deal with it :) > There is another advantage: while the Topic Naming Constraint is > under fire, it is very often useful (the more I think about it the better I > like it). I think the problem is not so much the TNC but using the TNC *in the > unconstrained scope*. Your approach would remove that problem. I had not thought about it, but that seems to be true. Good point. > Shoot! "Same player shoots again" Good night Bernard From sc34wg3@isotopicmaps.org Sun Jun 9 13:31:18 2002 From: sc34wg3@isotopicmaps.org (Marc de Graauw) Date: Sun, 9 Jun 2002 14:31:18 +0200 Subject: [sc34wg3] Which set is the unconstrained scope? (SAM-issue 'scope-unconstrained-rep') Message-ID: <01C20FC2.561E8CF0.marc@marcdegraauw.com> [Bernard Vatant] > Marc > > > 1) It is kind of strange to put this in a standard like the SAM. It would > > either require Topic Map authors to reify their Topic Map, or have a Topic > > Map > > merge process do it for them. While it is certainly often useful to reify > > your > > Topic Map, _requiring_ it would seem unnecessary. > > Reification might not be required. Another way would be (have been) to have > as > direct child of itself. > And when this element is not explicited, then the default scope would be the > reified > . or something like that. > That's what I mean. A Topic Map engine would add topics (reified Topic Maps) to my merged Topic Map that I haven't asked for. > > 2) What if you really want to say something that is valid always and > > everywhere? What if I want to express "The subject with identity 'MdG' has > > as > > its name 'Marc de Graauw', always and everywhere!" Your solution would > > automatically scope it down to the containing Topic Map. > > Well ... "valid always and everywhere" is something I would never dare > asserting. Hmmm. There are statements that are very hard to scope. 'Marc de Graauw' is my name in any context. While it is true that I did not exist in the past, Nostradamus could have said 'There will be a man called "Marc de Graauw" one day". And while not everybody knows me, saying 'Nobody in Buenos Aires knows "Marc de Graauw"' is a maeningful statement. So if scope is an extent of validity, how do I meaningfully scope the assignment of the name 'Marc de Graauw' to a subject with a certain identity? I certainly want to assert much more than 'The name of this subject is "Marc de Graauw" within the context of this Topic Map', which your interpretation of the unconstrained scope would imply if I do not scope my assertion explicitly. Yet what scope do I choose for my assertion? Most scopes I can think of (region, language, time period, profession etc.) are much more restrictive than I want. So what scope do I choose? Your interpretation of the unconstrained scope is at odds with XTM, where it says "Assignments made in the unconstrained scope are always valid", though it is not at odds with ISO 13250 where no such statement is made. (Of course being at odds with XTM is not necessarily a problem as the XTM and ISO 13250 have different positions on this subject.) > Or publish a PSI for your notion of "always and everyhere" and use it as a > scope. I cannot publish PSI's as I am not an organization with the long-term commitment that publishing PSI's requires, but maybe you could :-) > I'm afraid I miss your point. Maybe we should test that on less academic > examples :)) > This was a very bad example on my part. Let's try another one: In my 'Business Map' Topic Map (www.marcdegraauw.com/itm) I want to scope associations by (among other things) Business Department: Sales, Marketing, et cetera. The association I want to scope is a mapping between elements in Business vocabularies, i.e. 'company_name can be used as CustomerName'. CustomerName and company_name are (names of) topics themselves. I do not use subject indicators because these assertions are unidirectional, i.e. I do not know whether 'CustomerName can be used as company_name'. When I scope the assignment with {Sales}, I want to assert that the mapping maybe used for the business processes of the department Sales. When I scope with {Sales, Marketing} I want to assert that the mapping maybe used for the business processes of the department Sales and for those of Marketing. When I do not scope explicitly, I want to assert that the mapping is valid for all Business Departments, not only as a coincidence (all existing business departments to have this this mapping) but as a general rule (the definition of CustomerName is such that it is a subset of company_name and thus the mapping is always valid). Now when I merge, I will often need to clean up the resulting topic map. For instance, the resulting Topic Map might have two associations: - 'CustomerName can be used as company_name' within scope {Sales} - 'CustomerName can be used as company_name' within scope {Sales, Marketing} The first association can be thrown away, since the second one already says that the mapping is valid for business processes of the Sales department, and if the Topic Maps are large this would result in an enormous clutter of redundant associations. So my application needs a process that cleans up the resulting Topic Map according to this rule: If there are two associations that are equal in all respects except scope, and the scope of the former one is a subset of the scope of the latter one, the former one can be removed. Now when the unconstrained scope is the set of all topics, I could use the unconstrained scope for associations that are valid for all business departments, and this rule would work fine. For instance, when a Topic Map would contain: - 'CustomerName can be used as company_name' within scope {Sales} - 'CustomerName can be used as company_name' the first association would be cleaned up because {Sales} is a subset of the set of all topics, and this is what I want. When your interpretation of the unconstrained scope were implemented in the Topic Map engine I use for merging, I could no longer use the unconstrained scope for this purpose, because the Topic Map engine would generate: - 'CustomerName can be used as company_name' within scope {Sales} - 'CustomerName can be used as company_name' within scope {reified_originating_topic_map} and {Sales} is not a subset of {reified_originating_topic_map}. This is what I mean when I say your solution does not scale well when we expand scope. I would thus be forced to scope associations that are valid for all business departments with either: 1) all business departments, which is a maintenance nightmare when new business departments are added, or, 2) a scope meaning all business departments, existing and future, i.e. scope it with {this_thing_means_all_departments}. Now the problem with this second option is that {Sales, Marketing} is not a subset of {this_thing_means_all_departments} (since the second set only contains a single element and not all departments). So I would need to build a special rule into my cleanup process: If there are two associations that are equal in all respects except scope, and the scope of the former one is a subset of the scope of the latter one OR THE SCOPE OF THE LATTER ONE IS {this_thing_means_all_departments} THEN the former one can be removed. This would work, but the solution with the unconstrained scope is much more elegant. Of course I do not want to argue the standard should define the unconstrained scope as the set of all topics because this would solve my problem. The point is that the behaviour of the Topic Map I described above is of a very general type, and I think a lot of applications would want to have implement similar behaviour. What I argue is that the unconstrained scope was intended for this kind of behaviour, at least in XTM ("Assignments made in the unconstrained scope are always valid") and that the representation of the unconstrained scope as the set of all topics is in line with this behaviour. Another point: you propose another solution as the representation of the unconstrained scope, and I agree it's a viable and intelligent alternative, though I'm not convinced yet it is the best solution. However, in your first response you write: > Saying that the unconstrained scope is an empty set is a non-sense, saying it's the set of > all topics in the topic map is as silly as can be, as you very well show ... and saying > it's universal is arrogant :)) You are a mathematician. So what is wrong with the alternative of saying the unconstrained scope is the set of all topics? Does it lead to problems if we use that solution? Marc From sc34wg3@isotopicmaps.org Sun Jun 9 18:08:22 2002 From: sc34wg3@isotopicmaps.org (Lars Marius Garshol) Date: 09 Jun 2002 19:08:22 +0200 Subject: [sc34wg3] Which set is the unconstrained scope? (SAM-issue 'scope-unconstrained-rep') In-Reply-To: <01C20E44.2B927A20.marc@marcdegraauw.com> References: <01C20E44.2B927A20.marc@marcdegraauw.com> Message-ID: It seems to me that this issue depends on the term-scope-def issue[1], in that it depends on whether a scope is made up of the intersection of its themes or whether it is defined by each of those themes individually. (Note: previous drafts of the SAM said "union", but meant "intersection".) I think that before we have agreed on this we won't be able to make any progress. Let's assume for the moment that a scope *is* made up from the intersection of its themes. If we then have the three scopes 1. {} 2. {a} 3. {a, b} it follows that characteristics in 3. have a more restricted validity than those in 2., and that those in 1. are the least restricted of all. Given this, let's look at the proposed ways to represent the unconstrained scope (the first four from Marc, the last from Bernard): 1. It is the empty set. To me this solution seems reasonable, although it is not free from problems. 2. It is the set of all topics. This has the problem that this makes the unconstrained scope the most restrictive of all scopes. It is only valid when *all* topics apply. Clearly, this makes no sense. 3. Say nothing about the 'settiness' of the unconstrained scope. This does not work, unfortunately, since the SAM says that [scope] is a set of topic items and will require a specific representation for the unconstrained scope. 4. The unconstrained scope is the set of all topics that are 'known' to be relevant for a Topic Map to an application. This is what ISO 13250 does, and as Marc has pointed out it just does not work. 5. It is made up of the topic map itself. This corresponds well with common sense, but it would require the topic map topic to be added to all the scopes in the topic map in order not to wreak havoc with the restrictiveness ordering. So I think we can dismiss 2., 3., and 4. straight away (in this universe, that is). 1. and 5. require a closer look, I think. --- 1. The empty set * Marc de Graauw | | The reason it is undesirable for the unconstrained scope to be the | empty set is that applications may very well decide to ask questions | such as "is that scope a subset of this set of topics?". Since | scopes are sets, such questions are natural. If the unconstrained | scope is the empty set, no scope would be a the subset of the | unconstrained scope when it would be more natural to expect every | defined scope to be a subset of the unconstrained scope | One can expect a lot of applications to use scope in such a way that | a topic characteristic assignment in scope {a, b} is valid to a | wider extent than an assignment in scope {b}. Since assignments in | the unconstrained scope are always valid, it would seem more natural | to define the unconstrained scope as {a, b, ... all other topics | ... } then as {}. This position assumes that scope is not a intersection, but that each topic contributes individually. If scope is an intersection it makes sense for the unconstrained scope to be the empty set. You would then ask: which of the scopes {} and {a} (or {a} and {a, b}) have wider applicability, and clearly that would be the first. * Bernard Vatant | | Saying that the unconstrained scope is an empty set is a non-sense | [...] Maybe it is, but you have yet to argue that point, Bernard. Later on, we will want a "find all characteristics valid in scope X"-operator, and looking into this in my opinion favours this solution. The desired result of that operation (still assuming scope is a union) is shown in the table below. (I use {} to mean the unconstrained scope.) X | characteristic scope | result ---------+-----------------------+------- {} | {} | valid {} | {a} | invalid {a} | {} | valid {a} | {a} | valid {a} | {a, b} | invalid {a} | {b} | invalid {a, b} | {} | valid {a, b} | {a} | valid {a, b} | {a, b} | valid {a, b} | {a, b, c} | invalid {a, b} | {d} | invalid So it would seem that a characteristic is valid in context X as long as its scope is a subset of X, and as far as I can make out this resolution causes no problems with that. --- 5. The topic map topic As Bernard says, this solution is intuitively appealing, but in the universe where scope is an intersection it only works if *all* scopes have the topic map topic added to them. Once they do then the only difference with resolution 1. is whether or not the topic map topic is present in all scopes. Marc was uneasy about what this would mean for processing, but I see no problem there. A topic map processor would, if necessary, create a topic item reifying the topic map item, and move on. This is no different from how HyTM importers are required to create topics representing the sort-theme and the display-theme. The question is: what would be the gain in requiring every scope to be expanded with one theme? It's not clear to me that that makes a lot of sense or in any real sense simplifies anything. Conceptually, it is correct, but I am not sure it makes sense to require it to be represented explicitly. Furthermore, what happens with merging then? I import topic map A, then import topic map B, and finally I merge them, producing topic map C. Now, what is the scope of the unconstrained characteristics coming from topic map A? Topic map A, or topic map C? However, as I said, I think this issue very much depends on the "is scope intersection or union" issue (term-scope-def). We should create another thread for that issue first, settle that, then come back here and settle this issue. I'll start that thread right away. [1] -- Lars Marius Garshol, Ontopian ISO SC34/WG3, OASIS GeoLang TC From sc34wg3@isotopicmaps.org Sun Jun 9 18:10:01 2002 From: sc34wg3@isotopicmaps.org (Lars Marius Garshol) Date: 09 Jun 2002 19:10:01 +0200 Subject: [sc34wg3] Which set is the unconstrained scope? (SAM-issue 'scope-unconstrained-rep') In-Reply-To: <002b01c20e68$a3f930c0$6601a8c0@bernard> References: <01C20E6C.A51F1650.marc@marcdegraauw.com> <002b01c20e68$a3f930c0$6601a8c0@bernard> Message-ID: * Marc de Grauw | | 1) It is kind of strange to put this in a standard like the SAM. It | would either require Topic Map authors to reify their Topic Map, or | have a Topic Map merge process do it for them. While it is certainly | often useful to reify your Topic Map, _requiring_ it would seem | unnecessary. * Bernard Vatant | | Reification might not be required. Another way would be (have been) | to have as direct child of itself. And when this | element is not explicited, then the default scope would be the | reified . or something like that. That's a purely syntactic proposal; in the model the result would still be reification. Also, it's not at all clear that this proposal solves this particular problem. You can then scope the topic map, but how does that affect the unconstrained scopes? | Well ... "valid always and everywhere" is something I would never | dare asserting. I agree. Every topic map is implicitly a theme in all scopes in that topic map. Whether that needs to be represented explicitly is another matter. -- Lars Marius Garshol, Ontopian ISO SC34/WG3, OASIS GeoLang TC From sc34wg3@isotopicmaps.org Sun Jun 9 18:20:45 2002 From: sc34wg3@isotopicmaps.org (Lars Marius Garshol) Date: 09 Jun 2002 19:20:45 +0200 Subject: [sc34wg3] Which set is the unconstrained scope? (SAM-issue 'scope-unconstrained-rep') In-Reply-To: <01C20FC2.561E8CF0.marc@marcdegraauw.com> References: <01C20FC2.561E8CF0.marc@marcdegraauw.com> Message-ID: * Marc de Graauw | | Hmmm. There are statements that are very hard to scope. 'Marc de | Graauw' is my name in any context. [...] Most scopes I can think of | (region, language, time period, profession etc.) are much more | restrictive than I want. So what scope do I choose? I wouldn't choose any scope at all. I don't see that any scope that you might add to the name would provide any useful information to anyone. As you say, that *is* your name, irrespective of context. Using scope to create topic name namespaces is a different use of scope from the constraining of validity, and the two should not be confused with one another. | I cannot publish PSI's as I am not an organization with the | long-term commitment that publishing PSI's requires, but maybe you | could :-) You could, Marc. A PSI just needs a publisher. A publisher that will be around in perpetuity is better than one that won't, but such publishers are in short supply, and people will use what they find useful in any case. (That is, don't require things to be so perfect before you do them that you prevent yourself from doing anything at all.) | The association I want to scope is a mapping between elements in | Business vocabularies, i.e. 'company_name can be used as | CustomerName'. CustomerName and company_name are (names of) topics | themselves. I do not use subject indicators because these assertions | are unidirectional, i.e. I do not know whether 'CustomerName can be | used as company_name'. When I scope the assignment with {Sales}, I | want to assert that the mapping maybe used for the business | processes of the department Sales. When I scope with {Sales, | Marketing} I want to assert that the mapping maybe used for the | business processes of the department Sales and for those of | Marketing. When I do not scope explicitly, I want to assert that the | mapping is valid for all Business Departments, not only as a | coincidence (all existing business departments to have this this | mapping) but as a general rule (the definition of CustomerName is | such that it is a subset of company_name and thus the mapping is | always valid). This sounds to me like a good and pragmatic use of scope. The validity may not actually be unconstrained, but within your topic map it is unconstrained. | Now when I merge, I will often need to clean up the resulting topic | map. For instance, the resulting Topic Map might have two | associations: | - 'CustomerName can be used as company_name' within scope {Sales} | - 'CustomerName can be used as company_name' within scope {Sales, Marketing} | | The first association can be thrown away, since the second one | already says that the mapping is valid for business processes of the | Sales department, and if the Topic Maps are large this would result | in an enormous clutter of redundant associations. So my application | needs a process that cleans up the resulting Topic Map according to | this rule: If there are two associations that are equal in all | respects except scope, and the scope of the former one is a subset | of the scope of the latter one, the former one can be removed. Yes, but this assumes that scope is a union. | Now when the unconstrained scope is the set of all topics, I could | use the unconstrained scope for associations that are valid for all | business departments, and this rule would work fine. For instance, | when a Topic Map would contain: | | - 'CustomerName can be used as company_name' within scope {Sales} | - 'CustomerName can be used as company_name' | | the first association would be cleaned up because {Sales} is a | subset of the set of all topics, and this is what I want. As I showed, if scope is an intersection it would work equally well if the unconstrained scope is the empty set. | When your interpretation of the unconstrained scope were implemented | in the Topic Map engine I use for merging, I could no longer use the | unconstrained scope for this purpose, because the Topic Map engine | would generate: | | - 'CustomerName can be used as company_name' within scope {Sales} | - 'CustomerName can be used as company_name' within scope | {reified_originating_topic_map} | | and {Sales} is not a subset of {reified_originating_topic_map}. This | is what I mean when I say your solution does not scale well when we | expand scope. Agreed. (Unless the reified_originating_topic_map is added to *all* the scopes.) -- Lars Marius Garshol, Ontopian ISO SC34/WG3, OASIS GeoLang TC From sc34wg3@isotopicmaps.org Sun Jun 9 18:45:32 2002 From: sc34wg3@isotopicmaps.org (Lars Marius Garshol) Date: 09 Jun 2002 19:45:32 +0200 Subject: [sc34wg3] SAM-issue term-scope-def Message-ID: In ISO 13250 the definition of scope says that scope is the union of the themes. That is, [finland = "Finland" / norwegian swedish] means that the name "Finland" is valid in Norwegian and that it is also valid in Swedish. XTM 1.0, on the other hand says that it is up to the application how to interpret the scope. The current SAM version[1] says scope is the intersection of the themes, which means that this particular scope would only be valid in *both* Norwegian *and* Swedish at the same time, which would require the topic to be written in this way: [finland = "Finland" / norwegian = "Finland" / swedish] On the other hand, that something is my opinion today could according to the SAM be expressed by scoping it with topics representing me and today. ISO 13250 explains in a note that to say this would require a topic representing me today would have to be created and used as the scope. (No mechanism is provided for doing so in ISO 13250, however.) The question is, which of these three approaches should we choose? I think we need to consider carefully the consequences for the unconstrained scope, for merging, and also for querying operations. --- Scope is union If we say that scope is union that would mean that the following topic [finland = "Finland" / norwegian swedish = "Finland" / norwegian = "Finland" / swedish] contains two redundancies, and is actually equivalent to [finland = "Finland" / norwegian swedish] which would seem to imply that the rules for equivalence and redundancy elimination need to be modified. Furthermore, if associations with published subjects are necessary to form compound scope it means that in order to answer the question "what occurrences of the topic 'term-scope-def' are valid in the scope 'lmg'" correctly when presented with {term-scope-def, opinion, ""} / lmg-today the topic map processor would have to traverse associations to evaluate the scope correctly, and building compound scopes becomes very cumbersome. --- Scope is intersection This means that to assert that something is valid in two different contexts requires it to be repeated. This seems like the lesser evil. It also means that the arithmetic of scope works well with the unconstrained scope being the empty set. (See previous email.) --- Scope is unspecified One of the mechanisms for merging (TNC merging) would then depend on a feature whose meaning is unspecified. Furthermore, when attempting to merge topic maps that interpreted scope differently one would be bound to get suboptimal results. Furthermore, we would have to create TMQL scope operators for a construct whose interpretation is undefined. In short, this does not seem to work very well. [1] Versions of SAM prior to 1.23 had an editorial error in the definition of scope. -- Lars Marius Garshol, Ontopian ISO SC34/WG3, OASIS GeoLang TC From sc34wg3@isotopicmaps.org Sun Jun 9 20:55:42 2002 From: sc34wg3@isotopicmaps.org (Jan Algermissen) Date: Sun, 09 Jun 2002 21:55:42 +0200 Subject: [sc34wg3] Which set is the unconstrained scope? (SAM-issue 'scope-unconstrained-rep') References: <01C20FC2.561E8CF0.marc@marcdegraauw.com> Message-ID: <3D03B2BD.2673F86F@acm.org> [Marc] > | I cannot publish PSI's as I am not an organization with the > | long-term commitment that publishing PSI's requires, but maybe you > | could :-) [Lars] > You could, Marc. A PSI just needs a publisher. A publisher that will > be around in perpetuity is better than one that won't, but such > publishers are in short supply, and people will use what they find > useful in any case. (That is, don't require things to be so perfect > before you do them that you prevent yourself from doing anything at > all.) Marc, I had the same understanding as you a short while ago. But it's actually very simple: If you make a topic map you should tell users of that map what the subjects of your topics are. The best road to go is, of course, to find some stable, published resources to use as subject indicators, but if they don't exist or you don't know them, well, just make an HTML page, write down what you consider the subject of your topic and publish that page. Voila, there is your PSI and users of your map will be glad they have something where they can find out what the subject of your topic is. If you find a highly authoritive PSI in the future you can allways add it and thus contribute to better global information interchange. Jan From sc34wg3@isotopicmaps.org Sun Jun 9 21:11:10 2002 From: sc34wg3@isotopicmaps.org (Jan Algermissen) Date: Sun, 09 Jun 2002 22:11:10 +0200 Subject: [sc34wg3] SAM-issue term-scope-def References: Message-ID: <3D03B65E.AB18F7C6@acm.org> Lars-- I think that it would really help to introduce a notion of 'user scope' or 'observer scope', being a set of topics. You would then be able to apply set theory more formaly. For example you then can say that 'and association is valid in the user context U if the association's scoping topic set S is a subset of U' or whatever the final interpretation will be. Jan -- Jan Algermissen Consultant & Programmer Tel: ++49 (0)40 89 700 511 Fax: ++49 (0)40 89 700 841 Email: algermissen@acm.org Web: http://www.topicmapping.com From sc34wg3@isotopicmaps.org Sun Jun 9 21:19:33 2002 From: sc34wg3@isotopicmaps.org (Lars Marius Garshol) Date: 09 Jun 2002 22:19:33 +0200 Subject: [sc34wg3] SAM-issue term-scope-def In-Reply-To: <3D03B65E.AB18F7C6@acm.org> References: <3D03B65E.AB18F7C6@acm.org> Message-ID: * Jan Algermissen | | I think that it would really help to introduce a notion of 'user | scope' or 'observer scope', being a set of topics. That does make sense. Ontopia has already used a terminology of "object scope" (meaning the scope of a topic characteristic assignment) and "context scope" (meaning the same as your two terms) internally, as well as in Steve and Geir Ove's scope paper. It has worked well for us, and certainly made discussion much easier. On the other hand, I am not sure if such a term is appropriate in the topic maps standard itself. It may be that it belongs in a separate context, such as TMQL. Or maybe we should just it in ISO 13250. | You would then be able to apply set theory more formaly. For example | you then can say that | | 'and association is valid in the user context U if the | association's scoping topic set S is a subset of U' | | or whatever the final interpretation will be. Agreed. -- Lars Marius Garshol, Ontopian ISO SC34/WG3, OASIS GeoLang TC From sc34wg3@isotopicmaps.org Sun Jun 9 21:49:41 2002 From: sc34wg3@isotopicmaps.org (Lars Marius Garshol) Date: 09 Jun 2002 22:49:41 +0200 Subject: [sc34wg3] New roadmap draft Message-ID: I've now posted a new roadmap draft to Comments are welcome, as always. I am hoping this will be the final draft. -- Lars Marius Garshol, Ontopian ISO SC34/WG3, OASIS GeoLang TC From sc34wg3@isotopicmaps.org Thu Jun 13 07:53:53 2002 From: sc34wg3@isotopicmaps.org (Bernard Vatant) Date: Thu, 13 Jun 2002 08:53:53 +0200 Subject: [sc34wg3] SAM-issue term-scope-def References: Message-ID: <001301c212a7$606ba160$6601a8c0@bernard> Hello all. Lars Marius asked me on another forum to bite here. Well, I was very uneasy with that issue until yesterday night, then I got the following idea(s), which maybe could help. Sorry, it's a bit long. But I tried to be very explicit. Thanks for your time and attention. I've figured so far scope as a bag where you could put so many different things that no general rule how to process it could be really set, other than arbitrary or "less evil", as Lars Marius tried to figure below . But in fact there is a way to entangle that, if you begin by expliciting the implicit (meta)association expressed by scope. The role-players of this (meta)association are: 1. The scoped assertion itself (reified) 2. The elements of the scope set (scoping topics) Note that "assertion" in 1 is to be understood in the most generic sense: any assertion that can be scoped, including regular associations, topic-name and topic-occurrence associations. If the role of the first member (assertion) is clearly specified (scoped), the role of the scoping members are not specified, further than "scoping" ... which is a very poor semantic indeed. That's where the issue comes from. If you specify, like in any regular association, the role of scoping topics, things become clearer and the conclusion is easier to draw and quite natural. Let's take an example. "Henry is King of Navarre and King of France from 1589 to 1610" Express that using the basic assertion "Henry is King", the rest of information being expressed as scopes. Note BTW that this assertion can be expressed like a regular association between Henri (person) and a status (King), or the attachment of a name (Henri) to a topic (King) ... and that it does not matter in fact. In any case, we have three scoping elements : France, Navarre, and the time span. Clearly, the two former have a "space" role, and the latter a "time" role in the scoping meta-association. So if you express it explicitly, quite obviously you have the following members: {Henri is King} (scoped assertion) {France, Navarre} (space scope) {1589-1610} (time scope) Now it figures that scopes playing the same role are first gathered by a "OR" (union?), and resulting sets (members) are gathered by a "AND" (intersection?) to get the global scope. More precisely: "Henri is King" is valid if ("space belongs to Navarre" OR "space belongs to France") AND "time belongs to 1589-1610". It figures another thing. Asserting a scope seems to be in that case setting implicitly the domain of two variables, "space" and "time". The nature of those variables are expressed by the role specifications in the meta-association. If we try to draw a general rule for that: If : the scope set is S = {Ai, Bi, ..., Xi, ...} where A, B, ..., X are scoping variables and Ai, Bi, ..., Xi values of those variables. Then : the scoped assertion is valid if AND( A belongs to {Ai} , B belongs to {Bi} ... X belongs to {Xi} ) It seems that this is very generic, the scoping variable-role, besides time and space, could be language, source, thesaurus, market sector ... whatever. Of course, this rule can be applied if roles of scoping elements are specified. Maybe the standard should be extended to include that? From a syntax viewpoint, it would mean allowing as child of ... Sorry to speak syntax here :)) What about now unconstrained scope and merging? The original source(s) of merging being added to scopes as reified topic maps in the merged map, as I suggested in a previous post, seems consistent with that. The original topic map plays role "source". In the above example, you could add to scope that the assertion (unauthorized) source is "TM-BV". So, after merging, you would have another member in the scoping meta-association: {Henri is King} (scoped assertion) {France, Navarre} (space scope) {1589-1610} (time scope) {BV} (source scope) If you have the same assertion confirmed by "Larousse 1972" (just checked), this will be added to the source member: {Henri is King} (scoped assertion) {France, Navarre} (space scope) {1589-1610} (time scope) {BV, Larousse} (source scope) Well. I think that makes it for my 0.02 Euros. Bernard ------------------------------------------------------------------- Bernard Vatant Consultant - Mondeca www.mondeca.com Chair - OASIS TM PubSubj Technical Committee www.oasis-open.org/committees/tm-pubsubj/ ------------------------------------------------------------------- ----- Message d'origine ----- De : "Lars Marius Garshol" � : Envoy� : dimanche 9 juin 2002 19:45 Objet : [sc34wg3] SAM-issue term-scope-def > > In ISO 13250 the definition of scope says that scope is the union of > the themes. That is, > > [finland = "Finland" / norwegian swedish] > > means that the name "Finland" is valid in Norwegian and that it is > also valid in Swedish. > > XTM 1.0, on the other hand says that it is up to the application how > to interpret the scope. > > The current SAM version[1] says scope is the intersection of the > themes, which means that this particular scope would only be valid in > *both* Norwegian *and* Swedish at the same time, which would require > the topic to be written in this way: > > [finland = "Finland" / norwegian > = "Finland" / swedish] > > On the other hand, that something is my opinion today could according > to the SAM be expressed by scoping it with topics representing me and > today. ISO 13250 explains in a note that to say this would require a > topic representing me today would have to be created and used as the > scope. (No mechanism is provided for doing so in ISO 13250, however.) > > > The question is, which of these three approaches should we choose? I > think we need to consider carefully the consequences for the > unconstrained scope, for merging, and also for querying operations. > > > --- Scope is union > > If we say that scope is union that would mean that the following topic > > [finland = "Finland" / norwegian swedish > = "Finland" / norwegian > = "Finland" / swedish] > > contains two redundancies, and is actually equivalent to > > [finland = "Finland" / norwegian swedish] > > which would seem to imply that the rules for equivalence and > redundancy elimination need to be modified. > > Furthermore, if associations with published subjects are necessary to > form compound scope it means that in order to answer the question > "what occurrences of the topic 'term-scope-def' are valid in the scope > 'lmg'" correctly when presented with > > {term-scope-def, opinion, ""} / lmg-today > > the topic map processor would have to traverse associations to > evaluate the scope correctly, and building compound scopes becomes > very cumbersome. > > > --- Scope is intersection > > This means that to assert that something is valid in two different > contexts requires it to be repeated. This seems like the lesser evil. > It also means that the arithmetic of scope works well with the > unconstrained scope being the empty set. (See previous email.) > > > --- Scope is unspecified > > One of the mechanisms for merging (TNC merging) would then depend on a > feature whose meaning is unspecified. Furthermore, when attempting to > merge topic maps that interpreted scope differently one would be bound > to get suboptimal results. Furthermore, we would have to create TMQL > scope operators for a construct whose interpretation is undefined. > > In short, this does not seem to work very well. > > > [1] Versions of SAM prior to 1.23 had an editorial error in the > definition of scope. > > -- > Lars Marius Garshol, Ontopian > ISO SC34/WG3, OASIS GeoLang TC > > _______________________________________________ > sc34wg3 mailing list > sc34wg3@isotopicmaps.org > http://www.isotopicmaps.org/mailman/listinfo/sc34wg3 > From sc34wg3@isotopicmaps.org Fri Jun 14 08:37:14 2002 From: sc34wg3@isotopicmaps.org (Graham Moore) Date: Fri, 14 Jun 2002 08:37:14 +0100 Subject: [sc34wg3] SAM-issue term-scope-def Message-ID: Hi,=20 Bernard I think I share your position here - I think this is effectively = what I said in my small paper on Is Scope Bogus? i.e. that scope is no = more than a lazy way of stating things about associations and that = really to be useful associations should be further qualified by other = associations. I would like us to try and get some consensus on this idea and put = something into the spec to reflect this. I dont think we need to ditch = scope just make it very clear that its a sloopy way to work. I think we = do this by defining something like the scope assoc example bernard = provided and say 'this is what scope is, but as you can see its not very = expressive'. Users of topics maps will then have all the info about = whats really going on and if they want fairly useless bags of topics = then fine, if not we'll have much better maps. I also think this goes hand in hand with ditching the topic naming = constraint as a MUST do and introducing typed names instead of scoped = names. If I can give a short example about the names, topic t1 has name n1. n1 has scope of (t2, t3) Scope on names is used in 2 ways: 1. to type 2. to qualify the topic i.e.=20 'gra' scoped by {shortname} is a typing action 'granada' scoped by {city} is a topic qualifying action I think that in the first circmstance what you are doing is typing the = name. The second example is just awful - what is really being said here = is that the TOPIC not the name has some relationship with 'city'. I would like to see that when someone queries a map with a topic name = they can get back multple topics. i.e query =3D> get topics by name 'Washington' Washington (located England) Washington (located US) and I would be horrified if all the names of these topics were scoped by = some topic that should really be associated properly with the topic. gra=20 -----Original Message----- From: Bernard Vatant [mailto:bernard.vatant@mondeca.com] Sent: 13 June 2002 07:54 To: sc34wg3@isotopicmaps.org Subject: Re: [sc34wg3] SAM-issue term-scope-def Hello all. Lars Marius asked me on another forum to bite here. Well, I was very = uneasy with that issue until yesterday night, then I got the following idea(s), which = maybe could help. Sorry, it's a bit long. But I tried to be very explicit. Thanks for your = time and attention. I've figured so far scope as a bag where you could put so many different = things that no general rule how to process it could be really set, other than arbitrary = or "less evil", as Lars Marius tried to figure below . But in fact there is a way to = entangle that, if you begin by expliciting the implicit (meta)association expressed by scope. = The role-players of this (meta)association are: 1. The scoped assertion itself (reified) 2. The elements of the scope set (scoping topics) Note that "assertion" in 1 is to be understood in the most generic = sense: any assertion that can be scoped, including regular associations, topic-name and = topic-occurrence associations. If the role of the first member (assertion) is clearly specified = (scoped), the role of the scoping members are not specified, further than "scoping" ... which is a = very poor semantic indeed. That's where the issue comes from. If you specify, like = in any regular association, the role of scoping topics, things become clearer and the = conclusion is easier to draw and quite natural. Let's take an example. "Henry is King of Navarre and King of France from = 1589 to 1610" Express that using the basic assertion "Henry is King", the rest of = information being expressed as scopes. Note BTW that this assertion can be expressed like = a regular association between Henri (person) and a status (King), or the = attachment of a name (Henri) to a topic (King) ... and that it does not matter in fact. In = any case, we have three scoping elements : France, Navarre, and the time span. Clearly, the two former have a "space" role, and the latter a "time" = role in the scoping meta-association. So if you express it explicitly, quite obviously you = have the following members: {Henri is King} (scoped assertion) {France, Navarre} (space scope) {1589-1610} (time scope) Now it figures that scopes playing the same role are first gathered by a = "OR" (union?), and resulting sets (members) are gathered by a "AND" (intersection?) to = get the global scope. More precisely: "Henri is King" is valid if ("space belongs to Navarre" OR "space = belongs to France") AND "time belongs to 1589-1610". It figures another thing. Asserting a scope seems to be in that case = setting implicitly the domain of two variables, "space" and "time". The nature of those = variables are expressed by the role specifications in the meta-association. If we try to draw a general rule for that: If : the scope set is S =3D {Ai, Bi, ..., Xi, ...} where A, B, ..., X are scoping variables and Ai, Bi, ..., Xi values of = those variables. Then : the scoped assertion is valid if AND( A belongs to {Ai} , B belongs to {Bi} ... X belongs to {Xi} ) It seems that this is very generic, the scoping variable-role, besides = time and space, could be language, source, thesaurus, market sector ... whatever. Of = course, this rule can be applied if roles of scoping elements are specified. Maybe the = standard should be extended to include that? From a syntax viewpoint, it would mean = allowing as child of ... Sorry to speak syntax here :)) What about now unconstrained scope and merging? The original source(s) = of merging being added to scopes as reified topic maps in the merged map, as I suggested = in a previous post, seems consistent with that. The original topic map plays role = "source". In the above example, you could add to scope that the assertion (unauthorized) source = is "TM-BV". So, after merging, you would have another member in the scoping = meta-association: {Henri is King} (scoped assertion) {France, Navarre} (space scope) {1589-1610} (time scope) {BV} (source scope) If you have the same assertion confirmed by "Larousse 1972" (just = checked), this will be added to the source member: {Henri is King} (scoped assertion) {France, Navarre} (space scope) {1589-1610} (time scope) {BV, Larousse} (source scope) Well. I think that makes it for my 0.02 Euros. Bernard ------------------------------------------------------------------- Bernard Vatant Consultant - Mondeca www.mondeca.com Chair - OASIS TM PubSubj Technical Committee www.oasis-open.org/committees/tm-pubsubj/ ------------------------------------------------------------------- ----- Message d'origine ----- De : "Lars Marius Garshol" =C0 : Envoy=E9 : dimanche 9 juin 2002 19:45 Objet : [sc34wg3] SAM-issue term-scope-def > > In ISO 13250 the definition of scope says that scope is the union of > the themes. That is, > > [finland =3D "Finland" / norwegian swedish] > > means that the name "Finland" is valid in Norwegian and that it is > also valid in Swedish. > > XTM 1.0, on the other hand says that it is up to the application how > to interpret the scope. > > The current SAM version[1] says scope is the intersection of the > themes, which means that this particular scope would only be valid in > *both* Norwegian *and* Swedish at the same time, which would require > the topic to be written in this way: > > [finland =3D "Finland" / norwegian > =3D "Finland" / swedish] > > On the other hand, that something is my opinion today could according > to the SAM be expressed by scoping it with topics representing me and > today. ISO 13250 explains in a note that to say this would require a > topic representing me today would have to be created and used as the > scope. (No mechanism is provided for doing so in ISO 13250, however.) > > > The question is, which of these three approaches should we choose? I > think we need to consider carefully the consequences for the > unconstrained scope, for merging, and also for querying operations. > > > --- Scope is union > > If we say that scope is union that would mean that the following topic > > [finland =3D "Finland" / norwegian swedish > =3D "Finland" / norwegian > =3D "Finland" / swedish] > > contains two redundancies, and is actually equivalent to > > [finland =3D "Finland" / norwegian swedish] > > which would seem to imply that the rules for equivalence and > redundancy elimination need to be modified. > > Furthermore, if associations with published subjects are necessary to > form compound scope it means that in order to answer the question > "what occurrences of the topic 'term-scope-def' are valid in the scope > 'lmg'" correctly when presented with > > {term-scope-def, opinion, ""} / lmg-today > > the topic map processor would have to traverse associations to > evaluate the scope correctly, and building compound scopes becomes > very cumbersome. > > > --- Scope is intersection > > This means that to assert that something is valid in two different > contexts requires it to be repeated. This seems like the lesser evil. > It also means that the arithmetic of scope works well with the > unconstrained scope being the empty set. (See previous email.) > > > --- Scope is unspecified > > One of the mechanisms for merging (TNC merging) would then depend on a > feature whose meaning is unspecified. Furthermore, when attempting to > merge topic maps that interpreted scope differently one would be bound > to get suboptimal results. Furthermore, we would have to create TMQL > scope operators for a construct whose interpretation is undefined. > > In short, this does not seem to work very well. > > > [1] Versions of SAM prior to 1.23 had an editorial error in the > definition of scope. > > -- > Lars Marius Garshol, Ontopian > ISO SC34/WG3, OASIS GeoLang TC > > _______________________________________________ > sc34wg3 mailing list > sc34wg3@isotopicmaps.org > http://www.isotopicmaps.org/mailman/listinfo/sc34wg3 > _______________________________________________ sc34wg3 mailing list sc34wg3@isotopicmaps.org http://www.isotopicmaps.org/mailman/listinfo/sc34wg3 _____________________________________________________________________ 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. _____________________________________________________________________ This message has been checked for all known viruses by the MessageLabs Virus Scanning Service. From sc34wg3@isotopicmaps.org Fri Jun 14 10:16:46 2002 From: sc34wg3@isotopicmaps.org (Lars Marius Garshol) Date: 14 Jun 2002 11:16:46 +0200 Subject: [sc34wg3] SAM-issue term-scope-def In-Reply-To: References: Message-ID: * Graham Moore | | i.e. that scope is no more than a lazy way of stating things about | associations and that really to be useful associations should be | further qualified by other associations. That would land us where RDF is now, and they have been having lots of debates on how to qualify statements. As far as I am aware they haven't really solved that problem to anyone's satisfaction yet. Scope is simpler, and that's also its strength, I would say. For one way to strengthen scope, see Steve and Geir Ove's paper on scope[1]. | I would like us to try and get some consensus on this idea and put | something into the spec to reflect this. I dont think we need to | ditch scope just make it very clear that its a sloopy way to work. If we agree that it is I think that would be an appropriate way to handle the issue, but I don't actually think this is true. (I'll explain why below.) | I also think this goes hand in hand with ditching the topic naming | constraint as a MUST do and introducing typed names instead of | scoped names. These issues are certainly related. | 'gra' scoped by {shortname} is a typing action Absolutely. This is just a workaround for the problem that names cannot have types. Most name scopes (in practice) are name types. | 'granada' scoped by {city} is a topic qualifying action | | [...] The second example is just awful - what is really being said | here is that the TOPIC not the name has some relationship with | 'city'. Agreed. This a terrible abuse of scope, but unfortunately typical of the examples people have throwing around. | I would like to see that when someone queries a map with a topic | name they can get back multple topics. | | i.e query => get topics by name 'Washington' | | Washington (located England) | Washington (located US) | | and I would be horrified if all the names of these topics were | scoped by some topic that should really be associated properly with | the topic. Amen. However, scope *can* be used appropriately, and when it is it can be very very useful. I've been saying this for a while, so I'll actually step forward and provide some examples for once. [gbk : charenc = "GBK" = "Windows CP 936" / microsoft] This says: most people call this character encoding GBK, but Microsoft calls it "Windows CP 936". A variation on this is to scope names with languages, which is very very useful, as it provides any easy way to make topic map-driven applications support multiple languages. A similar usage is when two classification systems have been merged, and some concepts appear in both, but with different names, and perhaps at different points in the hierarchy. Using scope you can qualify names and associations by what system they came from, and users can choose to see the merged result, only the structure of one, or the structure of both but using the names of one. [karnataka : province = "Karnataka" = "Mysore" / old-name] Here we are saying that this province is today known as Karnataka, but it used to be called Mysore. Obviously, the scope could be restricted to a specific time range, but I didn't see any point in that. instance-of(devanagari : instance, abugida : type) / daniels instance-of(devanagari : instance, alphasyllabary : type) / bright This is saying that according to Bright Devanagari is an alphasyllabary, whereas according to Daniels it is an abugida. This would allow me to let my scripts and languages web site be agnostic as to what authority on scripts it should follow. written-in(vietnamese : language, chinese-s : script) / formerly This is saying that Vietnamese used to be written with Chinese characters, but that it no longer is. So I do think scope can be useful, and although I agree that the scope does not contain any information about what each theme is doing in the scope applications know this. They can figure this out either by recognizing the themes, or by recognizing what they are instances of. For example, we've been thinking of making the Omnigator look at the HTTP Accept-language header (set from user preferences in most browsers) and set the user context filter accordingly. This would mean that most people would see the Genji topic map in English, while the Japanese would see it in Japanese. This would be done through scope filtering and published subjects, and the only missing piece is really 20 lines of code... [1] -- Lars Marius Garshol, Ontopian ISO SC34/WG3, OASIS GeoLang TC From sc34wg3@isotopicmaps.org Fri Jun 14 11:18:14 2002 From: sc34wg3@isotopicmaps.org (Kal Ahmed) Date: Fri, 14 Jun 2002 10:18:14 +0000 Subject: [sc34wg3] SAM-issue term-scope-def In-Reply-To: References: Message-ID: <200206141018.14757.kal@techquila.com> On Friday 14 June 2002 07:37, Graham Moore wrote: > Hi, > > Bernard I think I share your position here - I think this is effectivel= y > what I said in my small paper on Is Scope Bogus? i.e. that scope is no = more > than a lazy way of stating things about associations and that really to= be > useful associations should be further qualified by other associations. > > I would like us to try and get some consensus on this idea and put > something into the spec to reflect this. I dont think we need to ditch > scope just make it very clear that its a sloopy way to work. I think we= do > this by defining something like the scope assoc example bernard provide= d > and say 'this is what scope is, but as you can see its not very > expressive'. Users of topics maps will then have all the info about wha= ts > really going on and if they want fairly useless bags of topics then fin= e, > if not we'll have much better maps. > > I also think this goes hand in hand with ditching the topic naming > constraint as a MUST do and introducing typed names instead of scoped > names. > > If I can give a short example about the names, > > topic t1 has name n1. > n1 has scope of (t2, t3) > > Scope on names is used in 2 ways: > > 1. to type > 2. to qualify the topic > > i.e. > > 'gra' scoped by {shortname} is a typing action > > 'granada' scoped by {city} is a topic qualifying action > I must say that I agree with both Graham and Bernard that the existing "s= cope"=20 construct is not expressive enough for all needs (although it is suitable= for=20 some useful subset of all applications). I'm not sure that I agree with y= our=20 definition of the "use" of scope. My belief is that scope is used on name= s: 1) To turn them into context-dependent identifiers (for the TNC) 2) To restrict their use in an application (scope by language for example= ) I believe that the topics that one would typically use to do that are, as= you=20 say topics that either type or in some other way qualify the named topic.= I=20 also believe that the same holds true for occurrences (even though they h= ave=20 no identity semantics) For associations, on the other hand the usage of scope is much more about= =20 defining a context of validity and I agree with Bernard [1] that there ar= e=20 many facets to such a context and that simply lumping them all together i= n a=20 bag is not helpful. Perhaps the solution to this lies, as Bernard suggest= s,=20 in treating the scope syntax as a shortcut for a much more powerful "scop= ing=20 association". I am thinking of something simliar in nature to the existin= g=20 class-instance association / duality. Cheers, Kal [1] http://isotopicmaps.org/pipermail/sc34wg3/2002-June/000295.html --=20 Kal Ahmed, techquila.com XML and Topic Map Consultancy e: kal@techquila.com p: +44 7968 529531 w: www.techquila.com From sc34wg3@isotopicmaps.org Fri Jun 14 09:37:00 2002 From: sc34wg3@isotopicmaps.org (Bernard Vatant) Date: Fri, 14 Jun 2002 10:37:00 +0200 Subject: [sc34wg3] SAM-issue term-scope-def References: Message-ID: <008a01c21381$c3949a00$6601a8c0@bernard> Graham I'm glad we share positions on that. The way you extend the debate reminds me of the very short exchange we had a month ago on topicmapmail about "source" of associations. What I proposed first at the time, which was very silly indeed, was adding a "source" attribute to associations, but in fact it was going no more no less along the same lines than scope, "source" being just a subtype of "scope". What you and others said rightly at the time is that the proper way to deal with that is to attach "source" to the reified association, either as an occurrence, or by "assertion-source" association. The same argument holds for scope, so we come to the same conclusion indeed ... More comments below: > I think this is effectively what I said in my small paper on Is Scope Bogus? Is that paper available on-line somewhere? > I would like us to try and get some consensus on this idea and put something into the spec to reflect this. I would applaud to that - the only thing I can do, until France come back to sc34 ... still a long way to go :(( > I dont think we need to ditch scope just make it very clear that its a sloopy way to work. > I think we do this by defining something like the scope assoc example bernard provided > and say 'this is what scope is, but as you can see its not very expressive'. > Users of topics maps will then have all the info about whats really going on > and if they want fairly useless bags of topics then fine, if not we'll have much better maps. It figures we would keep scope there just for backward compatibility, but provide and recommend more effective and semantic ways to deal with what scope wants to express, through association reification process. If we provide something robust and effective, I suppose old-fashioned non-specified scope would die out slowly by itself, the same way I don't think many people use association members with no role specification, although they are allowed to do so by the standard. > I also think this goes hand in hand with ditching the topic naming constraint > as a MUST do and introducing typed names instead of scoped names. Agreed. Bernard ------------------------------------------------------------------- Bernard Vatant Consultant - Mondeca www.mondeca.com Chair - OASIS TM PubSubj Technical Committee www.oasis-open.org/committees/tm-pubsubj/ ------------------------------------------------------------------- From sc34wg3@isotopicmaps.org Fri Jun 14 14:02:25 2002 From: sc34wg3@isotopicmaps.org (Bernard Vatant) Date: Fri, 14 Jun 2002 15:02:25 +0200 Subject: [sc34wg3] SAM-issue term-scope-def References: Message-ID: <00f201c213ac$277cfb00$6601a8c0@bernard> > * Graham Moore > | > | i.e. that scope is no more than a lazy way of stating things about > | associations and that really to be useful associations should be > | further qualified by other associations. * Lars Marius > That would land us where RDF is now, and they have been having lots of > debates on how to qualify statements. As far as I am aware they > haven't really solved that problem to anyone's satisfaction yet. Yes, but we have a reification process, right? I don't see why we should follow all RDF wrong tracks :) > Scope is simpler, and that's also its strength, I would say. Simplicity is paid by lack of semantic accuracy. I don't think it's a valuable trade-off, because people use scope in a very lazy and loose way, because people are naturally lazy and loose if not forced otherwise ... as Graham example shows. When newcomers in topic maps land are forced into defining role specifications to explicit non-typed or ill-defined relationships they were dealing with before, they first consider it as a constraint. But after a while, they see the gain of accuracy they get and they don't want non-typed relationships any more. > For one way to strengthen scope, see Steve and Geir Ove's paper on scope[1]. I think "ad hoc" solutions proposed in this paper, as well as in the various examples you give in your answer are not necessary if refinement of scope is treated in the general framework of association reification. It is the scoping association that has to be explicited - by specification of roles of the scoping topics, and not the nature, type or names of scoping topics themselves. > So I do think scope can be useful, and although I agree that the scope > does not contain any information about what each theme is doing in the > scope applications know this. They can figure this out either by > recognizing the themes, or by recognizing what they are instances of. But if this information was carried in a standard way by a role specification in scoping association, the applications would be able to process it in a standard way, not through an ad hoc case-by-case process. Bernard ------------------------------------------------------------------- Bernard Vatant Consultant - Mondeca www.mondeca.com Chair - OASIS TM PubSubj Technical Committee www.oasis-open.org/committees/tm-pubsubj/ ------------------------------------------------------------------- From sc34wg3@isotopicmaps.org Fri Jun 14 15:31:12 2002 From: sc34wg3@isotopicmaps.org (Nikita Ogievetsky) Date: Fri, 14 Jun 2002 07:31:12 -0700 Subject: [sc34wg3] SAM-issue term-scope-def References: <008a01c21381$c3949a00$6601a8c0@bernard> Message-ID: <00f201c213b0$228d4290$1101a8c0@VAIOCOGI> I am with Lars and Kal on this. In around 70's in USSR people got the notion of a new plastic and aluminum millennium and threw away antic and highly valued bountiful things of bronze, cupper, silver and even gold. Nobody could ever understand russian soul but lets not run after plastic. (I hope you know what I mean) It is very useful but not for everything. Bernard, I do not see your problem: "Henry is King of Navarre and King of France from 1589 to 1610" I was proposing structured scopes two years ago (as I think many others did) But that proposal was put on a waiting list. Ands I must admit that I had waited quite successfully. Lets use scopes for what they are good for (like in Lars's examples for example) for everything else there are association members. For distinguishing roles of scope themes there is the topic typing mechanism. (type of topic that plays the role of scope theme). Primitive but works. --Nikita. ----- Original Message ----- From: "Bernard Vatant" To: Sent: Friday, June 14, 2002 1:37 AM Subject: Re: [sc34wg3] SAM-issue term-scope-def > Graham > > I'm glad we share positions on that. The way you extend the debate reminds me of the very > short exchange we had a month ago on topicmapmail about "source" of associations. What I > proposed first at the time, which was very silly indeed, was adding a "source" attribute > to associations, but in fact it was going no more no less along the same lines than scope, > "source" being just a subtype of "scope". > What you and others said rightly at the time is that the proper way to deal with that is > to attach "source" to the reified association, either as an occurrence, or by > "assertion-source" association. The same argument holds for scope, so we come to the same > conclusion indeed ... > > More comments below: > > > I think this is effectively what I said in my small paper on Is Scope Bogus? > > Is that paper available on-line somewhere? > > > I would like us to try and get some consensus on this idea and put something into the > spec to reflect this. > > I would applaud to that - the only thing I can do, until France come back to sc34 ... > still a long way to go :(( > > > I dont think we need to ditch scope just make it very clear that its a sloopy way to > work. > > I think we do this by defining something like the scope assoc example bernard provided > > and say 'this is what scope is, but as you can see its not very expressive'. > > Users of topics maps will then have all the info about whats really going on > > and if they want fairly useless bags of topics then fine, if not we'll have much better > maps. > > It figures we would keep scope there just for backward compatibility, but provide and > recommend more effective and semantic ways to deal with what scope wants to express, > through association reification process. If we provide something robust and effective, I > suppose old-fashioned non-specified scope would die out slowly by itself, the same way I > don't think many people use association members with no role specification, although they > are allowed to do so by the standard. > > > I also think this goes hand in hand with ditching the topic naming constraint > > as a MUST do and introducing typed names instead of scoped names. > > Agreed. > > Bernard > > ------------------------------------------------------------------- > Bernard Vatant > Consultant - Mondeca > www.mondeca.com > Chair - OASIS TM PubSubj Technical Committee > www.oasis-open.org/committees/tm-pubsubj/ > ------------------------------------------------------------------- > > > _______________________________________________ > sc34wg3 mailing list > sc34wg3@isotopicmaps.org > http://www.isotopicmaps.org/mailman/listinfo/sc34wg3 > > From sc34wg3@isotopicmaps.org Fri Jun 14 22:12:34 2002 From: sc34wg3@isotopicmaps.org (Bernard Vatant) Date: Fri, 14 Jun 2002 23:12:34 +0200 Subject: [sc34wg3] SAM-issue term-scope-def References: <008a01c21381$c3949a00$6601a8c0@bernard> <00f201c213b0$228d4290$1101a8c0@VAIOCOGI> Message-ID: <003f01c213e8$6a5b3d60$6601a8c0@bernard> Hello Nikita > I am with Lars and Kal on this. Well ... I thought Kal was with Graham and me. So we are all together? > In around 70's in USSR people got the notion > of a new plastic and aluminum millennium and threw away antic and > highly valued bountiful things of bronze, cupper, silver and even gold. > Nobody could ever understand russian soul but lets not run after plastic. > (I hope you know what I mean) Barely. Has it something to do with "Russian Semiotics" ? ;-) > Bernard, I do not see your problem: I'm sad you don't. It's not a problem in fact, just an example. > "Henry is King of Navarre and King of France from 1589 to 1610" > > > > > > > > > > > > > > > > > > > > > > > > Of course you can express it that way, and many others. I would have done something like that too ... I expressed it with scopes just for the illustration. Maybe I could have found something less far-fetched. > I was proposing structured scopes two years ago (as I think many others did) > But that proposal was put on a waiting list. > Ands I must admit that I had waited quite successfully. What do you mean exactly by that? I don't think structure of scope is the issue. The issue is : what is the nature of the relation between the scoping topic and the scoped association? And IMO this question boils down to specify a role, no more, no less ... > Lets use scopes for what they are good for (like in Lars's examples for > example) > for everything else there are association members. > For distinguishing roles of scope themes there is the topic typing > mechanism. > (type of topic that plays the role of scope theme). > Primitive but works. I don't like it that much. Confusing a type (class) with a role is suboptimal. Again, what has to be specified is the *role* of each scoping topic in its relation with the association. And we have a mechanism to do that very accurately and quite simply through association reification. Why not use it? Bernard From sc34wg3@isotopicmaps.org Sat Jun 15 04:35:49 2002 From: sc34wg3@isotopicmaps.org (Nikita Ogievetsky) Date: Fri, 14 Jun 2002 20:35:49 -0700 Subject: [sc34wg3] SAM-issue term-scope-def References: <008a01c21381$c3949a00$6601a8c0@bernard> <00f201c213b0$228d4290$1101a8c0@VAIOCOGI> <003f01c213e8$6a5b3d60$6601a8c0@bernard> Message-ID: <026b01c2141d$be4ba1f0$1101a8c0@VAIOCOGI> Hello Bernard, > > I am with Lars and Kal on this. > > Well ... I thought Kal was with Graham and me. So we are all together? Of course we are all together, it is just a fluctuation :-) > > In around 70's in USSR people got the notion > > of a new plastic and aluminum millennium and threw away antic and > > highly valued bountiful things of bronze, cupper, silver and even gold. > > Nobody could ever understand russian soul but lets not run after plastic. > > (I hope you know what I mean) > > Barely. Has it something to do with "Russian Semiotics" ? ;-) Not at all :-) I meant that we often tend to underestimate our present values when we run after new shining ideas. > > Bernard, I do not see your problem: > > I'm sad you don't. It's not a problem in fact, just an example. > > > "Henry is King of Navarre and King of France from 1589 to 1610" > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Of course you can express it that way, and many others. I would have done something like > that too ... > I expressed it with scopes just for the illustration. Maybe I could have found something > less far-fetched. Of course, let me help you: "Nikita said that Bernard agreed with Graham that scopes are obsolete." > > I was proposing structured scopes two years ago (as I think many others did) > > But that proposal was put on a waiting list. > > Ands I must admit that I had waited quite successfully. > > What do you mean exactly by that? I mean that as implementer I had to use what I had and found that it was doable. > I don't think structure of scope is the issue. The issue > is : what is the nature of the relation between the scoping topic and the scoped > association? And IMO this question boils down to specify a role, no more, no less ... Agree. This is actually exactly what I am doing in RTM and new QTM proposals See, for example, slides 29 and 31 in http://cogx.com/xtm2rdf/extreme2001 Where each association in RDF representation has a "validIn" property (scope) whose object is a s-node (using TMPM4 terms). S-node in XTM is just a set. While in RTM it can be a richer construct. Some QTM examples are on slides 11 and 24 in http://cogx.com/kt2002 > > Lets use scopes for what they are good for (like in Lars's examples for > > example) > > for everything else there are association members. > > > For distinguishing roles of scope themes there is the topic typing > > mechanism. > > (type of topic that plays the role of scope theme). > > Primitive but works. > > I don't like it that much. Confusing a type (class) with a role is suboptimal. Again, what > has to be specified is the *role* of each scoping topic in its relation with the > association. And we have a mechanism to do that very accurately and quite simply through > association reification. Why not use it? Why not indeed? You mean create an association describing a context and then use its subject to define a scoping theme? I misunderstood that you are suggesting to make the very notion of scope obsolete. I think that separation of contextual axes from characteristics axes is very-very important. --Nikita. From sc34wg3@isotopicmaps.org Fri Jun 14 19:36:03 2002 From: sc34wg3@isotopicmaps.org (Lars Marius Garshol) Date: 14 Jun 2002 20:36:03 +0200 Subject: [sc34wg3] SAM-issue term-scope-def In-Reply-To: <00f201c213b0$228d4290$1101a8c0@VAIOCOGI> References: <008a01c21381$c3949a00$6601a8c0@bernard> <00f201c213b0$228d4290$1101a8c0@VAIOCOGI> Message-ID: * Nikita Ogievetsky | | It is very useful but not for everything. I think this is scope as we have it today in a nutshell, really. I won't comment on the rest, as I agree with all of it. :) -- Lars Marius Garshol, Ontopian ISO SC34/WG3, OASIS GeoLang TC From sc34wg3@isotopicmaps.org Sat Jun 15 16:37:30 2002 From: sc34wg3@isotopicmaps.org (Lars Marius Garshol) Date: 15 Jun 2002 17:37:30 +0200 Subject: [sc34wg3] SAM-issue term-scope-def In-Reply-To: <00f201c213ac$277cfb00$6601a8c0@bernard> References: <00f201c213ac$277cfb00$6601a8c0@bernard> Message-ID: * Lars Marius | | That would land us where RDF is now, and they have been having lots | of debates on how to qualify statements. As far as I am aware they | haven't really solved that problem to anyone's satisfaction yet. * Bernard Vatant | | Yes, but we have a reification process, right? I don't see why we | should follow all RDF wrong tracks :) Well, it's not just reification that is the difference, Bernard. * Lars Marius Garshol | | Scope is simpler, and that's also its strength, I would say. * Bernard Vatant | | Simplicity is paid by lack of semantic accuracy. Certainly. | I don't think it's a valuable trade-off, because people use scope in | a very lazy and loose way, because people are naturally lazy and | loose if not forced otherwise ... as Graham example shows. When | newcomers in topic maps land are forced into defining role | specifications to explicit non-typed or ill-defined relationships | they were dealing with before, they first consider it as a | constraint. But after a while, they see the gain of accuracy they | get and they don't want non-typed relationships any more. Ok. So what I hear is that some people would prefer to get rid of scope altogether. To me that means that we have to reconsider what we are doing. Either we are rearchitecting topic maps completely from top to bottom, or we are merely strengthening the existing standard. Now, the requirements document that we already published[1] says that we will preserve backwards compatibility as far as we can. Discarding the TNC may conceivably fit within that scope (provided we push hard,) but I don't see how discarding scope altogether could do that. So either we have to agree on a completely new direction, or we have to stay with the original plan. Of course, the original plan does not prevent us from first producing a firm and complete standard, and *then* moving on to changing it, though admittedly this may cause trouble for TMCL and TMQL. Quo vadis, SC34? * Lars Marius Garshol | | So I do think scope can be useful, and although I agree that the | scope does not contain any information about what each theme is | doing in the scope applications know this. They can figure this out | either by recognizing the themes, or by recognizing what they are | instances of. * Bernard Vatant | | But if this information was carried in a standard way by a role | specification in scoping association, the applications would be able | to process it in a standard way, not through an ad hoc case-by-case | process. Possibly. I am not sure role types would give you so much more than the types of themes, but that's a discussion I am not very eager to start. What we were discussing was whether scope is the intersection of its themes, the union, or simply unspecified. If someone wants to argue that we should redo everything then I'd be happy to discuss that as well, but it belongs in a different thread, and we should be aware what it is we are doing. [1] , see "Relationship to other standards", point 2. -- Lars Marius Garshol, Ontopian ISO SC34/WG3, OASIS GeoLang TC From sc34wg3@isotopicmaps.org Sat Jun 15 17:06:43 2002 From: sc34wg3@isotopicmaps.org (Lars Marius Garshol) Date: 15 Jun 2002 18:06:43 +0200 Subject: [sc34wg3] SAM-issue term-scope-def In-Reply-To: <008a01c21381$c3949a00$6601a8c0@bernard> References: <008a01c21381$c3949a00$6601a8c0@bernard> Message-ID: * Bernard Vatant | | | Graham, I'm glad we share positions on that. The way you extend the | debate reminds me of the very short exchange we had a month ago on | topicmapmail about "source" of associations. What I proposed first | at the time, which was very silly indeed, was adding a "source" | attribute to associations, but in fact it was going no more no less | along the same lines than scope, "source" being just a subtype of | "scope". What you and others said rightly at the time is that the | proper way to deal with that is to attach "source" to the reified | association, either as an occurrence, or by "assertion-source" | association. The same argument holds for scope, so we come to the | same conclusion indeed ... I agree. These things are related, and in fact the RDF people are lumping these two things together under the term "provenance". (I don't know if that term is universally accepted in the RDF community.) * Graham Moore | | I would like us to try and get some consensus on this idea and put | something into the spec to reflect this. * Bernard Vatant | | I would applaud to that - So the idea proposed is that we add a note that scope is underpowered in the specification we are producing now, but otherwise leave it as-is? Presumably this is being done so that we can later come back with something more powerful? | the only thing I can do, until France come back to sc34 ... still a | long way to go :(( Bernard, that's not true. Any OASIS or ISUG member can attend SC34 meetings, since both organizations have full liaison status with SC34. In fact, this is how Steve Newcomb attends meetings. The fact that this doesn't give you a vote is immaterial, since nearly all decisions are in any case taken by developing consensus through debate. In other words, nothing is formally holding you back... | It figures we would keep scope there just for backward | compatibility, but provide and recommend more effective and semantic | ways to deal with what scope wants to express, through association | reification process. If we provide something robust and effective, I | suppose old-fashioned non-specified scope would die out slowly by | itself, the same way I don't think many people use association | members with no role specification, although they are allowed to do | so by the standard. I am not necessarily opposed to this, but I think we should be careful to take things one step at a time. It seems to me that it should be possible to come up with a more powerful scope construct later that can support all the things we are currently doing with scope. If that is the case I think we should move forward now with what we have, and those who are interested can develop scope++ proposals in paralell. -- Lars Marius Garshol, Ontopian ISO SC34/WG3, OASIS GeoLang TC From sc34wg3@isotopicmaps.org Sun Jun 16 10:22:59 2002 From: sc34wg3@isotopicmaps.org (Lars Marius Garshol) Date: 16 Jun 2002 11:22:59 +0200 Subject: [sc34wg3] Topic map standards guide Message-ID: If anyone wants to comment on it they will have to do so over the next few days. I expect to make another pass over it in 2-3 days, and then send it in. -- Lars Marius Garshol, Ontopian ISO SC34/WG3, OASIS GeoLang TC From sc34wg3@isotopicmaps.org Mon Jun 17 06:47:17 2002 From: sc34wg3@isotopicmaps.org (Martin Bryan) Date: Mon, 17 Jun 2002 06:47:17 +0100 Subject: [sc34wg3] SAM-issue term-scope-def References: Message-ID: <049b01c215c5$25c540e0$cdc466c3@yourudvgq1w43i> Lars Marius > In ISO 13250 the definition of scope says that scope is the union of > the themes. That is, > > [finland = "Finland" / norwegian swedish] > > means that the name "Finland" is valid in Norwegian and that it is > also valid in Swedish. A change from the 13250 definition of "a given scope is the union of the sujects of the set of themes used to specify the scope" to one where the intersection is used would be a mistake. The use of "all of the topics in a topic map" as the definition of a unconstrained scope was a clear recognition of the fact that any of the currently defined topics could, at some stage, be used to scope any other topic. What I would suggest is that we should have said that unconstrained scope was the union of all topics currently used as scopes. Yet no one seems to have listed this as a possible alternative definition. Martin Bryan From sc34wg3@isotopicmaps.org Mon Jun 17 09:39:39 2002 From: sc34wg3@isotopicmaps.org (Bernard Vatant) Date: Mon, 17 Jun 2002 10:39:39 +0200 Subject: [sc34wg3] SAM-issue term-scope-def References: <008a01c21381$c3949a00$6601a8c0@bernard> Message-ID: <003501c215da$aec9a6a0$6601a8c0@bernard> > * Graham Moore > | > | I would like us to try and get some consensus on this idea and put > | something into the spec to reflect this. > > * Bernard Vatant > | > | I would applaud to that - > > * Lars Marius Garshol > > So the idea proposed is that we add a note that scope is underpowered > in the specification we are producing now, but otherwise leave it > as-is? Presumably this is being done so that we can later come back > with something more powerful? That seems reasonable (see other message) > * Bernard Vatant > | the only thing I can do, until France come back to sc34 ... still a > | long way to go :(( > > Bernard, that's not true. Any OASIS or ISUG member can attend SC34 > meetings, since both organizations have full liaison status with SC34. > In fact, this is how Steve Newcomb attends meetings. The fact that > this doesn't give you a vote is immaterial, since nearly all decisions > are in any case taken by developing consensus through debate. > > In other words, nothing is formally holding you back... I know all that. My point is that it's always frustrating to engage in a process where you have no formal power :o) My remark was also about the process that is starting now with AFNOR in France, which will be desperately slow I'm afraid. > | It figures we would keep scope there just for backward > | compatibility, but provide and recommend more effective and semantic > | ways to deal with what scope wants to express, through association > | reification process. If we provide something robust and effective, I > | suppose old-fashioned non-specified scope would die out slowly by > | itself, the same way I don't think many people use association > | members with no role specification, although they are allowed to do > | so by the standard. > > I am not necessarily opposed to this, but I think we should be careful > to take things one step at a time. It seems to me that it should be > possible to come up with a more powerful scope construct later that > can support all the things we are currently doing with scope. If that > is the case I think we should move forward now with what we have, and > those who are interested can develop scope++ proposals in paralell. Agreed. Bernard ------------------------------------------------------------------- Bernard Vatant Consultant - Mondeca www.mondeca.com Chair - OASIS TM PubSubj Technical Committee www.oasis-open.org/committees/tm-pubsubj/ ------------------------------------------------------------------- From sc34wg3@isotopicmaps.org Mon Jun 17 09:33:13 2002 From: sc34wg3@isotopicmaps.org (Bernard Vatant) Date: Mon, 17 Jun 2002 10:33:13 +0200 Subject: [sc34wg3] SAM-issue term-scope-def References: <00f201c213ac$277cfb00$6601a8c0@bernard> Message-ID: <003401c215da$adc4b9c0$6601a8c0@bernard> *Lars Marius Garshol > Ok. So what I hear is that some people would prefer to get rid of > scope altogether. To me that means that we have to reconsider what we > are doing. Either we are rearchitecting topic maps completely from top > to bottom, or we are merely strengthening the existing standard. I don't know if you count me among those "some people", but if yes, I think there is a misunderstanding. Scope, is a very useful and important feature, simply we should make it more powerful by giving means to specify its semantics, in a backward compatible way. That's not discarding it. The comparison Kal made with is good. Scope as is it now could be understood as a convenient shortcut for something that could be expressed in more specific ways. That does not mean complete standard rearchitecting, simply adding semantics to one feature. > Now, the requirements document that we already published[1] says that > we will preserve backwards compatibility as far as we can. Discarding > the TNC may conceivably fit within that scope (provided we push hard,) > but I don't see how discarding scope altogether could do that. Agreed. Discarding scope completely is something I did not think about. I simply said that if we provide ways to provide more semantics to scope, consistent with a general way to deal with reification, it might be that scope use dies out by itself in the long run. But only users will tell. > * Lars Marius Garshol > | > | So I do think scope can be useful, and although I agree that the > | scope does not contain any information about what each theme is > | doing in the scope applications know this. They can figure this out > | either by recognizing the themes, or by recognizing what they are > | instances of. > > * Bernard Vatant > | > | But if this information was carried in a standard way by a role > | specification in scoping association, the applications would be able > | to process it in a standard way, not through an ad hoc case-by-case > | process. > > Possibly. I am not sure role types would give you so much more than > the types of themes, but that's a discussion I am not very eager to > start. Well. I think I should start another thread on that difference between scope type and scope role. If we go towards refining the notion of scope, it's very important IMO. > What we were discussing was whether scope is the intersection of its > themes, the union, or simply unspecified. As I tried to explain in my first post on that, the issue is certainly undecidable in the present state of scope, because any decision has to rely on the semantics of the scoping association. So, default of semantics, the answer is "unspecified". I've suggested a way to decide it when roles in the scoping association are specified (union for the same role, intersection otherwise) The roadmap it seems could be: 1. Precise that scope, as it were, is a simple but poor-semantics process of specifying context of validity, but that it's up to applications to decide how they deal with it, because the very lack of semantics does not allow to set general rules for merging. 2. Propose an extended and backward-compatible way to refine the scope semantics, e.g. by expliciting the scoping association, and the roles of each scoping topic. It could seem reasonable to finish with 1. and cast it in the standard, and proceed to further reflection on 2. Bernard ------------------------------------------------------------------- Bernard Vatant Consultant - Mondeca www.mondeca.com Chair - OASIS TM PubSubj Technical Committee www.oasis-open.org/committees/tm-pubsubj/ ------------------------------------------------------------------- From sc34wg3@isotopicmaps.org Fri Jun 21 12:57:20 2002 From: sc34wg3@isotopicmaps.org (Steve Pepper) Date: Fri, 21 Jun 2002 13:57:20 +0200 Subject: [sc34wg3] Montreal meeting of WG3 Message-ID: <5.1.0.14.2.20020621135025.02d0eae0@mail.ontopia.net> To all WG3 members: Urgent In Barcelona we agreed to have a WG3 meeting in Montreal in conjunction with Extreme Markup. This meeting needs to be organized immediately, so I would like your feedback at once. We provisionally agreed to meet Saturday and Sunday, August 3-4. Looking at the program, I see that Monday August 5 would be possible for most regular WG3 attendees. Our major task is to progress the SAM and RM, so it is essential that those responsible for these two items are able to attend. In addition we would like to have as many other people as possible. Please help me by answering the following questions immediately: (1) Which dates can you attend? (3rd, 4th and/or 5th of August)? (2) Do you prefer a 2-day or 3-day meeting? Thanks. Steve Pepper Convenor, WG3 From sc34wg3@isotopicmaps.org Fri Jun 21 12:45:57 2002 From: sc34wg3@isotopicmaps.org (Patrick Durusau) Date: Fri, 21 Jun 2002 07:45:57 -0400 Subject: [sc34wg3] Montreal meeting of WG3 References: <5.1.0.14.2.20020621135025.02d0eae0@mail.ontopia.net> Message-ID: <3D1311F5.6080006@emory.edu> Steve, Steve Pepper wrote: > > Please help me by answering the following questions immediately: > > (1) Which dates can you attend? (3rd, 4th and/or 5th of August)? > (2) Do you prefer a 2-day or 3-day meeting? 1. I can attend all three days. 2. Prefer 2-day but if progress is being made, would support 3-day. Patrick -- Patrick Durusau Director of Research and Development Society of Biblical Literature pdurusau@emory.edu From sc34wg3@isotopicmaps.org Fri Jun 21 13:03:05 2002 From: sc34wg3@isotopicmaps.org (Lars Marius Garshol) Date: 21 Jun 2002 14:03:05 +0200 Subject: [sc34wg3] Montreal meeting of WG3 In-Reply-To: <5.1.0.14.2.20020621135025.02d0eae0@mail.ontopia.net> References: <5.1.0.14.2.20020621135025.02d0eae0@mail.ontopia.net> Message-ID: * Steve Pepper | | (1) Which dates can you attend? (3rd, 4th and/or 5th of August)? 2nd, 3rd, and 4th. I have already scheduled other meetings for the 5th. | (2) Do you prefer a 2-day or 3-day meeting? 3-day. There is a lot to discuss. -- Lars Marius Garshol, Ontopian ISO SC34/WG3, OASIS GeoLang TC From sc34wg3@isotopicmaps.org Fri Jun 21 13:22:00 2002 From: sc34wg3@isotopicmaps.org (Bernard Vatant) Date: Fri, 21 Jun 2002 14:22:00 +0200 Subject: [sc34wg3] Montreal meeting of WG3 References: <5.1.0.14.2.20020621135025.02d0eae0@mail.ontopia.net> Message-ID: <00a201c2191e$3f3757a0$6601a8c0@bernard> > (1) Which dates can you attend? (3rd, 4th and/or 5th of August)? I'll arrive on 3rd at night and have a full-day tutorial on 4th I'd be happy to attend at least one day, which could be only the 5th Bernard From sc34wg3@isotopicmaps.org Fri Jun 21 13:48:44 2002 From: sc34wg3@isotopicmaps.org (Mason, James David (MXM) ) Date: Fri, 21 Jun 2002 08:48:44 -0400 Subject: [sc34wg3] Montreal meeting of WG3 Message-ID: <28D46344A4EFD411AAAB00508BDF65EC089EDEAD@exchange10.ctd.ornl.gov> I can be available for whatever, though I may not be available on Sunday. Jim Mason > -----Original Message----- > From: Steve Pepper [SMTP:pepper@ontopia.net] > Sent: Friday, June 21, 2002 7:57 AM > To: sc34wg3@isotopicmaps.org > Subject: [sc34wg3] Montreal meeting of WG3 > > To all WG3 members: Urgent > > In Barcelona we agreed to have a WG3 meeting in Montreal in conjunction > with Extreme Markup. This meeting needs to be organized immediately, so I > would like your feedback at once. > > We provisionally agreed to meet Saturday and Sunday, August 3-4. Looking > at > the program, I see that Monday August 5 would be possible for most regular > > WG3 attendees. > > Our major task is to progress the SAM and RM, so it is essential that > those > responsible for these two items are able to attend. In addition we would > like to have as many other people as possible. > > Please help me by answering the following questions immediately: > > (1) Which dates can you attend? (3rd, 4th and/or 5th of August)? > (2) Do you prefer a 2-day or 3-day meeting? > > Thanks. > > Steve Pepper > Convenor, WG3 > > _______________________________________________ > sc34wg3 mailing list > sc34wg3@isotopicmaps.org > http://www.isotopicmaps.org/mailman/listinfo/sc34wg3 From sc34wg3@isotopicmaps.org Fri Jun 21 14:36:03 2002 From: sc34wg3@isotopicmaps.org (Michel Biezunski) Date: Fri, 21 Jun 2002 08:36:03 -0500 Subject: [sc34wg3] Montreal meeting of WG3 In-Reply-To: <28D46344A4EFD411AAAB00508BDF65EC089EDEAD@exchange10.ctd.ornl.gov> Message-ID: I will be available. I find there is a lot we can accomplish in 2 days if the meeting is well prepared and organized. Michel =================================== Michel Biezunski Coolheads Consulting 1527 Northaven Drive Allen, TX 75002-1648 Email:mb@coolheads.com Web :http://www.coolheads.com Voice: (469) 675-1000 Fax : (972) 359-0270 =================================== > -----Original Message----- > From: sc34wg3-admin@isotopicmaps.org > [mailto:sc34wg3-admin@isotopicmaps.org]On Behalf Of Mason, James David > (MXM) > Sent: Friday, June 21, 2002 7:49 AM > To: 'sc34wg3@isotopicmaps.org' > Subject: RE: [sc34wg3] Montreal meeting of WG3 > > > I can be available for whatever, though I may not be available on Sunday. > > Jim Mason > > > -----Original Message----- > > From: Steve Pepper [SMTP:pepper@ontopia.net] > > Sent: Friday, June 21, 2002 7:57 AM > > To: sc34wg3@isotopicmaps.org > > Subject: [sc34wg3] Montreal meeting of WG3 > > > > To all WG3 members: Urgent > > > > In Barcelona we agreed to have a WG3 meeting in Montreal in conjunction > > with Extreme Markup. This meeting needs to be organized > immediately, so I > > would like your feedback at once. > > > > We provisionally agreed to meet Saturday and Sunday, August 3-4. Looking > > at > > the program, I see that Monday August 5 would be possible for > most regular > > > > WG3 attendees. > > > > Our major task is to progress the SAM and RM, so it is essential that > > those > > responsible for these two items are able to attend. In addition > we would > > like to have as many other people as possible. > > > > Please help me by answering the following questions immediately: > > > > (1) Which dates can you attend? (3rd, 4th and/or 5th of August)? > > (2) Do you prefer a 2-day or 3-day meeting? > > > > Thanks. > > > > Steve Pepper > > Convenor, WG3 > > > > _______________________________________________ > > sc34wg3 mailing list > > sc34wg3@isotopicmaps.org > > http://www.isotopicmaps.org/mailman/listinfo/sc34wg3 > _______________________________________________ > sc34wg3 mailing list > sc34wg3@isotopicmaps.org > http://www.isotopicmaps.org/mailman/listinfo/sc34wg3 > From sc34wg3@isotopicmaps.org Sat Jun 22 06:52:15 2002 From: sc34wg3@isotopicmaps.org (Mary Nishikawa) Date: Sat, 22 Jun 2002 14:52:15 +0900 Subject: [sc34wg3] Montreal meeting of WG3 In-Reply-To: <5.1.0.14.2.20020621135025.02d0eae0@mail.ontopia.net> Message-ID: <4.3.2-J.20020622115326.00bcae80@mail.fuchinobe.oilfield.slb.com> > > >(1) Which dates can you attend? (3rd, 4th and/or 5th of August)? >(2) Do you prefer a 2-day or 3-day meeting? (1) I will arrive in Montreal around 10:30 AM on the 3rd, and can get to the meeting sometime before lunch, and the 4th and 5th are also OK. (2) I think that we need as many days as possible, so three is fine with me. It will also give everyone with various commitments to have at least one full day of attendance. -- Mary From sc34wg3@isotopicmaps.org Mon Jun 24 22:16:36 2002 From: sc34wg3@isotopicmaps.org (Lars Marius Garshol) Date: 24 Jun 2002 23:16:36 +0200 Subject: [sc34wg3] SAM-issue term-scope-def In-Reply-To: <049b01c215c5$25c540e0$cdc466c3@yourudvgq1w43i> References: <049b01c215c5$25c540e0$cdc466c3@yourudvgq1w43i> Message-ID: * Martin Bryan | | A change from the 13250 definition of "a given scope is the union of | the sujects of the set of themes used to specify the scope" to one | where the intersection is used would be a mistake. That is just an assertion, though. Could you say *why* you think it would be a mistake? | The use of "all of the topics in a topic map" as the definition of a | unconstrained scope was a clear recognition of the fact that any of | the currently defined topics could, at some stage, be used to scope | any other topic. That makes sense, but as Marc explained very clearly at the beginning of the previous thread, this solution has serious problems. | What I would suggest is that we should have said that unconstrained | scope was the union of all topics currently used as scopes. Yet no | one seems to have listed this as a possible alternative definition. We could do that, but it would mean that a) the unconstrained scope changes every time a new theme is added to a scope, and b) it would be subject to exactly the same problem that Marc described. So I don't think that is a viable solution. -- Lars Marius Garshol, Ontopian ISO SC34/WG3, OASIS GeoLang TC From sc34wg3@isotopicmaps.org Mon Jun 24 22:19:50 2002 From: sc34wg3@isotopicmaps.org (Lars Marius Garshol) Date: 24 Jun 2002 23:19:50 +0200 Subject: [sc34wg3] SAM-issue term-scope-def In-Reply-To: <003501c215da$aec9a6a0$6601a8c0@bernard> References: <008a01c21381$c3949a00$6601a8c0@bernard> <003501c215da$aec9a6a0$6601a8c0@bernard> Message-ID: * Lars Marius Garshol |=20 | So the idea proposed is that we add a note that scope is | underpowered in the specification we are producing now, but | otherwise leave it as-is? Presumably this is being done so that we | can later come back with something more powerful? * Bernard Vatant |=20 | That seems reasonable (see other message) In that case I think we should shelve this idea for now, but put it on the agenda for Montr=E9al. I think this is better discussed F2F than in email.=20 =20 * Lars Marius Garshol | | [...] The fact that this doesn't give you a vote is immaterial, | since nearly all decisions are in any case taken by developing | consensus through debate. * Bernard Vatant | | I know all that. My point is that it's always frustrating to engage | in a process where you have no formal power :o)=20 I figured. What I was trying to say was that you were unlikely to have much use for that formal power. | My remark was also about the process that is starting now with AFNOR | in France, which will be desperately slow I'm afraid. Well, I hope it succeeds. I would rather see Bernard-with-vote than Bernard-without-vote.=20 --=20 Lars Marius Garshol, Ontopian ISO SC34/WG3, OASIS GeoLang TC From sc34wg3@isotopicmaps.org Mon Jun 24 22:29:18 2002 From: sc34wg3@isotopicmaps.org (Lars Marius Garshol) Date: 24 Jun 2002 23:29:18 +0200 Subject: [sc34wg3] SAM-issue term-scope-def In-Reply-To: <003401c215da$adc4b9c0$6601a8c0@bernard> References: <00f201c213ac$277cfb00$6601a8c0@bernard> <003401c215da$adc4b9c0$6601a8c0@bernard> Message-ID: * Bernard Vatant | | The comparison Kal made with is good. Scope as is it | now could be understood as a convenient shortcut for something that | could be expressed in more specific ways. I agree, and I have been thinking the same for a while. It seems to me that what we most of all need is more experience with it. | Well. I think I should start another thread on that difference | between scope type and scope role. If we go towards refining the | notion of scope, it's very important IMO. Sounds good to me. Note that this issue already exists in the SAM, since it was raised by Ann earlier. * Lars Marius Garshol | | What we were discussing was whether scope is the intersection of its | themes, the union, or simply unspecified. * Bernard Vatant | | As I tried to explain in my first post on that, the issue is | certainly undecidable in the present state of scope, because any | decision has to rely on the semantics of the scoping association. | So, default of semantics, the answer is "unspecified". I've | suggested a way to decide it when roles in the scoping association | are specified (union for the same role, intersection otherwise) That is a reasonable point of view, I think. It would be useful to know what others think, however. Two people who don't really agree is hardly a consensus. :) | The roadmap it seems could be: | | 1. Precise that scope, as it were, is a simple but poor-semantics | process of specifying context of validity, but that it's up to | applications to decide how they deal with it, because the very lack | of semantics does not allow to set general rules for merging. I don't think that is enough, unfortunately. We must have specific merging rules (XTM 1.0 had something like it, so SAM should be able to as well), and I think we need to resolve this so that TMQL and TMCL can have scope operators that work as we expect them to. | 2. Propose an extended and backward-compatible way to refine the | scope semantics, e.g. by expliciting the scoping association, and | the roles of each scoping topic. | | It could seem reasonable to finish with 1. and cast it in the | standard, and proceed to further reflection on 2. For a different value of 1., yes. -- Lars Marius Garshol, Ontopian ISO SC34/WG3, OASIS GeoLang TC From sc34wg3@isotopicmaps.org Mon Jun 24 22:31:54 2002 From: sc34wg3@isotopicmaps.org (Lars Marius Garshol) Date: 24 Jun 2002 23:31:54 +0200 Subject: [sc34wg3] SAM-issue term-scope-def In-Reply-To: <001301c212a7$606ba160$6601a8c0@bernard> References: Message-ID: So, we have agreed that there is a group of people who would like to see scope strengthened, that someone will work on a proposal for how to do this, and that we will discuss this in Montr=E9al. Meanwhile, we need to decide what to do in the short term. I am leaning towards specifying that scope is an intersection. Bernard would like to see it left undefined. I would like to hear other opinions on this. If I don't get any I will do intersection for now, and we can discuss this in Montr=E9al. --=20 Lars Marius Garshol, Ontopian ISO SC34/WG3, OASIS GeoLang TC From sc34wg3@isotopicmaps.org Tue Jun 25 08:18:15 2002 From: sc34wg3@isotopicmaps.org (H. Holger Rath) Date: Tue, 25 Jun 2002 09:18:15 +0200 Subject: [sc34wg3] Montreal meeting of WG3 References: <5.1.0.14.2.20020621135025.02d0eae0@mail.ontopia.net> Message-ID: <20020625072018.6C65C14C7FA@amati.petesbox.net> Hi, I'll be available all three days and I would like to see as much done as possible => let's meet three days and have a tough agenda. --Holger Steve Pepper wrote: > > To all WG3 members: Urgent > > In Barcelona we agreed to have a WG3 meeting in Montreal in conjunction > with Extreme Markup. This meeting needs to be organized immediately, so I > would like your feedback at once. > > We provisionally agreed to meet Saturday and Sunday, August 3-4. Looking at > the program, I see that Monday August 5 would be possible for most regular > WG3 attendees. > > Our major task is to progress the SAM and RM, so it is essential that those > responsible for these two items are able to attend. In addition we would > like to have as many other people as possible. > > Please help me by answering the following questions immediately: > > (1) Which dates can you attend? (3rd, 4th and/or 5th of August)? > (2) Do you prefer a 2-day or 3-day meeting? > > Thanks. > > Steve Pepper > Convenor, WG3 > > _______________________________________________ > sc34wg3 mailing list > sc34wg3@isotopicmaps.org > http://www.isotopicmaps.org/mailman/listinfo/sc34wg3 -- Dr. H. Holger Rath - Director Research & Development - empolis * GmbH Bertelsmann MOHN Media Group Technologiepark Pav. 17 97222 Rimpar, Germany phone : +49-172-66-90-427 fax : +49-9365-8062-250 http://www.empolis.com From sc34wg3@isotopicmaps.org Tue Jun 25 08:24:09 2002 From: sc34wg3@isotopicmaps.org (Graham Moore) Date: Tue, 25 Jun 2002 08:24:09 +0100 Subject: [sc34wg3] Montreal meeting of WG3 Message-ID: SSdtIHRoZSBzYW1lIGFzIGhvbGdlci4NCiANCmdyYQ0KDQoJLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0gDQoJRnJvbTogSCBIb2xnZXIuIFJhdGggDQoJU2VudDogVHVlIDI1LzA2LzIwMDIgMDg6 MTggDQoJVG86IHNjMzR3ZzNAaXNvdG9waWNtYXBzLm9yZyANCglDYzogDQoJU3ViamVjdDogUmU6 IFtzYzM0d2czXSBNb250cmVhbCBtZWV0aW5nIG9mIFdHMw0KCQ0KCQ0KDQoJSGksDQoJDQoJSSds bCBiZSBhdmFpbGFibGUgYWxsIHRocmVlIGRheXMgYW5kIEkgd291bGQgbGlrZSB0byBzZWUgYXMg bXVjaA0KCWRvbmUgYXMgcG9zc2libGUgPT4gbGV0J3MgbWVldCB0aHJlZSBkYXlzIGFuZCBoYXZl IGEgdG91Z2ggYWdlbmRhLg0KCQ0KCS0tSG9sZ2VyDQoJDQoJDQoJU3RldmUgUGVwcGVyIHdyb3Rl Og0KCT4NCgk+IFRvIGFsbCBXRzMgbWVtYmVyczogVXJnZW50DQoJPg0KCT4gSW4gQmFyY2Vsb25h IHdlIGFncmVlZCB0byBoYXZlIGEgV0czIG1lZXRpbmcgaW4gTW9udHJlYWwgaW4gY29uanVuY3Rp b24NCgk+IHdpdGggRXh0cmVtZSBNYXJrdXAuIFRoaXMgbWVldGluZyBuZWVkcyB0byBiZSBvcmdh bml6ZWQgaW1tZWRpYXRlbHksIHNvIEkNCgk+IHdvdWxkIGxpa2UgeW91ciBmZWVkYmFjayBhdCBv bmNlLg0KCT4NCgk+IFdlIHByb3Zpc2lvbmFsbHkgYWdyZWVkIHRvIG1lZXQgU2F0dXJkYXkgYW5k IFN1bmRheSwgQXVndXN0IDMtNC4gTG9va2luZyBhdA0KCT4gdGhlIHByb2dyYW0sIEkgc2VlIHRo YXQgTW9uZGF5IEF1Z3VzdCA1IHdvdWxkIGJlIHBvc3NpYmxlIGZvciBtb3N0IHJlZ3VsYXINCgk+ IFdHMyBhdHRlbmRlZXMuDQoJPg0KCT4gT3VyIG1ham9yIHRhc2sgaXMgdG8gcHJvZ3Jlc3MgdGhl IFNBTSBhbmQgUk0sIHNvIGl0IGlzIGVzc2VudGlhbCB0aGF0IHRob3NlDQoJPiByZXNwb25zaWJs ZSBmb3IgdGhlc2UgdHdvIGl0ZW1zIGFyZSBhYmxlIHRvIGF0dGVuZC4gSW4gYWRkaXRpb24gd2Ug d291bGQNCgk+IGxpa2UgdG8gaGF2ZSBhcyBtYW55IG90aGVyIHBlb3BsZSBhcyBwb3NzaWJsZS4N Cgk+DQoJPiBQbGVhc2UgaGVscCBtZSBieSBhbnN3ZXJpbmcgdGhlIGZvbGxvd2luZyBxdWVzdGlv bnMgaW1tZWRpYXRlbHk6DQoJPg0KCT4gKDEpIFdoaWNoIGRhdGVzIGNhbiB5b3UgYXR0ZW5kPyAo M3JkLCA0dGggYW5kL29yIDV0aCBvZiBBdWd1c3QpPw0KCT4gKDIpIERvIHlvdSBwcmVmZXIgYSAy LWRheSBvciAzLWRheSBtZWV0aW5nPw0KCT4NCgk+IFRoYW5rcy4NCgk+DQoJPiBTdGV2ZSBQZXBw ZXINCgk+IENvbnZlbm9yLCBXRzMNCgk+DQoJPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KCT4gc2MzNHdnMyBtYWlsaW5nIGxpc3QNCgk+IHNjMzR3ZzNA aXNvdG9waWNtYXBzLm9yZw0KCT4gaHR0cDovL3d3dy5pc290b3BpY21hcHMub3JnL21haWxtYW4v bGlzdGluZm8vc2MzNHdnMw0KCQ0KCS0tDQoJRHIuIEguIEhvbGdlciBSYXRoDQoJLSBEaXJlY3Rv ciBSZXNlYXJjaCAmIERldmVsb3BtZW50IC0NCgkNCgllbXBvbGlzICogR21iSA0KCUJlcnRlbHNt YW5uIE1PSE4gTWVkaWEgR3JvdXANCglUZWNobm9sb2dpZXBhcmsgUGF2LiAxNw0KCTk3MjIyIFJp bXBhciwgR2VybWFueQ0KCQ0KCXBob25lIDogICs0OS0xNzItNjYtOTAtNDI3DQoJZmF4ICAgOiAg KzQ5LTkzNjUtODA2Mi0yNTANCgkNCgk8bWFpbHRvOmhvbGdlci5yYXRoQGVtcG9saXMuY29tPg0K CWh0dHA6Ly93d3cuZW1wb2xpcy5jb20NCglfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KCXNjMzR3ZzMgbWFpbGluZyBsaXN0DQoJc2MzNHdnM0Bpc290b3Bp Y21hcHMub3JnDQoJaHR0cDovL3d3dy5pc290b3BpY21hcHMub3JnL21haWxtYW4vbGlzdGluZm8v c2MzNHdnMw0KCQ0KCV9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KCVRoaXMgbWVzc2FnZSBoYXMgYmVlbiBjaGVja2Vk IGZvciBhbGwga25vd24gdmlydXNlcyBieSBTdGFyIEludGVybmV0DQoJZGVsaXZlcmVkIHRocm91 Z2ggdGhlIE1lc3NhZ2VMYWJzIFZpcnVzIFNjYW5uaW5nIFNlcnZpY2UuIEZvciBmdXJ0aGVyDQoJ aW5mb3JtYXRpb24gdmlzaXQgaHR0cDovL3d3dy5zdGFyLm5ldC51ay9zdGF0cy5hc3Agb3IgYWx0 ZXJuYXRpdmVseSBjYWxsDQoJU3RhciBJbnRlcm5ldCBmb3IgZGV0YWlscyBvbiB0aGUgVmlydXMg U2Nhbm5pbmcgU2VydmljZS4NCgkNCg0K From sc34wg3@isotopicmaps.org Tue Jun 25 09:53:46 2002 From: sc34wg3@isotopicmaps.org (Lars Marius Garshol) Date: 25 Jun 2002 10:53:46 +0200 Subject: [sc34wg3] Topic map standards guide Message-ID: A draft of the guide is now up at Comments are still welcome, as I don't expect it to be perfect yet. Also, SRN and MB, you are invited to provide me with feedback/input on the Reference Model section. I'm not at all convinced that I've described it correctly, so assistance would be welcome. -- Lars Marius Garshol, Ontopian ISO SC34/WG3, OASIS GeoLang TC From sc34wg3@isotopicmaps.org Tue Jun 25 09:00:37 2002 From: sc34wg3@isotopicmaps.org (Martin Bryan) Date: Tue, 25 Jun 2002 09:00:37 +0100 Subject: [sc34wg3] SAM-issue term-scope-def References: <049b01c215c5$25c540e0$cdc466c3@yourudvgq1w43i> Message-ID: <039901c21c28$1969d130$29c466c3@yourudvgq1w43i> Lars Marius > | A change from the 13250 definition of "a given scope is the union of > | the subjects of the set of themes used to specify the scope" to one > | where the intersection is used would be a mistake. > > That is just an assertion, though. Could you say *why* you think it > would be a mistake? I gave the reason in the following paragraph, but to reinforce it I would state that to have XTM use intersection while ISO13250 clearly states union suggests that the two standards are in competion. I thought the idea was to try to align them without changing the basic concepts. > | The use of "all of the topics in a topic map" as the definition of a > | unconstrained scope was a clear recognition of the fact that any of > | the currently defined topics could, at some stage, be used to scope > | any other topic. > That makes sense, but as Marc explained very clearly at the beginning > of the previous thread, this solution has serious problems. Marc's preferred option in his 7th June message is "the set of all topics", which I agree with as it matches the wording in ISO 13250. I have not noted any change in Marc's position since then. I, however, offered an alternative that seemed to have been overlooked. > | What I would suggest is that we should have said that unconstrained > | scope was the union of all topics currently used as scopes. Yet no > | one seems to have listed this as a possible alternative definition. > > We could do that, but it would mean that > > a) the unconstrained scope changes every time a new theme is added to > a scope, and Yes, just as it would if you added a new topic and made that the scope of another topic. Are you saying that latter should be disallowed as well? We have to allow for the extension of the set of scopes used within XTM, both during merging and before/after. At merge time we have a static set of topics, so what is the problem? > b) it would be subject to exactly the same problem that Marc > described. > > So I don't think that is a viable solution. The problem is that the intersection of scopes approach causes loss of data, and that I do not like. Marc's suggestion of using all topics is the correct one, but this may result in too heavy an overload for processing. My suggestion would provide a halfway house between the two extremes. (Not that I expect anything I suggest to be used!) Martin From sc34wg3@isotopicmaps.org Tue Jun 25 10:37:51 2002 From: sc34wg3@isotopicmaps.org (Lars Marius Garshol) Date: 25 Jun 2002 11:37:51 +0200 Subject: [sc34wg3] SAM-issue term-scope-def In-Reply-To: <039901c21c28$1969d130$29c466c3@yourudvgq1w43i> References: <049b01c215c5$25c540e0$cdc466c3@yourudvgq1w43i> <039901c21c28$1969d130$29c466c3@yourudvgq1w43i> Message-ID: * Lars Marius Garshol | | That is just an assertion, though. Could you say *why* you think it | would be a mistake? * Martin Bryan | | I gave the reason in the following paragraph, but to reinforce it I | would state that to have XTM use intersection while ISO13250 clearly | states union suggests that the two standards are in competion. I | thought the idea was to try to align them without changing the basic | concepts. ISO 13250:2000 clearly states "union", while XTM 1.0 clearly states "undefined". The reason we are having this discussion is that there are problems with both of those definitions. I tried to explain what I thought those problems were in It may be that these explanations are unsatisfactory, in which case I guess I should sit down and write up a more organized paper on this. (If people feel I should do that, please let me know.) | Marc's preferred option in his 7th June message is "the set of all | topics", which I agree with as it matches the wording in ISO 13250. Well, no, it does not. ISO 13250:2000 says "all topics in the topic map," which is not the same as the set of all topics. That solution will cause complications for the serialization recommendations, the canonicalization syntax, and TMQL/TMCL. That is why I suggest that we use intersection instead, since the unconstrained scope then naturally becomes the empty set, which is free of all these problems. * Lars Marius Garshol | | We could do that, but it would mean that | | a) the unconstrained scope changes every time a new theme is added | to a scope, and * Martin Bryan | | Yes, just as it would if you added a new topic and made that the | scope of another topic. Are you saying that latter should be | disallowed as well? No, what I am concerned about are the presence of side-effects within topic maps. Let's say I have a topic map of 10,000 TAOs (that is, a medium-sized one), wherein about 5,000 topic characteristics are in the unconstrained scope. Now I add a new topic to the topic map, which, I agree, is a perfectly natural thing to do, and next I add it to the scope of some topic characteristic. What happens then is that 5,000 scopes change, even if I didn't explicitly touch any of them. That doesn't seem right to me. I haven't reasoned out the consequences in detail, but it does smell. What happens with scope indexes, for example? What happens with event listeners in an API? And so on. I'm not saying that this is necessarily anathema to me, but it seems to create lots of potential problems, and I don't see that it solves anything. So why should we want to choose it? * Lars Marius Garshol | | b) it would be subject to exactly the same problem that Marc | described. | | So I don't think that is a viable solution. * Martin Bryan | | The problem is that the intersection of scopes approach causes loss | of data, and that I do not like. In what | Marc's suggestion of using all topics is the correct one, but this | may result in too heavy an overload for processing. My suggestion | would provide a halfway house between the two extremes. I don't think Marc's suggestion will cause an overhead that is necessarily that much heavier than yours. The set of all topics can of course not be stored explicitly, but that's not necessarily a problem. The main problem is that it cannot be enumerated[1], which causes difficulties in some situations. | (Not that I expect anything I suggest to be used!) That's strange. I've found your input very valuable so far. I don't see any reason why we shouldn't use at least some of your suggestions, but if you do then please tell me why. [1] Not in practice, and quite possibly not in theory either. It would surprise me if the set of all topics were countably infinite. -- Lars Marius Garshol, Ontopian ISO SC34/WG3, OASIS GeoLang TC From sc34wg3@isotopicmaps.org Tue Jun 25 11:12:55 2002 From: sc34wg3@isotopicmaps.org (Ann M Wrightson) Date: Tue, 25 Jun 2002 11:12:55 +0100 Subject: [sc34wg3] Montreal meeting of WG3 In-Reply-To: <5.1.0.14.2.20020621135025.02d0eae0@mail.ontopia.net> Message-ID: I can do all 3 days - IMO we must have a good structure to the meeting so that priorities are set and followed, & if we agree early on that something is to be taken later it actually is discussed! Ann W. -----Original Message----- From: sc34wg3-admin@isotopicmaps.org [mailto:sc34wg3-admin@isotopicmaps.org]On Behalf Of Steve Pepper Sent: 21 June 2002 12:57 To: sc34wg3@isotopicmaps.org Subject: [sc34wg3] Montreal meeting of WG3 To all WG3 members: Urgent In Barcelona we agreed to have a WG3 meeting in Montreal in conjunction with Extreme Markup. This meeting needs to be organized immediately, so I would like your feedback at once. We provisionally agreed to meet Saturday and Sunday, August 3-4. Looking at the program, I see that Monday August 5 would be possible for most regular WG3 attendees. Our major task is to progress the SAM and RM, so it is essential that those responsible for these two items are able to attend. In addition we would like to have as many other people as possible. Please help me by answering the following questions immediately: (1) Which dates can you attend? (3rd, 4th and/or 5th of August)? (2) Do you prefer a 2-day or 3-day meeting? Thanks. Steve Pepper Convenor, WG3 _______________________________________________ sc34wg3 mailing list sc34wg3@isotopicmaps.org http://www.isotopicmaps.org/mailman/listinfo/sc34wg3 From sc34wg3@isotopicmaps.org Tue Jun 25 18:53:16 2002 From: sc34wg3@isotopicmaps.org (Mason, James David (MXM) ) Date: Tue, 25 Jun 2002 13:53:16 -0400 Subject: [sc34wg3] (off thread) Voting membership Message-ID: <28D46344A4EFD411AAAB00508BDF65EC089EDECB@exchange10.ctd.ornl.gov> > * Bernard Vatant > > | My remark was also about the process that is starting now with AFNOR > | in France, which will be desperately slow I'm afraid. > * Lars Marius Garshol | Well, I hope it succeeds. I would rather see Bernard-with-vote than | Bernard-without-vote. Your Chairman certainly agrees. The more voting national bodies we have, the more secure our future is. (Right now, JTC1, and SC34 in particular, are in trouble because people and national bodies are leaving the process.) As much as the ISUG President likes having a strong ISUG delegation, the SC34 Chairman would rather have a strong SC. Jim From sc34wg3@isotopicmaps.org Tue Jun 25 22:19:29 2002 From: sc34wg3@isotopicmaps.org (Marc de Graauw) Date: Tue, 25 Jun 2002 23:19:29 +0200 Subject: [sc34wg3] SAM-issue term-scope-def References: Message-ID: <007901c21c8e$000dbfb0$0200a8c0@MARCSONY> Lars Marius Garshol > Meanwhile, we need to decide what to do in the short term. I am > leaning towards specifying that scope is an intersection. Bernard > would like to see it left undefined. > > I would like to hear other opinions on this. If I don't get any I will > do intersection for now, and we can discuss this in Montr�al. > The terminology is not a happy one. Intersection and union are things one does with sets. Scope is a set of topics, but when we say that a scope Finland, Norway is an intersection (or union) we are applying intersection (union) to the topics Finland and Norway, and those topics are not (necessarily) sets. (This is not something I came up with, Steve Newcomb noted it too long ago, and problably others too). So one cannot really say that scope is either a union or an intersection. The basic idea behind it is clear though. In some way a scoping topic applies within a certain context, and the topic characteristic assignment is valid when that scoping topic applies. So if we have topic X with name Y which is scoped by topic A, then Y is a valid name whenever A applies. When we refrase scope-as-union in this way we get: if we have topic X with name Y which is scoped by topics A and B, then Y is a valid name whenever A applies _or_ B applies When we refrase scope-as-intersection we get: if we have topic X with name Y which is scoped by topics A and B, then Y is a valid name whenever A applies _and_ B applies What 'applies' really means is not relevant, this is basically up to the application (or user) of the Topic Map. However, if an application wants to do something useful with scope it has to decide whether a scoping topic 'applies' or not - at least I can see not other way to do anything with scope. SAM says: "Formally, a scope is composed of a set of subjects that together define the context. That is, the statement is considered valid only in contexts where all the subjects in the scope apply. In a sense, the scope is made up of the intersection of the subjects it is composed of." Is suggest we drop the terms 'union' and 'intersection' altogether and change the SAM to: "Formally, a scope is composed of a set of subjects that together define the context. That is, the statement is considered valid only in contexts where all the subjects in the scope apply." when we choose what was previously called the 'intersection'-view, which might more approriately be called the 'all subjects' view. Likewise it could be changed to: "Formally, a scope is composed of a set of subjects that together define the context. That is, the statement is considered valid only in contexts where any one of the subjects in the scope applies." when we choose what was previously called the 'union'-view, which we could call the 'any subject' view. Furthermore, I suggest the word 'only' should be dropped. When we say topic name 'economie' is valid in when the scoping topic 'Dutch' applies, we surely do not intend to say this name is valid _only_ in Dutch. What we assert is that it is valid in Dutch, and we do not really say anything about its validity outside this context. (In other words, it is quite possible that other languages use the same word for this topic.) I do not have very strong opinions on the all-subjects or any-subject views. I surely agree that in the former case the unconstrained scope should be the empty set and in the latter one the set of all topics - or some similar construct, such as Martin proposes. For me, as a Topic Map author, either way would work. It seems the any-subject view is compatible with ISO13250 (but phrased better), and the all-subject view is easier implementable for Topic Map application vendors since it avoids the set of all topics. I would tend to the any-subject view for backward compatibility if there is a reasonable way around the problems with the set of all topics (or similar contructs). Since I do not implement Topic Map applications I have no idea whether there is such a reasonable way or not. I certainly do agree with a lot of others that scope should be strengthened and needs some internal structure. I certainly do not think it is useless as it is, but its applicability is limited. Marc From sc34wg3@isotopicmaps.org Thu Jun 27 10:53:48 2002 From: sc34wg3@isotopicmaps.org (Lars Marius Garshol) Date: 27 Jun 2002 11:53:48 +0200 Subject: [sc34wg3] SAM-issue term-scope-def In-Reply-To: <007901c21c8e$000dbfb0$0200a8c0@MARCSONY> References: <007901c21c8e$000dbfb0$0200a8c0@MARCSONY> Message-ID: * Marc de Graauw |=20 | The terminology is not a happy one. Intersection and union are | things one does with sets. Scope is a set of topics, but when we say | that a scope Finland, Norway is an intersection (or union) we are | applying intersection (union) to the topics Finland and Norway, and | those topics are not (necessarily) sets. You are of course right about that.=20 =20 | The basic idea behind it is clear though. In some way a scoping | topic applies within a certain context, and the topic characteristic | assignment is valid when that scoping topic applies. So if we have | topic X with name Y which is scoped by topic A, then Y is a valid | name whenever A applies. And about this. =20 | When we refrase scope-as-union in this way we get: if we have topic | X with name Y which is scoped by topics A and B, then Y is a valid | name whenever A applies _or_ B applies |=20 | When we refrase scope-as-intersection we get: | if we have topic X with name Y which is scoped by topics A and B, | then Y is a valid name whenever A applies _and_ B applies And about this. =20 | What 'applies' really means is not relevant, this is basically up to | the application (or user) of the Topic Map. However, if an | application wants to do something useful with scope it has to decide | whether a scoping topic 'applies' or not - at least I can see not | other way to do anything with scope. And about this. I also you like your suggestion for rephrasing the definition of scope. =20 | Furthermore, I suggest the word 'only' should be dropped. When we | say topic name 'economie' is valid in when the scoping topic 'Dutch' | applies, we surely do not intend to say this name is valid _only_ in | Dutch. What we assert is that it is valid in Dutch, and we do not | really say anything about its validity outside this context. (In | other words, it is quite possible that other languages use the same | word for this topic.) This I am much less convinced about. I fear that if we remove the "only" we are weakning the definition to the point where there is no real distinction between "and" and "or". I also don't think you are really saying "economie" is only valid in Dutch. What you are saying is that it is valid in Dutch. It may be valid in other contexts, but you aren't saying anything about it, just as the concept may have other names in Dutch, but you haven't said anything about that either. I think this is the old "that I haven't said it doesn't mean that it isn't so"-issue. =20 | I do not have very strong opinions on the all-subjects or | any-subject views. I surely agree that in the former case the | unconstrained scope should be the empty set and in the latter one | the set of all topics - or some similar construct, such as Martin | proposes. For me, as a Topic Map author, either way would work. | It seems the any-subject view is compatible with ISO13250 (but | phrased better), and the all-subject view is easier implementable | for Topic Map application vendors since it avoids the set of all | topics. I would tend to the any-subject view for backward | compatibility if there is a reasonable way around the problems with | the set of all topics (or similar contructs). I think this sums up the current state of the issue quite neatly. One thing should be added, however: the any-subjects (or "or") view also causes problems for TMQL and its scope operators, and it is likely to also have awkward implications for TMAPI[1]. Further, it seems that the any-subjects/"or" view implies that the current merging rules should be changed as well. It is beginning to look as if this issue is sufficiently complex that it deserves a write-up in the form of an informal paper that outlines the different solutions, the problems with each of those, and possible suggestions for ways around the problems. If we could have something like that ready for the Montr=E9al meeting I think that meeting could be a lot more productive. Marc, do you think you could be editor of something like that? I know you don't feel ready to do all the TMQL/TMAPI/etc parts of it, but you don't need to write absolutely all of it so much as define the structure of the paper, write most of it, and collect and edit contributions from various people.=20 (I would prefer to do this myself, but I need to do something similar on the TNC, and there should be another SAM draft, and there should be a new XTM syntax draft, as well as a draft of the first GeoLang PSI set, all of it before Montr=E9al, so...) I think if we had something like this ready 2-3 weeks before Montr=E9al the meeting would be in a much better position to settle this issue in a proper way, and for people and national bodies who won't be there to make their opinions on the issue known. [1] --=20 Lars Marius Garshol, Ontopian ISO SC34/WG3, OASIS GeoLang TC From sc34wg3@isotopicmaps.org Thu Jun 27 11:23:00 2002 From: sc34wg3@isotopicmaps.org (Marc de Graauw) Date: Thu, 27 Jun 2002 12:23:00 +0200 Subject: [sc34wg3] SAM-issue term-scope-def References: <007901c21c8e$000dbfb0$0200a8c0@MARCSONY> Message-ID: <007d01c21dc4$a1f86000$0200a8c0@MARCSONY> Lars Marius Garshol > It is beginning to look as if this issue is sufficiently complex that > it deserves a write-up in the form of an informal paper that outlines > the different solutions, the problems with each of those, and possible > suggestions for ways around the problems. If we could have something > like that ready for the Montr�al meeting I think that meeting could be > a lot more productive. > > Marc, do you think you could be editor of something like that? I know > you don't feel ready to do all the TMQL/TMAPI/etc parts of it, but you > don't need to write absolutely all of it so much as define the > structure of the paper, write most of it, and collect and edit > contributions from various people. > OK. I won't be in Montreal though. Marc From sc34wg3@isotopicmaps.org Thu Jun 27 12:46:56 2002 From: sc34wg3@isotopicmaps.org (Jan Algermissen) Date: Thu, 27 Jun 2002 13:46:56 +0200 Subject: [sc34wg3] SAM-issue term-scope-def References: <007901c21c8e$000dbfb0$0200a8c0@MARCSONY> Message-ID: <3D1AFB30.AE7E9A68@acm.org> [Marc de Graauw:] > | Furthermore, I suggest the word 'only' should be dropped. When we > | say topic name 'economie' is valid in when the scoping topic 'Dutch' > | applies, we surely do not intend to say this name is valid _only_ in > | Dutch. What we assert is that it is valid in Dutch, and we do not > | really say anything about its validity outside this context. (In > | other words, it is quite possible that other languages use the same > | word for this topic.) [Lars:] > This I am much less convinced about. I fear that if we remove the > "only" we are weakning the definition to the point where there is no > real distinction between "and" and "or". > > I also don't think you are really saying "economie" is only valid in > Dutch. What you are saying is that it is valid in Dutch. It may be > valid in other contexts, but you aren't saying anything about it, just > as the concept may have other names in Dutch, but you haven't said > anything about that either. Marc, Lars, I don't think that scoping a element asserts anything about the validity of the name for a particular topic. I think that scoping a element asserts something about the validity of using a particular name as a base name for the topic and that means that scoping a element asserts something about the validity of using that name as an unambiguous identifyer for the topic. Therefore, scoping the topic-basename-characteristic between a topic and the name 'economie' with the scope {Dutch} does not mean, that the name 'economie' is invalid in another scope but that you cannot use it as an unambigous identifier unless the scope {Dutch} applies. Does that make sense to you ? Jan -- Jan Algermissen Consultant & Programmer Tel: ++49 (0)40 89 700 511 ++49 (0)177 283 1440 Fax: ++49 (0)40 89 700 841 Email: algermissen@acm.org Web: http://www.topicmapping.com From sc34wg3@isotopicmaps.org Thu Jun 27 17:07:55 2002 From: sc34wg3@isotopicmaps.org (Lars Marius Garshol) Date: 27 Jun 2002 18:07:55 +0200 Subject: [sc34wg3] SAM-issue term-scope-def In-Reply-To: <3D1AFB30.AE7E9A68@acm.org> References: <007901c21c8e$000dbfb0$0200a8c0@MARCSONY> <3D1AFB30.AE7E9A68@acm.org> Message-ID: * Jan Algermissen | | I don't think that scoping a element asserts anything | about the validity of the name for a particular topic. That's not how I read the XTM 1.0 specification. The first paragraph of Section 2.2.1.6[1] describes scope as limiting the validity of "topic characteristic assignments," which clearly includes base names. ISO 13250 uses much the same words, to what seems to me the same effect. | I think that scoping a element asserts something about | the validity of using a particular name as a base name for the topic | and that means that scoping a element asserts something | about the validity of using that name as an unambiguous identifyer | for the topic. The second paragraph of Section 2.2.1.6 says more-or-less what you say here, but I think it is pretty clear that the first paragraph says what I said. | Therefore, scoping the topic-basename-characteristic between a topic | and the name 'economie' with the scope {Dutch} does not mean, that | the name 'economie' is invalid in another scope but that you cannot | use it as an unambigous identifier unless the scope {Dutch} applies. | | Does that make sense to you ? Yes, it does. I think you premise is false, but that the conclusion is right. :) I explained in another email that I think you can't infer from [economy = "economie" / dutch] that the name "economie" might not be used for this concept in other languages than Dutch. All you know is that the topic map author didn't say it was so, but the author might be unaware that it is possible, might not have completed the topic map yet, and so on. So I think we agree on everything here, except your first paragraph above. [1] -- Lars Marius Garshol, Ontopian ISO SC34/WG3, OASIS GeoLang TC From sc34wg3@isotopicmaps.org Thu Jun 27 19:21:49 2002 From: sc34wg3@isotopicmaps.org (Jan Algermissen) Date: Thu, 27 Jun 2002 20:21:49 +0200 Subject: [sc34wg3] SAM-issue term-scope-def References: <007901c21c8e$000dbfb0$0200a8c0@MARCSONY> <3D1AFB30.AE7E9A68@acm.org> Message-ID: <3D1B57BD.5E65D8E4@acm.org> Lars Marius Garshol wrote: > > * Jan Algermissen > | > | I don't think that scoping a element asserts anything > | about the validity of the name for a particular topic. > > That's not how I read the XTM 1.0 specification. The first paragraph > of Section 2.2.1.6[1] describes scope as limiting the validity of > "topic characteristic assignments," which clearly includes base names. Right. What I was up to is that scoping a topic-basename association limits the validity of the 'use' (or assignment) of a particular name as a BASENAME and that it does not mean that the used name isn't a valid (simple-)name for the topic if the scope does not apply. (Either something is a name for something or not, that fact does not change) In other words, we must be carefull not to mix the special semantics of the topic-basename associations (or characteristic assignments) with the general semantics of using names for 'things'. Regarding the example, we must be careful not to infer from the scoped *basename* assignment of 'economie' to a topic, that 'economie' isn't a valid *name* for the topic unless the scope {Dutch} applies. If the scope {Dutch} doesn't apply 'economie' is not a valid BASE NAME, no more. > I explained in another email that I think you can't infer from > > [economy = "economie" / dutch] > > that the name "economie" might not be used for this concept in other > languages than Dutch. All you know is that the topic map author didn't > say it was so, but the author might be unaware that it is possible, > might not have completed the topic map yet, and so on. >From the above association I would infer (assuming that the author is a careful topic map author) that she is damn sure that the name "economie" is an unambigous name 'in dutch' for the topic --economy--. If the author wasn't sure, "economie" should not be a basename but some other kind of name (without the semantics of unambiguity). Sorry, I should have made my distinction between basename and name much more explicit in my first reply. So, again: does that make sense to you ? ;-) Jan > > So I think we agree on everything here, except your first paragraph > above. > > [1] > > -- > Lars Marius Garshol, Ontopian > ISO SC34/WG3, OASIS GeoLang TC > > _______________________________________________ > sc34wg3 mailing list > sc34wg3@isotopicmaps.org > http://www.isotopicmaps.org/mailman/listinfo/sc34wg3 -- Jan Algermissen Consultant & Programmer Tel: ++49 (0)40 89 700 511 ++49 (0)177 283 1440 Fax: ++49 (0)40 89 700 841 Email: algermissen@acm.org Web: http://www.topicmapping.com From sc34wg3@isotopicmaps.org Fri Jun 28 22:37:22 2002 From: sc34wg3@isotopicmaps.org (Marc de Graauw) Date: Fri, 28 Jun 2002 23:37:22 +0200 Subject: [sc34wg3] SAM-issue term-scope-def References: <007901c21c8e$000dbfb0$0200a8c0@MARCSONY> <3D1AFB30.AE7E9A68@acm.org> <3D1B57BD.5E65D8E4@acm.org> Message-ID: <003501c21eeb$ffe4ae80$0200a8c0@MARCSONY> [Marc de Graauw] > SAM says: > "Formally, a scope is composed of a set of subjects that together define the > context. That is, the statement is considered valid only in contexts where > all the subjects in the scope apply." > Furthermore, I suggest the word 'only' should be dropped. When we say topic > name 'economie' is valid in when the scoping topic 'Dutch' applies, we > surely do not intend to say this name is valid _only_ in Dutch. [Lars Marius Garshol] > This I am much less convinced about. I fear that if we remove the > "only" we are weakning the definition to the point where there is no > real distinction between "and" and "or". > > I also don't think you are really saying "economie" is only valid in > Dutch. [Jan Algermissen] > Regarding the example, we must be careful not to infer from the scoped > *basename* assignment of 'economie' to a topic, that 'economie' isn't > a valid *name* for the topic unless the scope {Dutch} applies. So we all agree on that point. Scoping the basename 'economie' with {Dutch} does not imply anything about the name in cases where {Dutch} does not apply. My point was that the phrasing of SAM seems to suggest otherwise. SAM: "...the statement is considered valid only in contexts where all the subjects in the scope apply." rephrased to suit this example: "...the *assignment of the basename 'economie' to topic X* is considered valid only in contexts where *{Dutch} applies*" When we say 'We are open only on Monday', that surely suggests we are closed on Tuesday, doesn't it? So I think the way SAM phrases it now, does suggest that "...the *assignment of the basename 'economie' to topic X* is considered NOT valid in contexts where NOT *{Dutch}applies*". And this is wrong - we all agree about that. Marc From sc34wg3@isotopicmaps.org Sat Jun 29 16:21:13 2002 From: sc34wg3@isotopicmaps.org (Lars Marius Garshol) Date: 29 Jun 2002 17:21:13 +0200 Subject: [sc34wg3] SAM-issue term-scope-def In-Reply-To: <003501c21eeb$ffe4ae80$0200a8c0@MARCSONY> References: <007901c21c8e$000dbfb0$0200a8c0@MARCSONY> <3D1AFB30.AE7E9A68@acm.org> <3D1B57BD.5E65D8E4@acm.org> <003501c21eeb$ffe4ae80$0200a8c0@MARCSONY> Message-ID: * Marc de Graauw | | So we all agree on that point. Scoping the basename 'economie' with | {Dutch} does not imply anything about the name in cases where | {Dutch} does not apply. I agree. How about phrasing the definition of scope as shown below? All topic characteristic assignments have a scope, which defines the extent to which the statement represented by the assignment is valid. Outside the context represented by the scope the statement is not known to be valid. Formally, a scope is composed of a set of subjects that together define the context. That is, the topic characteristic is known to be valid only in contexts ^^^^^^^^^^^^^^ where all the subjects in the scope apply. The changed part of the definition is highlighted above. -- Lars Marius Garshol, Ontopian ISO SC34/WG3, OASIS GeoLang TC From sc34wg3@isotopicmaps.org Sat Jun 29 17:01:25 2002 From: sc34wg3@isotopicmaps.org (Jan Algermissen) Date: Sat, 29 Jun 2002 18:01:25 +0200 Subject: [sc34wg3] SAM-issue term-scope-def References: <007901c21c8e$000dbfb0$0200a8c0@MARCSONY> <3D1AFB30.AE7E9A68@acm.org> <3D1B57BD.5E65D8E4@acm.org> <003501c21eeb$ffe4ae80$0200a8c0@MARCSONY> Message-ID: <3D1DD9D5.425F936@acm.org> Marc de Graauw wrote: > When we say 'We are open only on Monday', that surely suggests we are closed > on Tuesday, doesn't it? So I think the way SAM phrases it now, does suggest > that "...the *assignment of the basename 'economie' to topic X* is > considered > NOT valid in contexts where NOT *{Dutch}applies*". And this is wrong - we > all > agree about that. No, as I said, I do NOT agree with that. If the extend of validity of a basename characteristic assignment is the scope {Dutch} then (at least I) draw the conclusion that it is NOT valid outside that scope. As you say, 'We are open only on Monday' implies that 'we are closed on Tuesday'. My point was, that 'economie' is NOT a valid basename for the topic if NOT *{Dutch}* applies, but that this says nothing about the validity of the potential validity of 'economie' as a mere name. Jan > > Marc > > _______________________________________________ > sc34wg3 mailing list > sc34wg3@isotopicmaps.org > http://www.isotopicmaps.org/mailman/listinfo/sc34wg3 -- Jan Algermissen Consultant & Programmer Tel: ++49 (0)40 89 700 511 ++49 (0)177 283 1440 Fax: ++49 (0)40 89 700 841 Email: algermissen@acm.org Web: http://www.topicmapping.com From sc34wg3@isotopicmaps.org Sat Jun 29 17:32:44 2002 From: sc34wg3@isotopicmaps.org (Lars Marius Garshol) Date: 29 Jun 2002 18:32:44 +0200 Subject: [sc34wg3] SAM-issue term-scope-def In-Reply-To: <3D1DD9D5.425F936@acm.org> References: <007901c21c8e$000dbfb0$0200a8c0@MARCSONY> <3D1AFB30.AE7E9A68@acm.org> <3D1B57BD.5E65D8E4@acm.org> <003501c21eeb$ffe4ae80$0200a8c0@MARCSONY> <3D1DD9D5.425F936@acm.org> Message-ID: * Marc de Graauw | | When we say 'We are open only on Monday', that surely suggests we | are closed on Tuesday, doesn't it? So I think the way SAM phrases it | now, does suggest that "...the *assignment of the basename | 'economie' to topic X* is considered NOT valid in contexts where NOT | *{Dutch}applies*". And this is wrong - we all agree about that. * Jan Algermissen | | No, as I said, I do NOT agree with that. If the extend of validity | of a basename characteristic assignment is the scope {Dutch} then | (at least I) draw the conclusion that it is NOT valid outside that | scope. You have to be more careful with your use of these terms, Jan. I think what you mean is that '"economie" is in this case not a valid unique identifier for this topic outside the Dutch scope'. Whether you agree that it might still be a valid label for the topic outside the Dutch scope I am not sure. The term "base name" is not synonymous with "unique identifier qualified by scope" to the vast majority of people who know about topic maps, simply because that equation is very unexpected and very poorly documented in the current specifications. Also, whether base names will become mere labels or continue to be used as unique identifiers depends on the resolution of the TNC issue. -- Lars Marius Garshol, Ontopian ISO SC34/WG3, OASIS GeoLang TC From sc34wg3@isotopicmaps.org Sun Jun 30 16:05:32 2002 From: sc34wg3@isotopicmaps.org (Marc de Graauw) Date: Sun, 30 Jun 2002 17:05:32 +0200 Subject: [sc34wg3] SAM-issue term-scope-def References: <007901c21c8e$000dbfb0$0200a8c0@MARCSONY> <3D1AFB30.AE7E9A68@acm.org> <3D1B57BD.5E65D8E4@acm.org> <003501c21eeb$ffe4ae80$0200a8c0@MARCSONY> <3D1DD9D5.425F936@acm.org> Message-ID: <002101c22047$99cb0060$0200a8c0@MARCSONY> [Jan Algermissen] > No, as I said, I do NOT agree with that. If the extend of validity of a > basename characteristic assignment is the scope {Dutch} then (at least I) > draw the conclusion that it is NOT valid outside that scope. As you say, > 'We are open only on Monday' implies that 'we are closed on Tuesday'. > > My point was, that 'economie' is NOT a valid basename for the topic > if NOT *{Dutch}* applies, but that this says nothing about the validity > of the potential validity of 'economie' as a mere name. > Jan, I'll try to get it right this time. You say, if I understand you correctly, that in the case described 'economie' is not a valid basename when {Dutch} does not apply, but that it can be valid as a mere name. That raises the question what a 'mere name' is. Not a variant, since 'economie' has in the example not been declared as a variant. Do you mean an conformant application might for instance show 'economie' as a name to a user when {Dutch} does not apply, as long as that application does not treat 'economie' as a basename? So that in a sense elements have a double use: as real basenames, which are unique identifiers, and as name-strings, which can be used in whichever way an application chooses? That makes sense, but it would imply that one can restrict the extent of validity of the name 'economie' as a basename but not as a name-string (mere name). I.e. the scoping of a element would affect only its use as a basename, not it's use as a name-string. I find this couterintuitive and I do not think the standards (XTM, 13250) describe it this way. If this is what you mean, what do you think of this problem? If this is not what you mean, then what is a 'mere name'? BTW, it is appealing to say what you say (and what SAM suggests now) - when a basename is scoped, it is *not* valid outside this scope. It adds a lot of simplicity to the model. We might get around the counterintuitive consequences by saying: when scoped, a basename is not a valid name *for this topic* outside this scope. It might be a valid name *for the subject*, that we do not know, and the Topic Map does not say anything about this. To get back to our example: [economy = "economie" / dutch] This says that when {Cherokee}applies but {Dutch} does not, 'economie' is not a valid basename for topic economy. It is however possible that 'economie' is a valid name for the subject that topic economy represents when {Cherokee}applies but {Dutch} does not. This seems like an intuitive way to define things and keep simplicity. It would say, however, that 'economie' is not valid as a 'mere name' either for *topic* economy when {Dutch} does not apply, just that it might be valid as a 'mere name' for the *subject*. This brings to light some interesting differences between our standards: ISO13250: topic name = A string of characters specified as a name of a *topic* SAM: A base name is a name or label for a *subject* XTM: A *topic* may have zero or more names [Lars Marius Garshol] > How about phrasing the definition of scope as shown below? > > All topic characteristic assignments have a scope, > which defines the extent to which the statement represented by the > assignment is valid. Outside the context represented by the scope > the statement is not known to be valid. Formally, a scope is > composed of a set of subjects that together define the context. That > is, the topic characteristic is known to be valid only in contexts > ^^^^^^^^^^^^^^ > where all the subjects in the scope apply. This means the existing definition would remain as it is (say *not valid* instead of *not known to be valid*), though we could add a sentence explaining these issues, i.e.: "This restriction does not say anything about the relation between the subject and the characteristic in contexts where where not all the subjects in the scope apply. It only restricts the relation between the topic and the characteristic." And we could say: A base name is a name or label for a topic, and, indirectly, for the subject the topic represents. What do you think? Marc From sc34wg3@isotopicmaps.org Sun Jun 30 20:40:08 2002 From: sc34wg3@isotopicmaps.org (Jan Algermissen) Date: Sun, 30 Jun 2002 21:40:08 +0200 Subject: [sc34wg3] SAM-issue term-scope-def References: <007901c21c8e$000dbfb0$0200a8c0@MARCSONY> <3D1AFB30.AE7E9A68@acm.org> <3D1B57BD.5E65D8E4@acm.org> <003501c21eeb$ffe4ae80$0200a8c0@MARCSONY> <3D1DD9D5.425F936@acm.org> <002101c22047$99cb0060$0200a8c0@MARCSONY> Message-ID: <3D1F5E98.AAAD514D@acm.org> Marc de Graauw wrote: > > [Jan Algermissen] > > > No, as I said, I do NOT agree with that. If the extend of validity of a > > basename characteristic assignment is the scope {Dutch} then (at least I) > > draw the conclusion that it is NOT valid outside that scope. As you say, > > 'We are open only on Monday' implies that 'we are closed on Tuesday'. > > > > My point was, that 'economie' is NOT a valid basename for the topic > > if NOT *{Dutch}* applies, but that this says nothing about the validity > > of the potential validity of 'economie' as a mere name. > > > Jan, > > I'll try to get it right this time. No problem, it seems that Lars was right when he suggested that I should be more careful in using these terms. > > You say, if I understand you correctly, that in the case described > 'economie' is not a valid basename when {Dutch} does not apply, but that it > can be valid as a mere name. That raises the question what a 'mere name' is. Let's start with what a basename is: According to the present topic map standards ISO 13250 and XTM 1.0 no topic can have the same basename in the same scope and thus scopes constitute namespaces in which no two subjects can have the same name. This provides the ability to identify topics unambiguously by their basenames. (see Note 31 of ISO 13250) This is what I referred to when I said that basenames have the semantics of unambiguity. The association between a topic and its basename provides more than just a name (or 'mere name' or 'label') for the topic, it provides an unambiguous name (together with the namespace (scope) of course). So, my understanding of a scoped basename is, that it serves as an unambiguous name when the scope applies and that it does not serve as such when the scope does not apply. In other words, the scope expresses the extend of validity of the unambiguity of the name, not the extend of validity of the name alone. Now, what is a 'mere name' ? The fact that existing topic map markup languages provide a convenient way to express topic-basename-characteristics (such as the element in XTM) does not prevent you from defining other association types in order to express topic-name-characteristics that do NOT have the semantics of unambiguity (and could therefore be used to avoid topic-naming-contraint-based merges if you do want to use ambigous names, such as acronyms for example) You could call your association type 'topic-label' and create associations of that type between your topics and the strings that are the labels. > Not a variant, since 'economie' has in the example not been declared as a > variant. Of course not, should be used to express different appearances of one and the same name (such as a GIF image as opposed to a string). > Do you mean an conformant application might for instance show > 'economie' as a name to a user when {Dutch} does not apply, as long as that > application does not treat 'economie' as a basename? So that in a sense > elements have a double use: as real basenames, which are unique > identifiers, and as name-strings, which can be used in whichever way an > application chooses? No, but it seems like a reasonable idea for starting to resolve the issue if the topic naming constraint should be applied on basenames or not in the future. [interestingly you use the term 'real basenames' ;-) ] > That makes sense, but it would imply that one can > restrict the extent of validity of the name 'economie' as a basename but not > as a name-string (mere name). I.e. the scoping of a element would > affect only its use as a basename, not it's use as a name-string. I find > this couterintuitive and I do not think the standards (XTM, 13250) describe > it this way. You are right, they do not define it that way. > > If this is what you mean, what do you think of this problem? If this is not > what you mean, then what is a 'mere name'? See above. > > BTW, it is appealing to say what you say (and what SAM suggests now) - when > a basename is scoped, it is *not* valid outside this scope. It adds a lot of > simplicity to the model. We might get around the counterintuitive > consequences by saying: when scoped, a basename is not a valid name *for > this topic* outside this scope. It might be a valid name *for the subject*, > that we do not know, and the Topic Map does not say anything about this. To > get back to our example: > > [economy = "economie" / dutch] > > This says that when {Cherokee}applies but {Dutch} does not, 'economie' is > not a valid basename for topic economy. It is however possible that > 'economie' is a valid name for the subject that topic economy represents > when {Cherokee}applies but {Dutch} does not. Ah, you DID understand me ;-) > > This seems like an intuitive way to define things and keep simplicity. It > would say, however, that 'economie' is not valid as a 'mere name' either for > *topic* economy when {Dutch} does not apply, just that it might be valid as > a 'mere name' for the *subject*. When I was thinking about an example for the topic-label association above, I realized that after all, your initial problem isn't solved: Suppose I say: '"tennis" is a label for topic T1 in the scope {English}' does this imply that 'tennis' is not a valid label for T1 in German ??? The 'extend of validity' of labaling T1 with 'tennis' is expressed to be the scope {English}. Since we can consider {German} to be beyond that extend it should be logical to say that 'tennis' is not a valid label for T1 in German.... That's rediculous, isn't it ? What does this mean for - the use of languages as scopes ? - the original issue of the interpretation of scope ? > > This brings to light some interesting differences between our standards: > ISO13250: topic name = A string of characters specified as a name of a > *topic* > SAM: A base name is a name or label for a *subject* > XTM: A *topic* may have zero or more names Can you explain what you mean, I do not understand. Jan > > [Lars Marius Garshol] > > How about phrasing the definition of scope as shown below? > > > > All topic characteristic assignments have a scope, > > which defines the extent to which the statement represented by the > > assignment is valid. Outside the context represented by the scope > > the statement is not known to be valid. Formally, a scope is > > composed of a set of subjects that together define the context. That > > is, the topic characteristic is known to be valid only in contexts > > ^^^^^^^^^^^^^^ > > where all the subjects in the scope apply. > > This means the existing definition would remain as it is (say *not valid* > instead of *not known to be valid*), though we could add a sentence > explaining these issues, i.e.: "This restriction does not say anything about > the relation between the subject and the characteristic in contexts where > where not all the subjects in the scope apply. It only restricts the > relation between the topic and the characteristic." > > And we could say: > > A base name is a name or label for a topic, and, indirectly, for the subject > the topic represents. > > What do you think? > > Marc > > _______________________________________________ > sc34wg3 mailing list > sc34wg3@isotopicmaps.org > http://www.isotopicmaps.org/mailman/listinfo/sc34wg3 -- Jan Algermissen Consultant & Programmer Tel: ++49 (0)40 89 700 511 ++49 (0)177 283 1440 Fax: ++49 (0)40 89 700 841 Email: algermissen@acm.org Web: http://www.topicmapping.com