In How do you identify things I gave one option as:
1. Use "clever semantics".Semantic Web tools and Classic Web tools (browsers) can simply use different interpretations when they see a URI. Browsers will try to fetch you up some web page. Semantic Web tools know only that you are talking about some object in some unspecified domain of discourse, where the URI-to-object mapping is many-to-one (no two distinct objects share the same URI). That is, semantic web tools in general treat the URI as an opaque object that can only be compared to another one. Certain tools may understand a vocabulary (eg theThingDescribedByTheText) for relating the two uses, and they can perhaps open the opaque identifier. But you might very easily make a mistake and end up equating W3C with its web page.
With this approach, URIs are used as identifiers only for two reasons: (1) we get a nice rule for coining new identifiers (only the authority which is allowed to publish the resource with that URI can coin the identifier), and (2) browsers can do something interesting with them.
I was fogging up two different issues and hardly doing them justice.
People normally think of RDF predicates as expressing a relationship between the thing denoted by the text of the "about" attribute and the thing denoted by the text of the "resource" attribute. (Let's ignore literals for now.) The predicate is not thought to relate to the identifier text itself.
But does it have to be that way? No. That behavior can be considered part of the definition of each particular predicate. This allows us to define a predicate for identifying "anonymous" resources like (in n3):
<#anon752> id:scope id:local
and, if I understand them correctly, is essential to the correct
interpretation of n3's log:forAll and log:forSome.
This expanded realm of interpretation also helps clarify the status of literals in the system. Still, if reification scares you, this will too!
The issue comes up in most languages in some form. In C, the text of identifiers is kept in debugging (and sometimes linking) information in the object code, but it's almost unheard-of for a program to look at it. Interpreted languages have some more flexibility. In LISP, "quote" and related functions like "setq" are allowed access to identifier text (as I undrestand it).
This is not as crazy as it sounds. At the core of "hash versus slash" debate is the question about why someone people don't like "http://purl.org/dc/elements/1.0/creator" as a name for a property. Yes, it's probably a web page, but why can't it be an predicate at the same time?
I think the answer is it can. For a predicate it's just like having two functions by the same name (and in the same scope) which are disambiguated by their type signatures or For a subject/object, it's like implementing multiple interfaces, which works as long as the interface element names are different.
Perhaps the proper test is whether one can mechanically translate a conflated situation into a traditional disjoint one. In C++, the ambiguous function names are "mangled" into unamgiguous names for the old C linker. In multiple inheritence, the function names are translated into vtable indexes.
For the semantic web, the test is probably to try writing rules for transforming a set of assertions using overloaded identifiers into an equivalent set which does not. My guess is this will not be a problem, because it's very unlikely the type-signatures or interface-element names will conflict, since they are given globally unique identifiers. (or mostly unique, except for the conflation we're untangling here.)
Sandro Hawke
$Date: 2001/03/23 19:17:21 $