This is one possible solution to the Semantic Web Identification Problem.
Guiding Principles:
Conclusions:
The fragment-identifier in a URI-References is a context-sensitive guide for client actions
HTTP URIs identify a particular kind of of TCP-based server process and implicitely the data they can transmit to a client
No current standards-track URI syntax can identify objects in arbitrary domains of discourse
Another syntax, disjoint from URIs is needed for giving global identifiers to arbitrary objects.
The design issues then are:
Which disjoint syntax?
How to make the names globally unique?
Issue | Proposed Solution | |
---|---|---|
Syntax | Disjoint 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. |
Issue | Proposed Solution | |
---|---|---|
Syntax | Disjoint 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 Category | Denotation |
---|---|
absoluteURI | identify resource |
./relativeURI | same, eg for files in same directory |
[time,authority,name] | identify anything (global skolem constant) |
word | identify 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 $