[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Uniform Context Transfer Protocol?

• To: mc@x..., xml-dev@l...
• Subject: Uniform Context Transfer Protocol?
• From: "Seth Johnson" <seth.johnson@r...>
• Date: Sat, 31 Jan 2004 19:00:09 -0500

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. 

• Prev by Date: RE: best practice for providing newsfeeds ?
• Next by Date: Re: Schema fragments for everyday stuff
• Previous by thread: SIRs should be filed for many concepts.... (was Re: Patents, schmatents (was: hi))
• Index(es):
  • Date
  • Thread