RE: [ALL] RDF/A Primer Version

Pat Hayes said:

<quote>
[4] has a clear and explicit description (at
http://www.w3.org/TR/webarch/#indirect-identification
) of a condition which seems to apply almost
perfectly to the situation which arises in RDF/A
and which Alistair deplores, and which is
correctly described as not constituting a URI
collision. Using the same name to refer both to a
thing, and to a piece of a document which itself
refers to the same thing, seems clearly to be an
example of indirect reference. As [4] says,
somewhat pithily," Identifiers are commonly used
in this way."
</quote>

I understood [4] to be referring to 'indirect identification' as expressed in RDF via properties of type owl:InverseFunctionalProperty. I.e. the following triple:

_:aaa foaf:homepage <http://jo-lamda.blogspot.com/>.

... uses the URI <http://jo-lamda.blogspot.com/> to 'indirectly identify' the blank node _:aaa because the property foaf:homepage is declared by the FOAF ontology [1] to be an inverse functional property.

If this is indeed the intended meaning of 'indirect identification' at [4] then I strongly suggest the RDF/A primer does NOT use the term 'indirect identification' to refer to the practice of using URIs to denote both a piece of XML (effectively a part of a document) and an entity in the 'real world' (e.g. a person).

See also related email [2].

Pat Hayes said:

<quote>
It is impossible, both practically and
theoretically, to completely avoid all ambiguity
in using referential names. Reference is not
access. While URLs must be unambiguous locators,
in the sense of resolving unambiguously to a
particular Web resource, referential names -
which is how URI references are used in RDF -
cannot possibly be specified so exactly as to
refer uniquely and unambiguously in all
circumstances. Even globally recognizable proper
names like "Mount Everest" do not have unique
referents in all possible circumstances, since
the exact referent depends on the ontological
framework being mutually assumed (Where is the
exact edge of a mountain? Are we talking about
people as agents or as medical cases? At a
particular time or as endurants? etc..) Under
these circumstances, to view every referential
ambiguity as a Bad Thing is about as useful as
trying to stamp out breathing.

