Proposed Solution #29

This is one possible solution to the Semantic Web Identification Problem.

Guiding Principles:

  1. Treat current standards-track RFCs as strictly normative


  1. The fragment-identifier in a URI-References is a context-sensitive guide for client actions

  2. HTTP URIs identify a particular kind of of TCP-based server process and implicitely the data they can transmit to a client

  3. No current standards-track URI syntax can identify objects in arbitrary domains of discourse

  4. Another syntax, disjoint from URIs is needed for giving global identifiers to arbitrary objects.

The design issues then are:

  1. Which disjoint syntax?

    1. Disjoint from AbsoluteURI, RelativeURI, and/or URI-Reference?
    2. Allow use of non-URI characters (like quote, space, and angle-brackets)? Allow used of URI not-recommended characters (like curly and square brackets)?
    3. Give space in the syntax for local-scope, nested-scope, and/or relative identifiers?
  2. How to make the names globally unique?

Detailed Proposal 29a

IssueProposed Solution
SyntaxDisjoint From all URI syntaxes
Character Set Angle brackets like "<" non-resource-identifier ">" sets text apart from all URIs; suggest a different level of semantics, as in BNF
Scoping Within the brackets, commas delimit parts of a tuple; singletons are locally scoped
Global Uniqueness <foo,uuid> or <foo,date,email-or-domain-name> both allowed. Some room to add new approaches.

Detailed Proposal 29b

IssueProposed Solution
SyntaxDisjoint From all URI syntaxes except that relativeURI must be specified as ./foo
Character Set see below
Scoping many options
Global Uniqueness Time-Authority-Name and UUID both provided here, too.
Syntactic CategoryDenotation
absoluteURI identify resource
./relativeURI same, eg for files in same directory
[time,authority,name] identify anything (global skolem constant)
wordidentify anything (local skolem constant)
<word> local existential variable
<[time,authority]word> global existential variable


In this direction, you could go some interesting places, but maybe you shouldn't. Specifically, 29b is moving towards having the syntax encode information perhaps better left in specific assertions, albeit assertions about the text of identifiers.

Also, the guiding principle may well be flawed.

Sandro Hawke
$Date: 2001/03/23 19:17:21 $