Wednesday, December 7, 2011

Mapping RDF formats to nested stores

Looking at other 'ontology' definitions, the subject becomes, ho0w well to they map the the engine architecture? Consider the example below from Wiki:

A resource with statements "there is a Person identified by http://www.w3.org/People/EM/contact#me, whose name is Eric Miller, whose email address is em@w3.org, and whose title is Dr.".

An RDF Graph Describing Eric Miller[15]
The resource "http://www.w3.org/People/EM/contact#me" is the subject.
The objects are:
"Eric Miller" (with a predicate "whose name is"),
em@w3.org (with a predicate "whose email address is"), and
"Dr." (with a predicate "whose title is").
The subject is a URI.

Let me take a shot with defining an element that matches the person definition, in TypeFace Explosion. I use the $, as a predicate indicator, likely wrong, but good for the moment:

URL$Subject.(name$Person's name,email$email address,title$Dr)

Where does the $ appear in this instance? Likely as an overload on link in Key,Link,Pointer; the engines general triple format. The engine only reserves the first byte of link, thus three free bytes are enough to add more than the Dublin Core predicate modifiers. So using this 'direct map' overload the link, then the enclosing block holds the actual strings associated with the class. Everything arrive at the destination packaged, like subroutine call arguments.

Other method of extension includ encapsulation of proprietary triple, so simple redefine the basic triple with more columns:

Subject, Object, Link,Pointer

Then use the engine as is, there really are no places where the engine really need anything but the operators and pointer, except in the 35 lines of match. So the continer model really holds in this case.

No comments: