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.

RDF Triples are stored in a set of three tables. This design was based on suggestions found in the work of Sergey Melnik, the mailing list of the W3C's RDF Interest Group, R.V. Guha, Matt Biddulph, Libby Miller and Dan Brickley, who have all been investigating how to store and query triples against standard RDBMSs.

The current design is implemented in postgresql thusly:

app_skybuilders_com=> \d odbm_rdftriples
Table "odbm_rdftriples"
Column	Type	Modifiers
id	integer	not null default nextval('"odbm_rdfstatements_id_seq"'::text)
subjectid	integer
predicateid	integer
objectid	integer
isresource	text
Primary key: odbm_rdfstatements_pkey
app_skybuilders_com=> \d odbm_rdfresources
Table "odbm_rdfresources"
Column	Type	Modifiers
id	integer	not null default nextval('"odbm_rdfresources_id_seq"'::text)
uri	text
Primary key: odbm_rdfresources_pkey
app_skybuilders_com=> \d odbm_rdfliterals
Table "odbm_rdfliterals"
Column	Type	Modifiers
id	integer	not null default nextval('"odbm_rdfliterals_id_seq"'::text)
literal	text
Primary key: odbm_rdfliterals_pkey

However, there is nothing PostgreSQL-centric about the design. It is ready to be instantiated in any other RDBMS easily, and can be interfaced with using plain SQL. Other query languages like SquishQL, RQL, RDQL, and RDFQL and others in the rdfdb-style can presumably interface to this design with minimal design changes.

  Resource Types should be defined through a Schema Manager which authors RDFS through a familiar folders, files, and forms tool. Each resource type could have an index page (which describes the type and browses all of the resources of that type), and a management page (where the schema can be edited). These pages should be standard locations both for users and other programs.

  Each resource type should have independant privileging per-group and per-user. Custom privileges could also be modelled for various management areas (see privileging and customization).

  Bookmarks

  Contacts. Anyone can grap or feed another user's public (or privileged) info as a contact. Annotating other users with creator-marked metadata is encouraged. Anyone can created a new, non-active user as a contact (how is this reconciled with an active user with the same email address?).

  FAQ. FAQs could have Question and Answer pairs which publish into a CSSable template just like blog posts do. They could be categorized (even faceted).

  Polls. Anonymous voting. Standard reports with graphs, percentile, and full count, sortable, filterable and searchable. Includeable and syndicated at standard URLs. Link in feed.

  Quotes. Semantic author linking. Offer bibliographic references; ISBN, link to line or chapter on Project Gutenberg or equivalent if available. Faceted/thesaurus/semantic directory management.

  News Page. Serialized articles and stories publish to CSSable template, blog-style. Sharable, faceted topics and sections for categorization. Could also receive aggregation mixed in. Specialized workFlow.

  Time, Address, and Name Format templates. Blog-style templates.

  Notification templates.

  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.

  Genericity in more depth.

  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.

Resources should at least be kept both in the file system and in the db, if not only in the db for the sake of full-text searching via SQL. If the resource is only in the file system, it cannot be queried.

  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

  Moving files (and directories) singly or as a bulk operation is very important. The Shop module has the idea of a 'pallet' which you put items into and then move or alias them into other categories. Likewise the Pages module could have a 'binder' (or some more intuitive metaphor), an erzatz clipboard that allows the user to 'take' a group of pages and/or directories, navigate to another directory and either move or copy (or alias) them to that location.

  Other interesting things to see about a resource are size (in k or in bytes) and number of lines (for at a glance change detection).

  The user's current privilege should be displayed for each resource (even the icon could reflect restricted access by being greyed-out).

  A style option for this and all manager views could be alternating row colors for readability. This could be implemented in the background as CSS classes. They could be styled identically for the current look, or differently for the alternating look.

  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.

  Some structuring could take place inside of each resource's content. If there are anchors assigned to various elements, those anchors could be recognized and leveraged by server-side analysis. Statements could be made about these fragments. If CSS usage of ids conflicts, perhaps a new sky:Ref or sky:Anc or just sky:Id attribute could be introduced. Standard structures that could be generated as part of a view of such a resource include:

