Talia Core System Functional Specifications

Maintainer: Daniel Hahn

This document is not complete

Introduction

These specs might be a bit boring, since there are no actual users involved. However, it should make the workings of the Talia Core clearer.

Scenario

Let's assume that someone (let's call her Michaela) wants to build an application with the Talia classes.

Before he can start accessing the library, Michaela might want to set up the ontology which describes the types of Sources and Relations in the database.

After that, Silvia will use mainly the Source class and it's dynamic accessors to manipulate the data in the library.

Sources and names

Before she starts, Michaela has to understand how the data is stored and named in the system.

The basic elements are called Sources. Each source is a document in the library and each of them has it's own unique address, which is a URL like this: !http://www.hyperpop.org/letter-to-maria. The first (domain) part of this URL (!http://www.hyperpop.org/) is the name of the TaliaNode. The second part (letter-to-maria) is the name of one document (Source) in that Node.

Local and remote nodes

All documents in the local node (the local library) are called local sources. Documents that are stored in other nodes (they are in a different library) are called remote sources.

For example, when Michaela uses the "HyperPop" library, all Sources with names starting with !http://www.hyperpop.org/ are local. All other Sources are remote.

The local library will contain information on both local and remote resources. However, it will only know about remote resources that are related to the local content in some way.

If necessary and possible, the library will fetch information from the remote node(s). This will be transparent to the end user in most cases.

Setting up an ontology

Source and Relation types: Each source can have multiple "Source Types". These are not the same as the actual object type of the Source object! These types will be represented by SourceType objects.

(TODO: Maybe these will contain constraints for sources) (TODO: Relations between source type and class type?)

There will also be RelationType objects which may contain constraints for relations (TODO: check if we need those constraints)

(TODO: What about constraints for remote types? Should remote source really be untyped?)

(TODO: Ontology checking within ActiveRDF)

(There is a lot missing here)

The ontology will be defined in a native format or XML (e.g. RDFS). It will be read at startup. From the ontology, the system will create the types and namespaces in memory, and all necessary symbols to use them.

Creating new Sources

A new sources is created with mysource = Source.new(uri, *types = nil) where uri is the URI that this source uses, and *types is a list of source types. If the uri is just a plain string the system will create a new local Source with the given name.

Otherwise the system uses the given URI to decide if the Source is local or remote.

For remote sources, the system will try to load the type information from the remote source, and merges it with the given type information for the local representation. (TODO: Maybe this needs to be configurable)

Accessing the data

For normal operation, Michaela will use the accessor methods of the Source class. The Source class has some find methods that can be used to look up sources. The search will only find local sources. (TODO: How will remote sources support these?)

• There is no global Source.find(:all), since it does not make sense to get all the data from the library
• However, you can use Source.find_type(type) This method is passed a !SourceType and returns all Sources of that type.
• There is a generic Source.find(options) function. Options include:
  • :type - Returns all the sources with the given type. The value is a !SourceType (see above), or an URI describing a source type.
  • :something - Will find the Sources where the relation "something" (this can be any relation name). Is set to the given value. The value is a string literal or an URL. TODO: Behaviour if the relation is not valid
• The methods return an array of Source objects
• TODO: Do we need a cut-off to limit the number of objects found?
• The Source.find(name) method will return the local source with the given identifier.
• To check for a Source, you can call Source.exists?(name)

Source class methods

Once Michala has found some Source, she can do more things with the objects, in order to browse the library. The Source class will support the following calls:

• relations - Returns the names of all the relations that the Source currently has. Relations are only relations to other Sources
• properties - Returns the names of all the properties the Source currently has. Properties do not include the relations to other sources.
• TODO: How will the distinction above work with the RDF?
• types - Will return the !SourceType objects that describe the object's type
• xxx - An unknown method call will return the value of the property/relation. If it does not exist, it will return nil (as !ActiveRDF). These can also be used for assignment.
• uri - the URI of this Source
• save - Saves the source object itself and all relations/properties that it holds. This may return an error.