RE: [ALL] RDF/A Primer Version

Alistair, Pat

I share completely Pat's views, but I share Alistair's interrogations about them (a
consensual starting if any ...). Since those things have been at the heart of some current
ruminations, I'll drop a few lines about it here.

Indirect identification in [4], is followed by section 2.3 "URI comparisons" ...
http://www.w3.org/TR/webarch/#identifiers-comparison
... starting this way: "URIs that are identical, character-by-character, refer to the same
resource."

But previous section clearly states that the same URI can refer "indirectly" to different
things in different (so-called local) processing contexts. So maybe this sentence should
read more exactly :

"URIs that are identical, character-by-character, refer to the same resource in the same
processing context."

We tend to focus on the most frequent processing context, the Web client-server
interaction which aims to retrieve a representation of the resource. But, Alistair, all
the VM cookbook shows clearly that the representation that you retrieve in this specific
processing context (http GET) depends on devilish details of both client and server
configuration, so even in this case where the resource is supposed to be "directly"
referenced, actually the referent is not uniquely defined by the URI. IOW, there is no
such thing as "direct identification" by URIs. The referent, even in http GET context, is
neither the stream of bytes you get, nor the result of this stream in your browser, nor
... Exactly the same as for "Mount Everest" or "Alistair Miles", the referent is "neti,
neti" :)

Now if this URI is used to identify a owl:Class in some OWL ontology, it's clear that the
context includes the ontology, and any application in which this ontology is loaded
assumes the same referent (whatever that is). So the processing context there might be an
ontology editor, a reasoner, or whatever tool has implemented the semantics of owl:Class.

If we have failed so far to achieve effective definitions of same-ness in the semantic
technologies, it's because we fail to see that same-ness, or identification, is
context-bound. My mantra about that is "no identity, only identification process".

So the question is not to know if a given URI has a single, absolute, context-independent,
referent, or even less what this referent is or should be. Would be as insane as to want
to define what "Mount Everest" refers to, or is, or should be in an absolute way. Assuming
one can and should provide such definitions leads IMHO all semantic technologies into a
dead end. So what we badly need is both

1. Standard ways to define processing contexts, in which identical URIs identify the same
referent
2. Standard ways to declare that different URIs have the same referent, also
identification process might be different

I agree there with Alistair that the current RDF stack makes no provision for either of
those. I have made some very little steps and proposals towards the point 2. See [1] ...
still waiting for feedback from the community about them ...

Cheers

Bernard

[1] http://www.mondeca.com/lab/bernard/spek.rdf


> -----Message d'origine-----
> De : public-swbp-wg-request@w3.org
> [mailto:public-swbp-wg-request@w3.org]De la part de Miles, AJ (Alistair)
> Envoyé : mercredi 25 janvier 2006 20:31
> À : Pat Hayes; Booth, David (HP Software - Boston)
> Cc : Ben Adida; SWBPD list; public-rdf-in-xhtml task force
> Objet : 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 Thursday, 26 January 2006 12:09:49 UTC