• A table of contents or overview at the top of the page, reflecting the heirarchy of sections.
• An index at the bottom of the page, revealing some of the semantics of each section with links by category or topic.
• A table of full metadata, including links to other resources that refer to this one.

  These structures could be offered as feeds in rss or opml, to give and abstract view of a the resource's contents.   All public metadata should also be generated into the resource's head as meta tags.

  Auto-destruct: any resource could be scheduled for auto-deletion as of a date/time.
  Request/Publication restrictions: Requests could be rejected from anywhere off-site, specific IP groups or domains, or even specific Template Resources ("I won't let that rag publish my article"). Conversely, A resource that is aggreagating or otherwise accepting submissions from the public could reject anything from a specific address or even individual authors.
  Tag Restriction: Any resource (or metadata field of its Type) could define tag restrictions to be validated against upon data submission. This is just a list of tags not to be allowed, in case there should be a reason not to.

  Allow 'sumissions'; tentative edits to any resource, marked as tentative and not-to-be-published, for the admin/owner to edit/schedule/annotate/merge/validate/reject as is seen fit. Tentative resources could also be created where no prior resource exists, to fall under the domain of the directory owner. There could be notification settings assoc with submission arrival. Sttings could also only allow them from particular groups or users, or not at all.

  There probably ought to be a flag (or workFlow) that determines whether a given resource will be published upon request or not, like enable/disable in Shop (perhaps a preference could cause workFlow to inhibit pulishing unless page status is Publish).   Perhaps Fragment Resources could have a setting to keep them from serving into inappropriate contexts. Either they could only publish to Template Resource requests, or restrict based on user agent ip/domain.

  Every resource should have a title, a description, and an abstract.   Resources, esp. Page Series and Pages, should be categorizable from their Metadata Management pages.

  A resource could be scheduled according to a rule rather than at a concrete date/time (moment?). For instance, a variant could be scheduled for any monday while another variant could be scheduled for any tuesday, etc.

  Include a Content-Language header in each Language Variant page as it is created.   A full locale code list as found in any browser is required, so that variants for any locale may be constructed, indepedently of whether a string set has been created for each of them. This may require a separate structure from Locales, depending on how AdminLabels handles the creation of new labels.

  Directories must be treated as resources, with standard metadata kept such as title and description. Also vital for each directory is per-group and per-user privileging.

  A keystroke like control-s should be fielded by javascript to execute the Save command, just like clicking the link.

  One resource can be included in another using what we call a hyperinc.
  When managing a Template Resource (a resource that includes other resources via sky:Inc), the included resources should be likewise manageable either via bulk operations or links to the same management interface for the included resources (especially skyWriter should link to skywriting each included resource). Conversely, a Fragment Resource (a resource so included) should provide the same operations and management links (again, esp. skyWriter). Keeping track of the contexts in which a Fragment Resource is being used is key. Forking the content of the resource is tantamount to moving a resource in complexity, as some of the references to the original resource will have to change to point at the forked version. But offering an index to the including Template Resources makes the job a little easier. There is a question here about whether this kind of forking can happen within a Series, as a semantic mark between variants, or whether a new Series is always required.
  Blog posts, as viewed by anyone aggregating them or being notified about them (say, an administrator), could be reposted (riposted?) to another blog at a click. The repost interface could offer to crosspost, add content, post as text (quote) for annotation or post as include (hyperinc, sky:Inc) for reuse.

  When browsing a resource, a special search mode could be made available that replaods the page, highlighting the search matches, offering an index to results at the top (each could be dynamically anchored with a result index), and a prev and next link could be appended before and after each result (probably a tiny arrow gif).   Thesaurus-like alternates should be offered via a see also section, including preferred terms, broader terms, narrower terms, alternate terms, related terms, opposite terms, etc.   Regular expressions should also be supported.

Users search in particular should expand to make them searchable by any piece of metadata available, including url, registration, etc. These searches should not be made case sensitive unless the user requests that mode. Reports should offer sorting/filtering by latest logins/registrations. Results and reports could also display whether the user is online.

  Results for all resource types should be filterable and sortable by most recent activity, popularity (hit count or rating), creation date/modification date, etc. Each resource type could offer a contextual faceted directory view and faceted thesaurus matching for criteria for improved searching.

  workFlow is a system of resources that allow management processes to be modelled and tracked. Flow charts can be generated, even published and imported in a variety of XML formats for interchange with other tools.

  It's also very important for other resource type to be integrated with workFlow. Pages is a good example, where only pages that are promoted to publish should be visible. The actual operation of other resources should depend on their workFlow state. Conversely, workFlow Tasks, Steps, and Phases should be able to be contingent on the filling out of a Form, the confirmation of a Payment in the Shop, or other resource actions.

More optional elements for insertion into the skyPages footer (or header) on a per series basis:

• Last updated
• Draft navigation
• email - mailto: link to each page author/maintainer
• Current Date and Time - "Served at: "
• 'add me to notification of page update' link
• mailto: link to commentary - that is, an email address which receives a mail and posts it as a new comment
• subscription to commentary digest - needs skyPulse
• mailto site admin/webmaster?
• Authorship
• Last Modified date
• copyright string © orgName
• Email this page link

  Footer could also include some Community-wide info like messages, ads, or copyright info.

  For series edits/accesses/changeovers, a possible form design follows.
