Re: Sesame vs. Jena?

From: Seth Johnson <>
Date: Sat, 01 Oct 2005 01:00:37 -0400

Shashi Kant wrote:
> This question got me thinking as to why one need either Jena or Sesame in a
> SemWeb world. They are after all a frameworks for working with RDF data. Is
> there another way to achieve what Jena or Sesame do without the overheads?
> Has anyone looked at the possibility of using an Object oriented databases
> or ORMS (Object-Relational Mapping) which would presumably remove the need
> for parsers and RDF querying mechanisms. The data are persisted in the form
> of graphs natively, therefore querying would be like querying an Object
> array from the language of your choice (Java, C#,..).
> I guess, my question is, is there a way of working with RDF data without
> using either Sesame or Jena?
> (note: I am assuming reasoning is something that can be plugged into an OODB
> just as you can with Jena/Sesame)

Just to step in momentarily with a little peep that's related to

I have worked out details of a "Uniform Context Transfer
Protocol" which is meant to reside above the transport layer and
below the applications layer.

What it is, is a set of conventions based on generalizing the
notion of relations, creating standard functionality that is
available as part of the communications infrastructure, simply by
declaring a "context" -- the term I use for the more generalized
notion of a relation among entities.

I actually generalize to the extent that I don't believe the
rationales for XML itself are relevant -- what happens with the
UCTP, is all applications are inherently interoperable, and RDF
propositions are just a special case of a context.

Interoperating UCTP servers provide "all the fundamental
operations one needs for managing information, including
modeling, outlining, manipulation, updating and maintenance,
querying, categorizing, distribution and dependency tracking."

Below is something I started writing to describe it.

Seth Johnson

Uniform Context Transfer Protocol

General Overview

The uniform context transfer protocol (UCTP) is an end-to-end
data transport protocol that supports manipulable distributed
hypermedia and data processing on the basis of the concept of
universal state transfer. It employs a set of abstract terms
that designate the elements of a uniform structure for
representing and transferring state, called the uniform context
framework (UCF).

In place of documents and files, UCTP implements contexts,
manipulable collections of resource elements which are referred
to according to the UCF abstractions. All of the elements of a
context are assigned key values which function as links to the
servers at which the elements originate. Because all elements
are links, multiple contexts may freely reuse the same elements.

The elements of the UCF reflect a universal information
architecture which supports all the fundamental operations one
needs for managing information, including modeling, outlining,
manipulation, updating and maintenance, querying, categorizing,
distribution and dependency tracking. In this way, UCTP
implements the notion of an atomic application. Fundamental
information processing functions for any application can be
implemented simply by declaring a UCTP context, or by declaring
multiple contexts to be combined in a complex application. Any
UCTP front end interface that surfaces the full complement of
UCTP functionality can be used to browse and work with any
information for any other application served by a UCTP server.

UCTP is designed for scalability, providing a simple uniform
interface through the use of a small set of verbs (GET, PUT,
REMOVE and HOST) and the finite set of generic elements which
make up the UCF. UCTP servers attain the status of universal
application servers in the sense that all fundamental information
management functions are provided by means of this interface and
the rest of the functions and architecture incorporated within
the protocol.

The information architecture underlying UCTP affords a maximum
degree of flexibility in data processing. Entity relationships
for all applications are stored in a flat fact table form,
allowing information to be accessed and worked with rapidly,
flexibly and with implicit interoperability among all
applications. In addition, by using the UCF abstractions as
generic primitives, UCTP makes possible a highly granular
procedural approach to data processing that is unimpeded by the
intricacies of entity-relationship models or the strictures of
table- or record-level distribution and/or replication.
Higher-level techniques for managing complexity, such as
set-oriented and object-oriented data processing and programming,
may be implemented on top of the UCTP layer.

Uniform Context Framework

Instead of working with information through the representation of
diverse entities in separate physical tables, the UCTP physical
data model is a generalized and denormalized structure that
directly represents relations as such. Relations implemented
under UCTP are called contexts. UCTP uses the following generic
abstractions to represent the elements of any context:

 * Space
 * Location
 * Standpoint
 * Use Type
 * Use
 * Link Type
 * Link
 * Use Attribute
 * Link Attribute
 * Use Attribute Value
 * Link Attribute Value
 * Use Category
 * Link Category
 * Use Category Value
 * Link Category Value

These elements make up the uniform context framework (UCF), a
standard structure for representing and transferring state. UCTP
assigns unique key values to each element, made up of a URL
(designating the location of a UCTP server), a forward slash, and
a key value unique to that server. For example:

Contexts and Context Instances

A general context in UCTP is comprised of a use type related to a
link type. A particular context instance is designated by a
particular use of the use type, which can have any number of
links, particular instances of the link type, related to it.
This combination of use types, link types, uses, and links
describes a traditional one-to-many relationship, wherein the
various uses of a use type serve as “records” of the parent
entity type (on the “one” side), and the multiple links of a link
type serve as “records” of the child entity type (on the “many”

State: Scope of Generality

In UCTP, state is an aspect of contexts representing their
generality, and is designated in terms of the concepts of space,
location, and standpoint. Declaring a state for a UCTP context
means that the context serves as a convention among all clients
and servers that participate in that state. Space represents the
notion of an abstract realm within which numerous UCTP servers
participate and interoperate as they support shared contexts.
Location represents an individual UCTP server. Standpoint is an
abstraction used to represent states of narrow scope hosted at
particular locations, for the purpose of independent or
provisional development work.

Generality of a state is designated by either providing key
values for space, location and/or standpoint, or leaving their
key values empty. A state representing generality across an
entire space is represented by providing a unique key value for
the space, while leaving the location and standpoint keys empty.

A state for representing universal conventions would be
designated by leaving all three key values empty. However, since
this designates no authoritative server for the state, contexts
defined within such a state cannot be managed by UCTP, and would
require ratification as standards by external standards bodies,
followed by general adoption in code and practice. With UCTP,
this process of fostering general adoption by means of standards
bodies becomes significantly less necessary. Instead of
presupposing that state and physical data models are so
arbitrarily complex and diverse as to necessitate such a process
in order to assure interoperability, UCTP provides for universal
interoperability at a "data transport level" located directly
above the transport layer and below the applications layer.

Data Distribution

Traditional entity-relationship modeling entails record- and
table-level replication in distributed environments because it
binds sets of attributes to individual physical tables
representing discrete entities. Under UCTP, distribution of
attributes and their values is not accomplished in the same
manner. UCTP uses the UCF to distribute metadata describing the
relational organization of information across servers, while it
leaves particular attribute values at particular locations, where
UCTP servers act as their authoritative hosts. User agents and
interoperating UCTP servers may maintain the currency of their
local caches of attribute values according to any algorithm
appropriate to their own purposes.

Instead of binding sets of attributes to particular tables
representing particular entities, UCTP uses the abstractions that
make up the UCF to describe scopes of relevance for link and use
attributes. Attributes can be declared to be relevant for all
links of a particular link type, or for all links used by a
particular use type, or for all instances of a particular use or
link regardless of general context (use type and/or link type),
or for any other of the finite number of scopes that can be
described by the possible permutations of the UCF elements. UCTP
servers provide and maintain appropriate attributes and values
for various contexts according to these scopes of relevance.


UCTP contexts do not presuppose or require locking mechanisms,
since whenever user agents request an occasion to modify a
context, UCTP servers notify them whether the context has been
modified in whole or in part since the time of the user agent's
local copy. UCTP servers may implement shared contexts as freely
interruptible or as "reservable" according to diverse governing
principles. Separate protocols may implement locking or other
"reservation" schemes on top of the UCTP layer, for contexts for
which that is desired.

Message structure and processing
        - requests, responses, occasions, events

State distribution system
        - metadata, attributes, values, hosts

Data structure
        - denormalized

Errors / Responses

Appendix A: UCTP and RDF

The correlates for RDF's subjects, predicates, and objects under
UCTP are uses, link types, and links.

UCTP/Use - RDF Subject
UCTP/Link Type - RDF Predicate
UCTP/Link - RDF Object

UCTP moves beyond RDF's knowledge-modeling assertions by
splitting subjects into use types and uses, and then using the
combination of use types with link types to define atomic
applications, contexts which automatically provide all
fundamental information functions needed to manage information
for any application. Because UCTP is designed in this manner, it
is perfectly suited for RDF applications. It simply goes beyond
the knowledge-modeling purposes of RDF and the semantic web, to
providing universal fundamental functions and implicit
interoperability among all applications.

Appendix B: UCTP and REST

Roy Fielding has articulated a comprehensive set of engineering
principles which constitute an architectural style called
"representational state transfer" (REST) intended to govern
optimal Web architecture and Web application design. By
describing how UCTP's implementation of universal state transfer
compares with the architectural principles of REST, we can
address its design implications in an orderly and reasonably
complete manner. The chief differences stem from the fact that
past architectural principles have presupposed the arbitrary
complexity of state and data models, and therefore have taken
certain design decisions geared toward managing complexity, which
are unnecessary within UCTP.

RIAA is the RISK!  Our NET is P2P!
DRM is Theft!  We are the Stakeholders!
New Yorkers for Fair Use
[CC] Counter-copyright:
I reserve no rights restricting copying, modification or
distribution of this incidentally recorded communication. 
Original authorship should be attributed reasonably, but only so
far as such an expectation might hold for usual practice in
ordinary social discourse to which one holds no claim of
exclusive rights.
Received on Sat Oct 01 2005 - 04:56:39 EDT

This archive was generated by hypermail 2.3.0 : Thu Aug 09 2012 - 16:39:18 EDT