Loading...
 
(Cached)
Refresh Print

Better URI Axioms

Jeff Bone at RESTwiki? authored an article on(external link) Better URI Axioms in 2002 to reflect REpresentational State Transfer wisdom arising long after the W3 ontology was set into stone.

All of these axioms are reflected or guaranteed in living ontology and Living Ontology Web. The following contrasts Bone's abstraction and Hubley's implementation and detailed definition as reflected in those artifacts:



lexical equivalence?

"It should be possible to determine the equivalence of any two URI which refer to the same resource by a simple, lexical test. Lexical equivalence guarantees equivalence." - Jeff Bone

"Living Ontology Web absolutely requires that a common suffix? and prefix implies that the same resource is being described. For instance a number of names ending in ", 2006" such as GPC platform, 2006 and Canadian federal election, 2006 imply that they are both the year 2006? and not something else and that can be inferred simply by lexical identity. Also a number of names starting with GPC or with Canadian? imply that this means one exact thing. The very strongest such implications are namespaces, e.g. term:namespace, news:namespaces, in which it is the point of view on the resource that is changing." - Craig Hubley

canonical name?s

"Whenever possible, a single logical resource should have a single, canonical name. Lexical non-equivalence strongly implies non-equivalence." - Jeff Bone

"In living ontology there are for instance common time/place/person? strings that are absolutely and lexically identical. The GFDL corpus namespace conventions are followed absolutely. For instance, User:Craig_Hubley is the same on any Living Ontology Web service, and while the string Craig_Hubley is guaranteed to refer to that person, the string Craig Hubley is not, though in theory it could be (with a stronger lexical test that allows for variant use of underscore, plus sign, soft space? and hard space? in name?s)." - Craig Hubley

namespace abstraction?

"The namespace should be a structured view of the information space, not a view of the structure of the information space." - Jeff Bone

"A living ontology namespace clearly separates all views of the structure using predictable conventions ("all", "list of", "by") to easily create flexible category and weak ontology on demand. These absolutely do not constrain the information as formal category schemes in tikiwiki do. There is no attempt whatsoever to make editorial judgements by naming, only advice to "ignore" a page. If there is a strong ontology evolving it can evolve with little or no interference from views of the structure or editorial decisions specific to a particular web service. Most importantly, axiom?s about open politics itself are very clearly separated from any statements about politics itself (the issue ) or openpolitics.ca itself (an argument or demonstration thereof). Thus issue/position/argument separation is followed even at reflexive levels of description, which is perfectly reflexive abstraction if this separation is part of the definition of open politics itself, as it is." - Craig Hubley

structural form?

"Whenever possible, the canonical name of a resource should use a structural form and should avoid the use of query strings. Query strings impair the correct and efficient operation of such things as Web crawlers, proxies, and software that attempts to exploit the hyperstructure of the Web." - Jeff Bone

"Living Ontology Web deprecate?s query string?s such as "tiki-index.php?page=" or "/index.php/" and requires they not appear in any URIs at all even on rewrite. Good wiki farm?s like wikidev.net? or even marginal ones like seedwiki do the same." - Craig Hubley

meaningful path?

"Whenever practical, namespace designers are encouraged to respect the intuitive meaning of the path part of URI when this is used. That is, they are encouraged to treat .../a/b as an implication that .../a/ is a resource. They are, however, under no obligation to do so. Conversely..." - Jeff Bone

"The only intuitive meaning of any noun in any URI is that defined in the GFDL corpus namespace. That is widely translated and permanently available due to being open content. There is no alternative. The only intuitive meaning of any verb in any URI is that defined in HTTP which necessarily interprets at least the HTTP methods themselves. There is again no alternative. As new methods becoming recognized - typically chosen from a list of all control verbs - make their way visibly into URIs, then they may be assumed to constrain presentations and resources, e.g. "/edit/" meaning those that enable editing a page, or "/infra/" meaning those that describe configuration of infrastructural capital." - Craig Hubley

generic opacity?

"In the absence of explicit instructions on how to do otherwise, consumers of URI and namespaces should treat (the path part of) URI as opaque. However, given explicit instructions on the structure and semantics of any or all parts of some URI in some namespace, it is perfectly acceptable to construct or deconstruct URI or their components according to those instructions. This capability should be used sparingly and carefully." - Jeff Bone, who also states that "private, prose agreements are in general inferior to standards-based, machine-readable, public agreements, and there are as yet no standards-based, public ways of saying that it is acceptable to construct a URI except in the context of relative URI application or query string."

"To construct or deconstruct any Living Ontology Web URI requires nothing but a list of all control verb?s and all human command verbs so as to clearly identify when unambiguous instructions to machines, or instructions to humans, are involved. Thus there can be no confusion about what inevitably affects a living body versus what inevitably doesn't. For instance, "to fax" something does not imply any particular body impact, while "to hang" someone does. What remains after those inevitabilities are filtered out, are ambiguous instructions to machines that must have some semantics attached in each context by programmers etc., which may or may not affect living bodies. Limiting such filters, sparingly and carefully, minimizes the use of "private, prose agreements" which are inevitable in human affairs by ensuring that anything which can be "standards-based, machine-readable" without risk to bodies, actually is. In time all these must be "standards-based" "public agreements", that is, "public ways of saying that it is acceptable to construct a URI" that is meaningful for all civic best practice users, anywhere, at least following standards set by Efficient Civics Guild." - Craig Hubley

Bone also states a final non-axiom preference:

hypermedia preference?

"The Web prefers hypermedia. Information owners are encouraged to provide hypermedia interfaces to their objects and information spaces whenever practical." - Jeff Bone

"In practice, this means that HTTP cannot remain the only or even dominant REST protocol?, but that a separate infra protocol? must evolve to assess a terminal?'s capabilities, especially when worn devices are considered. This can be done with HTTP but only with quite high overhead that's undesirable. With the capabilities of the terminal known, another ultra protocol? would be required to deal with the licensing, payment, authentication, privacy and non-technical issues regarding access. Only with both of those clearances could a hypermedia interface to an arbitrary object on an arbitrary terminal be reliable and therefore lead to a stable and memorable URI anyone could rely on, which are the only ones that can be practical" - Craig Hubley.




Show php error messages