(The following is a broad overview of a system I am developing; I think it
is right exactly up the alley of REST, though it proposes to transcend some
parts of the REST architectural setup, without violating its motivations.
Two brief "appendices" quickly describe the relationship between this model
and RDF, and REST. -- Seth Johnson)
Context Transfer Protocol
The context transfer protocol (CTP) 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, CTP 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, updating and maintenance, manipulation, querying,
categorizing, distribution and dependency tracking. In this way, CTP
implements the notion of an atomic application. Fundamental information
processing functions for any application can be implemented simply by
declaring a CTP context, or by declaring multiple contexts to be combined in
a complex application. Any CTP front end interface that surfaces the full
complement of CTP functionality can be used to browse and work with any
information for any other application served by a CTP server.
CTP 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. CTP 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 CTP 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, CTP 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 CTP layer.
Instead of working with information through the representation of diverse
entities in separate physical tables, the CTP physical data model is a
generalized and denormalized structure that directly represents relations as
such. Relations implemented under CTP are called contexts. CTP 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. CTP assigns unique key
values to each element, made up of a URL (designating the location of a CTP
server), a forward slash, and a key value unique to that server. For
example: ctphome.org/18273645.
A general context in CTP 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” side).
In CTP, 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 CTP 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 CTP
servers participate and interoperate as they support shared contexts.
Location represents an individual CTP 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 CTP, and would require ratification as standards by
external standards bodies, followed by general adoption in code and
practice. With CTP, 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, CTP provides for universal interoperability at the data
transport level.
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 CTP,
distribution of attributes and their values is not accomplished in the same
manner. CTP uses the UCF to distribute metadata describing the relational
organization of information across servers, while it leaves particular
attribute values at particular locations, where CTP servers act as their
authoritative hosts. User agents and interoperating CTP 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, CTP 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. CTP servers provide and maintain
appropriate attributes and values for various contexts according to these
scopes of relevance.
CTP contexts do not presuppose or require locking mechanisms, since whenever
user agents request an occasion to modify a context, CTP servers notify them
whether the context has been modified in whole or in part since the time of
the user agent's local copy. CTP 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 CTP layer, for contexts for which that is desired.
Message structure
- requests, responses, occasions, events
State distribution system
- metadata, attributes, values, hosts
Data structure
- denormalized
Errors / Responses
Appendix A: CTP and RDF
The correlates for RDF's subjects, predicates, and objects under CTP are
uses, link types, and links.
CTP/Use - Rdf Subject
CTP/Link Type - Rdf Predicate
CTP/Link - Rdf Object
CTP 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 CTP 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: CTP 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 CTP'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 CTP.
--
DRM is Theft! We are the Stakeholders!
New Yorkers for Fair Use
http://www.nyfairuse.org
[CC] Counter-copyright:
http://realmeasures.dyndns.org/cc
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.