[
Lists Home |
Date Index |
Thread Index
]
Context Transfer Protocol (Uniform 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 - [RdfSubject]
CTP/Link Type - [RdfPredicate]
CTP/Link - [RdfObject]
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.
|
