RE: [ALL] RDF/A Primer Version

Wow!  Like Alistair, I also read section 2.3.3 of the WebArch[4]
document as saying that the same URI should *not* be used for both Nadia
and her mailbox, in part because of the first sentence:
[[
To say that the URI "mailto:nadia@example.com" identifies both an
Internet mailbox and Nadia, the person, introduces a URI collision.
However, we can use the URI to indirectly identify Nadia. Identifiers
are commonly used in this way.
]]

It is interested to realize now how that same paragraph can be
interpreted so differently[7].  The difference of interpretation seems
to hinge on whether the "indirect" identification is explicit (thus
requiring an explicit inverse functional property between two different
RDF nodes) or implicit, depending on the context of the application
using it.

I admit that I find a lot of persuasiveness in your arguments, but I am
also struggling to understand how implicit indirect identification
should work.

If "indirect" identification is implicit, I see a few possibilities for
how this could happen, which I'll call: (1) the Shadow-Ontology
approach; (2) the Coercible-Triples approach; and (3) the Multiple-Sense
approach.

1. The Shadow-Ontology Approach.  Another approach is for the
application (and the ontology in which the relevant properties are
defined) to always use mailto:nadia@example.com as an indirect
identifier for Nadia the person, and never (or rarely) have a need for
relating its objects and properties to those that make use of other
characteristics of Nadia.  For example, we might have an iPreferences:
ontology with an iPreferences:likesToEat property with domain
foaf:Mailbox and range foaf:Document which is used to *indirectly*
indicate that Nadia likes apple pie:

	<mailto:nadia@example.com> 
		iPreferences:likesToEat
			<http://example.org/recipies/applePie> .

More precisely, it indicates that "The person whose mailbox is
nadia@example.com likes to eat the food created from the recipe at
http://example.org/recipies/applePie.")

Nadia's love of apple pie instead *could* have been directly expressed
using a parallel "shadow ontology" dPreferences:

	_:s1
		dPreferences:likesToEat
			foodOntology:applePie .

("Nadia likes apple pie", where _:s1 is a foaf:Person directly
identifying Nadia and foodOntology:applePie directly identifies the
concept of apple pie.)  Furthermore, the iPreferences: ontology could be
explicitly related to the dPreferences: shadow ontology if desired:

	_:s1 foaf:mbox <mailto:nadia@example.com> .

	foodOntology:applePie
		foodOntology:hasRecipeAt
			<http://example.org/recipies/applePie> .
	
	dPreferences:likesToEat
		foo:isShadowPropertyFor
			iPreferences:likesToEat

However, since the application may never have the need to deal with
foaf:Persons or the foodOntology: directly, there is no need for the
dPreferences: shadow ontology to even exist.  

The Shadow-Ontology approach to indirect identification is only indirect
in the sense that users may know that the real-world implication is that
"Nadia likes apple pie" even though the RDF statements deal only with
foaf:Mailboxes and foaf:Documents.  In fact it is *direct*
identification at the RDF level.

2. The Coercible-Triples Approach.  The application uses a coercion rule
to generate a foaf:Person bnode whenever it reads a triple that has an
email address where a foaf:Person was expected (assuming foaf:Persons
are not supposed to be email addresses).  This is *different* from
ambiguity or URI collision because a bnode is created by the coercion
rule.  The triple that is read is not asserted directly; instead,
coercion rules are applied to generate the triples that are asserted.
(I.e., the provenance of the "coercible triple" is used to determine
what triples to actually assert.)  For example, when

	<mailto:nadia@example.com> rdf:type foaf:Person .

is read, the reified version of the above might be asserted instead of
the above triple, and a coercion rule could then be applied to assert
something like:

	_:p1 rdf:type foaf:Person .
	_:p1 foaf:mbox <mailto:nadia@example.com> .

                                  ---------

However, it doesn't sound like either of the above approaches is quite
what you mean when you refer to "indirect identification" and say that
"a single URI can usefully play several referential roles at the same
time"[6].  Do you mean something like the following?

3. The Multiple-Sense Approach(?).  A URI may have multiple senses or
referents.  Ontological context[6] is used to know which sense of the
URI is intended.  For example, the same URI
http://jo-lamda.blogspot.com/ might in one case refer to a person's web
page (a foaf:Document), whereas in another case it might refer to the
person (a foaf:Person) described by that web page.  Thus when the
following are asserted:

	<http://jo-lamda.blogspot.com/> a foaf:Person, foaf:Document.

there is no contradiction even if foaf:Person is declared
owl:disjointWith foaf:Document because

	<http://jo-lamda.blogspot.com/> a foaf:Person . 

is implicitly talking about a different sense of the URI
http://jo-lamda.blogspot.com/ than

	<http://jo-lamda.blogspot.com/> a foaf:Document .

I.e., it is as if the following were instead asserted (perhaps via the
Coercible-Triples approach above):

	<http://jo-lamda.blogspot.com/#thePerson> a foaf:Person . 
	<http://jo-lamda.blogspot.com/#theDocument> a foaf:Document .

However, it *seems* like you may be saying[6] that the need to split
<http://jo-lamda.blogspot.com/> into
<http://jo-lamda.blogspot.com/#thePerson> and
<http://jo-lamda.blogspot.com/#theDocument> is not inherent, but depends
on the application.  Thus one should only make such distinctions when
they are necessary -- a sort of "lazy disambiguation" -- such as if you
have:

	<http://jo-lamda.blogspot.com/> a foaf:Person, foaf:Document.

*and* foaf:Person is declared owl:disjointWith foaf:Document.   Is this
what you mean?  If so, how should 

On the other hand, the TAG's httpRange-14 decision seems to imply that a
distinction between a web page ("information resource" in TAG jargon)
and something else should *always* be made.

References:
5. TAG's httpRange-14 decision:
http://lists.w3.org/Archives/Public/www-tag/2005Jun/0039.html

6. Pat Hayes on multiple referential roles of a URI:
http://lists.w3.org/Archives/Public/public-swbp-wg/2006Jan/0153.html

7. Pat Hayes on "indirect identification":
http://lists.w3.org/Archives/Public/public-swbp-wg/2006Jan/0139.html

David Booth

Received on Monday, 30 January 2006 18:11:24 UTC