Like words in human language, URIs can be safely
overloaded under conditions which allow possible
misunderstandings to be securely resolved by
their local context, without requiring
negotiation: and this need not even require that
the resolution be actually done, provided that
the necessary context - which is the case under
discussion, is likely to be the ontology
identified by the root URI of the RDF property -
can be accessed when required. In English we
safely use "bank" to refer to a side of a river,
a turning motion or a building, in part because
these meanings are so divergent that the
ambiguity can almost always be immediately
resolved by the immediate context. Similarly, an
email address can be safely used to refer to its
owner in part because almost anything that can be
coherently said about a person could not possibly
apply to an email account, and vice versa. Even
the use of a literal string in a context which
requires a reference to a named agent can be
interpreted as making sense, since it clearly
requires a coercion, and it would be natural to
use the string as a referring name. Whether or
not this is in some fundamental sense 'correct'
or 'proper' is not worth discussing: what matters
is only that a community of agents all agree to
use the same kind of coercion strategy when it is
required, which allows strings to be used to
refer to agents; and to the extent they do, then
they thereby become genuinely referring names.
This is how the world comes to use language, both
in the large and in the small
(http://www.economist.com/science/displayStory.cfm?story_id=5135495).
</quote>

OK. Tell me what 'local context' is exactly. How do I as a publisher ensure that sufficient 'context' is available for the applications I intend to support? What about unforeseen applications? As a consuming application, how do I get at the 'context', and how do I use it to resolve ambiguities? Where are these issues addressed in current specifications?

Surely it is good practice for publishers to clearly understand how and when ambiguities can arise, to be aware of each and every action that could lead ambiguity, and to undertake such actions in full knowledge of the consequences. Surely it is also good practice for publishers in the majority of cases to design systems that do not lead to ambiguity, or that minimise the potential for ambiguity, because in doing so they simpify the management of change, and increase the ease with which their data can be repurposed in unforseen contexts? I.e. by acting to minimise the potential for ambiguity, a publisher increases the value of its published data, because the data is more portable.

A practical question: If I operate under the assumption that the same URI will commonly be used to denote both a person and their home page, doesn't this make the notion of logical consistency effectively useless? Don't domains and ranges become effectively useless also?

E.g. if I have:

<http://jo-lamda.blogspot.com/> foaf:mbox <mailto:jo.lambda@example.org>.

... and I also have:

_:aaa foaf:homepage <http://jo-lamda.blogspot.com/>.

... then via the domain of foaf:mbox and the range of foaf:homepage I may conclude:

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

What is the usefulness of this new information?

Cheers,

Al.

[1] http://xmlns.com/foaf/0.1/ 
[2] http://lists.w3.org/Archives/Public/public-swbp-wg/2006Jan/0145.html 
[4] http://www.w3.org/TR/webarch/#indirect-identification 


-----Original Message-----
From: public-rdf-in-xhtml-tf-request@w3.org on behalf of Pat Hayes
Sent: Wed 25/01/2006 05:30
To: Booth, David (HP Software - Boston)
Cc: Ben Adida; SWBPD list; public-rdf-in-xhtml task force
Subject: RE: [ALL] RDF/A Primer Version
 

>I hate to say this, but I think the URI identity issues that Alistair
>raised in email[3] after yesterday's teleconference are important enough
>to delay publication until they are either fixed or visibly marked as
>problems.  The WebArch document is clear that URI collisions[4] are A
>Bad Thing.  It would seem wrong to endorse such collisions, even
>implicitly.

I beg to differ.

[4] has a clear and explicit description (at 
http://www.w3.org/TR/webarch/#indirect-identification 
) of a condition which seems to apply almost 
perfectly to the situation which arises in RDF/A 
and which Alistair deplores, and which is 
correctly described as not constituting a URI 
collision. Using the same name to refer both to a 
thing, and to a piece of a document which itself 
refers to the same thing, seems clearly to be an 
example of indirect reference. As [4] says, 
somewhat pithily," Identifiers are commonly used 
in this way."

It is impossible, both practically and 
theoretically, to completely avoid all ambiguity 
in using referential names. Reference is not 
access. While URLs must be unambiguous locators, 
in the sense of resolving unambiguously to a 
particular Web resource, referential names - 
which is how URI references are used in RDF - 
cannot possibly be specified so exactly as to 
refer uniquely and unambiguously in all 
circumstances. Even globally recognizable proper 
names like "Mount Everest" do not have unique 
referents in all possible circumstances, since 
the exact referent depends on the ontological 
framework being mutually assumed (Where is the 
exact edge of a mountain? Are we talking about 
people as agents or as medical cases? At a 
particular time or as endurants? etc..) Under 
these circumstances, to view every referential 
ambiguity as a Bad Thing is about as useful as 
trying to stamp out breathing.

Like words in human language, URIs can be safely 
overloaded under conditions which allow possible 
misunderstandings to be securely resolved by 
their local context, without requiring 
negotiation: and this need not even require that 
the resolution be actually done, provided that 
the necessary context - which is the case under 
discussion, is likely to be the ontology 
identified by the root URI of the RDF property - 
can be accessed when required. In English we 
safely use "bank" to refer to a side of a river, 
a turning motion or a building, in part because 
these meanings are so divergent that the 
ambiguity can almost always be immediately 
resolved by the immediate context. Similarly, an 
email address can be safely used to refer to its 
owner in part because almost anything that can be 
coherently said about a person could not possibly 
apply to an email account, and vice versa. Even 
the use of a literal string in a context which 
requires a reference to a named agent can be 
interpreted as making sense, since it clearly 
requires a coercion, and it would be natural to 
use the string as a referring name. Whether or 
not this is in some fundamental sense 'correct' 
or 'proper' is not worth discussing: what matters 
is only that a community of agents all agree to 
use the same kind of coercion strategy when it is 
required, which allows strings to be used to 
refer to agents; and to the extent they do, then 
they thereby become genuinely referring names. 
This is how the world comes to use language, both 
in the large and in the small 
(http://www.economist.com/science/displayStory.cfm?story_id=5135495).

I suggest that if current real-world usage of a 
metadata vocabulary seems to be causing no actual 
operational problems, it might be better to study 
this real-world usage carefully with a view to 
learning something about how symbols actually are 
being used on the Web, than to set out to take 
great pains to improve it.

In the meantime, I also suggest that RDF/A might 
usefully use the term "indirect identification" 
to point out that subjects of RDF triples can 
both be pieces of XML markup and also refer to 
entities in the real world, and that this need 
not be deplored as harmful ambiguity.

Pat Hayes

>David Booth
>
>[3] Identity issues raised by Alistair:
>http://lists.w3.org/Archives/Public/public-swbp-wg/2006Jan/0113.html
>[4] TAG's Web Architecture:
>http://www.w3.org/TR/webarch/#URI-collision
>
>
>>  -----Original Message-----
>>  From: public-swbp-wg-request@w3.org
>>  [mailto:public-swbp-wg-request@w3.org] On Behalf Of Ben Adida
>>  Sent: Tuesday, January 24, 2006 12:03 PM
>>  To: SWBPD list
>>  Cc: public-rdf-in-xhtml task force
>>  Subject: [ALL] RDF/A Primer Version
>>
>>
>>
>>
>>  Hi all,
>>
>>  I made a mistake in the version of the RDF/A Primer that I presented 
>>  at the telecon yesterday. I have just finished uploading the right 
>>  version, which you can find here:
>>
>>  http://www.w3.org/2001/sw/BestPractices/HTML/2006-01-24-rdfa-primer
>>
>>  With the WG and specifically the reviewers' approval (DBooth,
>>  GaryNg, 
>>  and also "unofficial" reviewers), I am hoping that we can rapidly 
>>  agree that this latest version should be the one that becomes our 
>>  first published WD.
>>
>>  The only difference in content is that the new version has an extra 
>>  section (section #2), and the old sections 2 and 3 are merged into 
>>  the new section 3 for purely organizational purposes (no text
>>  is lost 
>>  or added in those sections, just reorganized.) The point of the new 
>>  section 2 is to add an even simpler introductory example. We believe 
>>  this additional section is in line with the comments we
>>  received from 
>>  reviewers, both official and earlier, unofficial reviews. In
>>  fact, we 
>>  began writing it in part to respond to some of these early
>>  comments 2 
>>  weeks ago.
>>
>>  The already-approved version is still at the old URL for
>>  comparison:
>>  http://www.w3.org/2001/sw/BestPractices/HTML/2006-01-15-rdfa-primer
>>
>>  I want to stress that this is entirely *my* mistake: the TF had 
>>  agreed [1,2] that this second version would be presented to the WG
>  > yesterday, and I simply forgot. Publishing these additional examples
>  > now is quite important for getting the word out about RDF/A and
>  > making it competitive against other metadata inclusion proposals, 
>>  outside of W3C, that are gaining traction.
>>
>>  Apologies for my mistake. I hope you'll see that these edits do not 
>>  constitute a substantive change to the document, rather they help 
>>  make the same points more appealing to and understandable by
>>  a larger 
>>  audience.
>>
>>  -Ben Adida
>>  ben@mit.edu
>>
>>  [1] Discussion during last segment of January 10th TF
>>  telecon: http://www.w3.org/2006/01/10-swbp-minutes
>>
>>  [2] Discussion, at beginning, of Mark's new examples during January 
>>  17th TF telecon:
>>  http://www.w3.org/2006/01/17-swbp-minutes
>>
>>


-- 
---------------------------------------------------------------------
IHMC		(850)434 8903 or (650)494 3973   home
40 South Alcaniz St.	(850)202 4416   office
Pensacola			(850)202 4440   fax
FL 32502			(850)291 0667    cell
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes

Received on Wednesday, 25 January 2006 19:31:11 UTC