XRM: eXtensible Resource Management

XRM is shorthand for the range of services that RDF/Ontological tools should offer. Using a combination of Application Server Scripting, SQL, XML, XML Schema, RDF, RDF Schema, RSS, DAML+OIL, and OWL, they will syndicate, aggregate, and semantically and ontologically relate server, database, filesystem, and internet resources. This will encompass many previously disjoint operations including:

content management
knowledge management
resource management
events scheduling
information design
user management
customer relationship management
e-commerce
mail and news management
distributed authoring
etc.

The simplest and most intuitive approach to authoring semantic content that occurs to me is to manage resources through a directory style view, as one does bookmarks or email. Rather than navigating solely by file system directories and files, however, the directories in this case would be things like RDF classes and properties and the files would be resources.

When a new resource is added, a url is entered as its unique identifier and a label (or labels, in multilingual mode, using xml:lang) is entered, as with bookmarks, for ease of human readability. (Later, when the manager is more advanced, RDF classes will be offered for use as templates for the new resource, and there will be an option to mark the new resource as a property.) Subsequently, statements may be made about the resource by adding properties to it. Known RDF properties (either general, such as the dublin core, or class specific, if the resource has a class) are offered by their labels (with full URL on mouseover) and sorted by namespace for selection, or a new one can be created. Once a property is selected, known resources are offered or a new resource or literal may be entered as its value. Thus a full statement can be entered into the manager.

The manager will offer three other features of primary interest:

Each resource entry will offer a link to open a new window to view the resource being described. In this way, the manager becomes a resource location and annotation engine.
From any level of the directory, a link to the equivalent RDF/XML serialization of the information being managed will be offered, and a standard navigation will be maintained so that other engines and agents will be able to usefully traverse and even author semantics in the manager.
The directory will also be customizable using a sophisticated faceted search and filtering engine which will allow the user to formulate sematic queries, format their output (as HTML, XML, RDF/XML, OPML, RSS, etc.), and archive these settings as report profiles.

In his Design Issues document about Generic Resources, Tim Berners-Lee defines a "resource" thusly:

A "resource" is a conceptual entity (a little like a Platonic ideal). When represented electronically, a resource may be of the kind which corresponds to only one posisble bit stream representation. An example is the text version of an Internet RFC. That never changes. It will always have the same checksum.
On the other hand, a resource may be generic in that as a concept it is well specified but not so specifically specified that it can only be represented by a single bit stream. In this case, other URIs may exist which identify a resource more specifically. These other URIs identify resources too, and there is a relationship of genericity between the generic and the relatively specific resource.

He goes on to give a suggestion about using RDF to model these relationships.

The main trick in this area is generally called Content Negotiation. A more advanced version of this has been proposed by rfc2295 Transparent Content Negotiation in HTTP (TCN) and rfc2296 HTTP Remote Variant Selection Algorithm -- RVSA/1.0.

Standard variance techniques are to be supported, where applicable. The .var type map file/Multiviews approach, using the http headers URI, Content-Type, Content-Language, Content-Encoding, Content-Length, and Description has yet to take into account time- and semantic-variants. While TCN's new catch-all header Accept-Features (more accurate: Feature-Set-Info) seems prepared to handle these (new?) variant types, even it is limited to static content negotiation.

As more and more dimensions of content variation emerge, it becomes increasingly unwieldy to maintain vast numbers of variants and their metadata in the filesystem. Dynamic content, where the varying content itself (and metadata) is either stored in an encapsulating XML file, a database, or even contextually generated by server scripts, allows greater flexibility of both management and request-time transformation. This necessitates Dynamic Content Negotiation, server-scripted variant selection algorithms that respond not only according to client Accept-* headers, but also to ReSTful (querystring, form, and cookie) parameters to extend the means of negotiation.

The listing for a given directory will now come out of the metadata statements made about resources in that directory, rather than directly from a scan of the directory in the file system. The metadata about file resources will be kept up to date through a combination of scanning the directory upon load, update upon check-in/check-out, and other maintenance operations such as import, backup, and syndication. It is vital that the user be presented with a seamless view of the namespace as it covers both file system resources and database resources.
Whenever a new directory or file is discovered (new in this case meaning a resource with no statements yet recorded in the database), the application will create a baseline set of statements that describe the resource, all sharing the url of the resource as subject, and setting values for properties such as name, type, creation and last modified dates, etc. This RDF instance will be used as the basis for further management statements to allow the user to assign settings, set up privileged relationships, serialize, syndicate, and reuse the resource.

The manager will also be the tool used to create database resources, where an RDF instance stored as triples in the database includes not only the metadata describing a resource, but also the actual content of the resource as a literal. Even file resources may have their content duplicated in the database, so as to be searchable using high-speed SQL queries.

Some display techniques picked up from CVS:

displaying only the version number instead of the whole file name
displaying the date in a smaller font
trimming off the year and offering the time as we approach the present
displaying (a link to) commentary on each version
displaying authorship

  The technique for locating database resources picks up where normal Content Negotiation leaves off. By inserting a custom handler for the HTTP status code 404 File Not Found, in this case a server-side script called ResourceLocator.html, the application is able to take the requested url and retrieve any statements made about it, such as what versions are available. From there, it can compare against the usual content negotiation headers and any additional ReSTful restrictions and return the appropriate variant resource, which may originate in the RDF itself, elsewhere in the filesystem, or elsewhere on the net.
  If no statements are found about the requested resource, the name can be analysed for typos and casing (see mod_speling) and for otherwise similar names both in the db and the fs.
  And ultimately, if no resource matches by any strech of the imachination, the application can present a management page that offers to create the requested resource, asking for appropriate title, description, and other metadata. If no content is given, the statements can be recorded about the non-existant resource (or empty node?). If the user is a guest (that is, has not logged in as a registered user), or has logged in, but hasn't the privilege to allow them to create the resource (or metadata), the submission is marked for moderation and is not published by the site unless approved by someone with appropriate privilege.   Every resource, when browsed, should offer (by author/owner preference, of course) all its metadata, probably discreetly in the footer, with links to the appropriate variant resources along each dimension, as well as authorship, interesting dates, commentary, etc.