I am interested in being notified when:

a new page occurs in this series
a page in this series is edited
a page in this series is rescheduled
a comment is made about this page
a comment is made about this series

  Notifications need management, privileging, logging, etc. just like any other scheduled server action.

  Different types of notification may need templating, for boilerplate insertion, styling, etc. These templates could be a resource type.

  Offer attachments to be managed as related resources.
Offer multiple selection and bulk operations such as move and delete.

  The persistent archive should offer a toggle for chrono sorting asc or desc, sort by author, by title, and a toggle for descriptions.

  There could be a preference could either conceal email from the interface altogether (though allow mail to be sent to that user by that address without showing it), or display it in a spam-safe way like "dtd@skybuilders.com" would appear "dtd at skybuilders dot com", a trivial transform.
  Other interesting personal info that could be kept:

• ICQ, AIM, Yahoo Messenger, MSN, Jabber, or other chat ids or numbers
• url/bookmarks (could be in separate section)
• occupation
• interests
• description
• plan file (perhaps autogen in home directory)
• sig file (perhaps autogen in home directory)

  The personal skyPage should be a seriealized Template Resource that includes various feed resources. It should be autogenerated as part of the user's home directory. The key resources to include are personal info feeds such as name, email, phones, addresses, settings, and privs, each with a link to edit the info displayed. Other useful resources are activity reports like recently edited (see activity log) pages, events, tasks, email, latest comments made by the user, latest comments on user's resources, etc. All of these feeds should be customizeable (via flat HTML stylable with CSS or DHTML by preference) and link through to managing the displayed info. They should also be available to be included in any resource.

  The same page could be available to other users, even guests, restricting itself to info the user has marked as public (see privacy control).

  Site slogan.
  Formats.
  Email errors to support.
  Messages, ads, or copyright info to appear in footer. These could be channeled from any resource/feed.

  Resources should have a standard API for editing, managing, and commenting.
Likewise for privileging.

  Privileges can be module wide, based on a type of resource, on a series of resources, or on an individual resource.   Some privileges could be marked as dependant; the privilege for one user would be contingent on the privilege of the user who assigned it. The assignment of privileges should be logged and auditable. It could have notifications associated with it, etc. The report could be viewed on a timeline.

  An optional widget could feed the list of users currently online (which should be available as an includable resource and syndicated).   An optional widget could feed the list of 10 latest pages to go live, or the 10 about to go live (which should be available as an includable resource and syndicated), as a sanity check for publishers (restrictable to the resources you own, are associated with, or all).

  New table names are needed for storing XML nodes and RDF triples.   Errors could be caught and emailed to support, based on a site setting.

  Change Password should have links back to other personal info pages (and User Manager, when applicable).

  All activity (every insert or update) should be logged against the resource being modified. This provides an audit trail, reversion history, statistics, etc. Actions could be modelled as properties. Activity reports (avail. as rss/xml/rdf feeds and as sharable, configurable, includable resources like blocks) should be filterable/sortable by resource type, action, user, date, etc.

  Track referers per resource. Offer referer management from resource management page. Content could offer separate versions per referer (referer become a semantic dimension). Footer should link to referer list, list should be syndicated and includable.

  Stats may be displayed as graphs. Measurements may be given both as percentile and as total number. Most are based on resource hit count. Interesting statistics include:

• browser type (with icon for each)
• operating system (with icons)
• visitors by hour
• visitors by day
• visitors by month/year
• by resource type
• by dir/section/semantic
• by individual resource
• number of logins/registrations/other actions

  Form element font size and border are stylable using CSS.
  Each user could override any of the standard icons or images as part of a custom theme.
  Server pages could have CSS pages assigned as settings, overrideable per-group or per-user.
  Themes? CSS groups? Formats?

  Time, Address, and Name Formats. Default, site-wide, per-group, and per-user settings. Theme-based? By locale? By dialect?
  Setting could dictate what template is used. Template could be blog-style, with skyTags for positioning of known data elements. Templates could be a new resource type.

  Resources could be rated semantically; given a score based on how accurate they are according an arbitrary semantic (useful, informative, funny, on-topic, etc.).

  A skyLink (or new term) ought to be a new way of linking to a resource that checks for the real resource at the given url, returns it if available, returns a (well-identified) cached version if not.

  A skyImage ought to be a new standard resource type that offers a link to variants by resolution, color space, and subject (other pictures of the same or similar things, for instance).

  Publish a snapshot of a directory structure to a deployment server at the click of a button as static files.

  A simple, non-javascript based date input wouldn't have day names or time zone selection or dynamic dates per month (the features that require scripting). Would this lightweight version be preferable anywhere?

  Metalog
  Metapad
  skyLog
  skyPad