Store, cache and resolving
The ResourceStore, available from the ConzillaKit, is the starting point from where all the communication with storage is done.
The ResourceStore handles Components and Containers (both subclasses of Resource) where Components are views of metadata around a central URI while the Containers are containers for the metadata, typically metadata for a set of Components that somehow belong together. The ResourceStore delegates the storage of the Components to the Cache (typically in memory only) and the Containers are delegated to the ContainerManager.
All loading are done through the ResourceStore, including real loading of Containers and the creation of Components (metadata views) from the metadata residing in loaded Containers. The functions are called getAndReferenceX where X is Concept, ConceptMap, the generic Component which loads any of the former as well as Content Components, and finally Container. The caching in the Cache and the ContainerManager is done behind the scenes.
You requests a Resource by its URI (the se.kth.cid.identity.URI) which is easiest to manufacture from strings via the class URIClassifier. The reason for not using the java.net.URI is historicall and has to do with it's failure to handle URI-schemes like urn:path. Observe, that for urn:paths it is neccessary to do an initial resolving to get a retrievalble identifier see below, i.e. a URL.
First it is important to realise that only Containers needs to be retrieved, all Components are assumed to be metadata views of metadata in Containers (that might need to be retrieved before the Component can be successfully inspected though).
Let's consider the situation when we want to load a Container called urn:path:/org/conzilla/people/matthias/presentation.rdf. In the local resolver there are two mappings defined:
When resolving the longest path that matches is replaced with its belonging BASE URI. In this case the resolved URI would be: http://www.conzilla.org/people/matthias/presentation.rdf.
In the code this is achieved by the ResourceStore asks the resolverManager of a list of resolved URLs. Then the ResourceStore tries to load the Container from the resolved candidated URLs in order until it succeeds or fails alltogether.
TO be continued.