Author: Graham Moore , gdm@empolis.co.uk (based on XTM CMS Swindon meeting and subsequent face-to-face)
I thought I'd put this picture together to hopefully shed some light on the idea of resources and that in the world of topic maps model is not enough and that we have to consider model in conjunction with operations on that model/ or in terms of that model.
The picture below shows how the different domains in topicmaps interact via model and operations.
Area A is the subject space. This is the intangible mess of ideas and thoughts and perceptions had by people. This area is a topic map author's brain, for example. The circles denote concepts, subjects (in tm speak).
Area B is the topicmap model system space. So from a syntax and import/processing or through direct interaction a topic map model is constructed in some computer system. The circles represent topics and the lines between them represent the topic associations.
Area C is the domain of resources. This is the 'information domain', 'resource domain', the place where 'real data' lives. It is the files on the file system, the contents of a string, the contents of a database. The boxes are the resources.
These three areas together consistute the areas of activity. When we are discussing topic maps, topicmap systems and topic map models we have to be aware that we are spanning two chasms and three domains. The section below discusses the nature of the associations within and across these chasms and pillars.
1. This is the migration/ capture of subjects in the conceptual domain to their topic proxy in the topic map domain. The mechanism used here is human perception (at some level - either through authoring or creation of an automatic authoring process).
2 and 3. These two are grouped together as they work together and are to an extent redundant without the other. Summary: 2 and 3 show that a resource is located by a locator and a function, and that the result of executing that function returns a handle onto the resource.
So, a little bit slower, At the begining of Line 2 is a resource locator, say 'http://www.topicmaps.com/index.html', the line itself represents conceptually which resource the locator references. There also exists a function, lets call it FOO(), the execution of the function FOO() on a resource locator resolves to this resource (indicated by line 2) and then returns (line 3) a handle onto the data that is the resource. From this handle it is possible to read the resource data.
4. just shows the interconnections of the topics with other topics by associations. The same idea can be applied with the system as with 2 and 3 above, in that topics are resources, resource locators exist, that there is a function that resolves a topic reference to the actual topic. The only real difference is the difference in the environment in which FOO is executed. In the case of general resource locators the scope is universal computer systems, in the case of the topic locator it is the topic map system domain.
Here are a couple of thoughts relevant to XTM model and syntax. The CMS model has used this pattern as a basis for its model of resources, including the idea of the resolution function FOO.
The idea of resourceData from the syntax group DTD is also relevant in this area. If I understand it correctly the idea is to allow an occurrence to reference just a string of data, i.e. 'Graham Moore', and that data should be directly included in the processed model. The approach as I see it is to have a special structure called resourceData which contains the string 'Graham Moore'. The model above can be used to achieve this without the need to introduce additional elements with additional semantic baggage. I would propose that the following would be consistant with the resource model and achieve what is desired:
<loc href="urn:value:Graham Moore" />
In this example the resolution of this locator by the FOO function returns a handle onto the resource and getting data from that gives the string of characters.
The FOO function needs to be able to distinguish these different naming schemes anyway, HTTP etc. I realise that it is going to be hard to get/ define the urn scheme, but I think something like this is more 'right' and we shouldnt shy away from it because there are registration/ syntax issues.