Underpinnings of Conzilla
Introduction
As Conzilla has been developed in a research context we have put quite a lot of effort into the design. The result includes style sheets for flexible presentations, SHAME generated forms for editing and presenting metadata, persistent identifiers for avoiding broken links, collaboration by allowing context-maps to be spread out, RDF for interoperability, and a plugin system for allowing extensions. In this chapter we will go through these 'underpinnings', explain how they work and what they are good for.
Everything is RDF
Understanding how Components are Stored
A context-map consists of a list of concept and concept-relations and their graphical layout information, this is stored in a presentation container. The concepts and concept-relations as well as descriptive information around them like titles and descriptions are stored in an information container. Both presentation and information containers are realized as files on your hard drive (or on a server accessible via ftp). Note that the presentation and information containers can be the same file. For simplicity, we will from now on refer to containers as files. In the way we store the various components there is no direct correspondence to individual files:
- Several components can be store in the same file.
- Components can be divided into parts and stored in several files.
The last point is especially important, e.g. if people want to collaborate around context-maps. More specifically spreading out components in separate files are useful when it is important to:
- Preserve the origin of information
- Allow people to edit maps without requiring edit rights of the original files.
- Avoiding local copies of maps when people contributes to them.
- Minimize the risk of disrupting the information other have contributed.
- Support a multitude of opinions.
- Provide the basis for a more fine grained publication process.
Globally unique identifiers
Every component have an identifier in the form of a URI. The identifiers are used for:
- expressing concept-relations.
- referencing the concepts and concept-relations the context-map wants to present.
- specifying hyperlinks between context-maps.
- gathering information for components that are spread out.
- etc.
As you see, identifiers are vital to the inner workings of components. The decision to allow components to be spread out in different files has as a consequence that if two concepts have the same identifier – they are the same component. Hence, making sure that identifiers are globally unique is vital (unless you want to add to existing components). As suggested above you should use a namespace over which you have control, e.g. a subdirectory of where you homepage resides. Observe that we do not require that the identifiers of the components are URLs, i.e. that the identifiers scheme specifies a way to retrieve the component. Clearly this would make little sense if the components are spread out in different files. Instead, whenever a component is referenced via its identifier it is accompanied with a list of files to load if it is not obvious from the situation. Such a list is doomed to be incomplete at least for widely used components. This is clearly a limitation of the management of components. It should be noted that the limitation is unavoidable if you want the freedom to express your opinions or extend what other people have done in a distributed manner. A solution where you voluntarily register your extensions when you want others to find them is planned but not yet realized. It is also interesting to consciously leave certain files out for looking on a component from a certain perspective.
Identifiers for retrieving files
When you follow a link in a web browser it loads the page linked to. Similarly, when you follow a link in a context-map you must load the files where the context-map and the concepts and concept-relations it presents is expressed. This requires that the files must have identifiers that allows you to retrieve the files themselves. Hence, just like components we require that files have globally unique identifiers, URIs. More specifically, we require that it is well defined how to load a file given its identifier. In more formal terms this means that the file identifier should be a URL or alternatively be a URI that is resolvable into a URL.
A general principle is that when people are in the creative process of creating components, i.e. context-maps, concepts and concept-relations, they should be protected from technical details as far as possible. More concretely, we believe that it is acceptable to specify a globally unique identifier-base at the start from where all globally unique identifiers will be generated (as we do in the sessions). However, we do not believe that it is acceptable to force people to decide on the exact location of the files before they start.
Hence, we do not want the file identifiers to be URLs since we believe it would among other things inhibit the creative process. The latter approach, with a resolving mechanism, is a bit more complicated and involves an intermediate resolving step every time a file should be loaded as well as administrating and keeping the resolving mechanism up to date. However, the resolving mechanism has other benefits:
- files can be referenced from the start, no need to know the physical server they will be stored on eventually (i.e. you do not need to know the domain name and the path to your storage space on the server in advance).
- if files are moved to another place you need only change in the resolving mechanism, avoiding breaking references. This is especially important in the case when others have referenced your work and you have no possibility of changing those references yourself (except contacting people that are responsible for those references).
Another argument for using a resolving mechanism is the absence of relative links in the underlying representation format (RDF), this makes it harder to sustain referencersntegrity when moving large sets of files. (Relative links are often used when building html web-sites, allowing you to move sets of pages between systems without breaking internal links.)