[e2e] Uniform Context Transfer Protocol?

[Seth Johnson]

See if this makes sense.  I've mulled this over a good while, don't know how
well it qualifies for e2e-tivity.  It's spoken of in terms borrowed from
application level protocols (the two appendices here allude to this context
in which I began thinking about this), but I have always felt it would be
good if it were just an extension to TCP, and not an XML-kinda thing, or XML
replacement.  It would make XML irrelevant, anyway -- actually, since it's
designed so all applications are inherently interoperable, and new
applications are just freely devised conventions that people share,
understanding of the "applications layer" would change a good bit.  It's a
"data transport layer" that sits above TCP/IP.  If it's out of sorts here, I
apologize; a recent post or two prompted me to present it for
consideration.  -- Seth Johnson


Uniform Context Transfer Protocol?

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, updating and maintenance,  manipulation, querying,
categorizing, hierarchizing, 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
disôrébution anä/or òepliãation. Higher-levåì  tecèîiques for maîaginç
ãïípìexiôy, sõcè as såt-oriånted and object- oréentåd äátá ðrocesséng and
programmiîç, íáù bå émpìemeîted on top of  the UÃTP láyer® 
Š
Énstead of working with information through the representation of  diverse
entities in separate physical tables, the UCTP physical data  model is a
generalized and denoòmalized structure that directly  represents relations
as such. Relations implemented unäer UCTÐ are  calìed contexts. UCTP uses
the fïllowing 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: UCTPhome.org/18273645. 

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” side). 

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 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 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 

- 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.