Discussion:
[ALL] RDF/A Primer Version
(too old to reply)
Ben Adida
2006-01-24 17:03:19 UTC
Permalink
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
***@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
Booth, David (HP Software - Boston)
2006-01-24 20:48:41 UTC
Permalink
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.

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-***@w3.org
> [mailto:public-swbp-wg-***@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
> ***@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
>
>
Ben Adida
2006-01-24 21:31:21 UTC
Permalink
David,

I agree, I think we should mark the problems. I'd rather not try to
rush the fixing of these problems, though, as I think they'll need
very careful editing. Assuming we do mark the problem carefully, do
you think the impact of section #2 is small enough to warrant moving
ahead?

-Ben

On Jan 24, 2006, at 3:48 PM, Booth, David (HP Software - Boston) wrote:

>
> 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.
>
> 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-***@w3.org
>> [mailto:public-swbp-wg-***@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
>> ***@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
>>
>>
>
Pat Hayes
2006-01-25 05:30:35 UTC
Permalink
>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-***@w3.org
>> [mailto:public-swbp-wg-***@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
>> ***@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
Miles, AJ (Alistair)
2006-01-25 18:37:03 UTC
Permalink
Comment on

http://www.w3.org/2001/sw/BestPractices/HTML/2006-01-24-rdfa-primer
RDF/A Primer $Id: 2006-01-24-rdfa-primer.xml,v 1.7 2006/01/24 16:43:20 adida Exp $

The example:

<html>
<head>
<title>Jo Lamda's Home Page</title>
</head>
<body>
<p>
Hello. This is <span property="foaf:name">Jo Lamda</span>'s
home page.
<h2>Work</h2>
If you want to contact me at work, you can
either <a rel="foaf:mbox" href="mailto:***@example.org">email
me</a>, or call <span property="foaf:phone">+1 777 888 9999</span>.
</p>
</body>
</html>

... gives the following triples (assuming that the above is the content of Jo's home page):

<http://jo-lamda.blogspot.com/>
foaf:name "Jo Lambda";
foaf:mbox <mailto:***@example.org>;
foaf:phone "+1 777 888 9999".

What is the URI <http://jo-lamda.blogspot.com/> being used to denote? Jo? Jo's home page? Both?

How is it possible for Terri's contact software to 'extract' the 'information':

foaf:homepage = "http://jo-lamda.blogspot.com/"

... where no such triple is given in the content, unless it 'knows' to handle home pages containing RDF/A in a special way?

If the example were to be:

<html>
<head>
<title>Jo Lamda's Home Page</title>
</head>
<body>
<p>
Hello. This is <span property="foaf:name">Jo Lamda</span>'s
<a rel="foaf:homepage" href="http://jo-lamda.blogspot.com/">home page</a>.
</p>
</body>
</html>

... it would give the additional triple:

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

How does Terri's contact software handle this? How should other applications handle this?

As I understand it, if you want to use the URI <http://jo-lamda.blogspot.com/> to _indirectly identify_ Jo, you have to do something like:

_:aaa foaf:homepage <http://jo-lamda.blogspot.com/>;
_:aaa foaf:name "Jo Lambda".

Similarly, if you want to use the URI of Jo's internet mail box <mailto:***@example.org> to _indirectly identify_ Jo, you have to do something like:

_:aaa foaf:mbox <mailto:***@example.org>;
_:aaa foaf:name "Jo Lambda".

Then, because foaf:mbox is an inverse functional property (as is foaf:homepage), if it were declared that:

_:bbb foaf:mbox <mailto:***@example.org>.

... we could arrive at the conclusion:

_:bbb owl:sameAs _:aaa.

... which in turn would lead to the conclusion:

_:bbb foaf:name "Jo Lambda".

(Is this correct?)

This was what I understood by 'indirect identification' as implemented in RDF/OWL.

To say:

<http://jo-lamda.blogspot.com/> foaf:name "Jo Lambda".

... is to use the URI <http://jo-lamda.blogspot.com/> to _directly identify_ both Jo and her home page. I.e. this is a URI collision. If both Jo's home page URI and her internet mail box URI were used to _directly identify_ Jo, you could end up drawing the conclusion that:

<http://jo-lamda.blogspot.com/> owl:sameAs <mailto:***@example.org>.

Surely we want to avoid that?

Cheers,

Al.
Pat Hayes
2006-01-26 21:02:41 UTC
Permalink
>Comment on
>
>http://www.w3.org/2001/sw/BestPractices/HTML/2006-01-24-rdfa-primer
>RDF/A Primer $Id: 2006-01-24-rdfa-primer.xml,v 1.7 2006/01/24
>16:43:20 adida Exp $
>
>The example:
>
><html>
> <head>
> <title>Jo Lamda's Home Page</title>
> </head>
> <body>
> <p>
> Hello. This is <span property="foaf:name">Jo Lamda</span>'s
> home page.
> <h2>Work</h2>
> If you want to contact me at work, you can
> either <a rel="foaf:mbox"
>href="mailto:***@example.org">email
> me</a>, or call <span property="foaf:phone">+1 777
>888 9999</span>.
> </p>
> </body>
></html>
>
>... gives the following triples (assuming that the above is the
>content of Jo's home page):
>
><http://jo-lamda.blogspot.com/>
> foaf:name "Jo Lambda";
> foaf:mbox <mailto:***@example.org>;
> foaf:phone "+1 777 888 9999".
>
>What is the URI <http://jo-lamda.blogspot.com/> being used to
>denote? Jo? Jo's home page? Both?

Not a meaningful question. The technical answer is that it denotes
whatever it denotes in each possible interpretation of this RDF (plus
any other RDF that happens to be in use at the time.) This might be
Jo in some interpretations and Jo's homepage in others, and it might
be something else entirely in yet others. Moreover, this "ambiguity"
is not a problem to be solved. All that actually matters is that
useful conclusions can be drawn from all this RDF.

>How is it possible for Terri's contact software to 'extract' the
>'information':
>
>foaf:homepage = "http://jo-lamda.blogspot.com/"
>
>... where no such triple is given in the content, unless it 'knows'
>to handle home pages containing RDF/A in a special way?

Well, it isn't possible, without knowing some more information. But
why is this question relevant?

>
>If the example were to be:
>
><html>
> <head>
> <title>Jo Lamda's Home Page</title>
> </head>
> <body>
> <p>
> Hello. This is <span property="foaf:name">Jo Lamda</span>'s
> <a rel="foaf:homepage"
>href="http://jo-lamda.blogspot.com/">home page</a>.
> </p>
> </body>
></html>
>
>... it would give the additional triple:
>
><http://jo-lamda.blogspot.com/> foaf:homepage <http://jo-lamda.blogspot.com/>.
>
>How does Terri's contact software handle this? How should other
>applications handle this?

If that software is handling RDF, it just draws conclusions which
contain it. That is about all the 'handling' that is required to
happen to URIs in semantic web inferential processing.

It might for example do the following. Since the domain of
foaf:homepage is foaf:Person, it concludes that

http://jo-lamda.blogspot.com/ rdf:type foaf:Person .

Now we want to send a message to that person's emailbox, so we might
pose this as a SPARQL query:

SELECT ?x WHERE { http://jo-lamda.blogspot.com/ foaf:mbox ?x }

and if Jo had also used the RDF/A from your first example above, this
would succeed with the result
x/mailto:***@example.org , and from here on out it should be
plain sailing.

The point being that although you or I might find the claim
(<websiteURI> rdf:type foaf:Person .) to be a bit peculiar, this
doesn't bother the software. Its not even bothered by using the same
URI to denote the website and also the owner of the website, just as
long as those two 'roles' for the URI don't interfere with one
another; and although I havnt checked all the details, I don't think
they do anywhere in FOAF. This general multiple-use technique is
common in theorem-provers, where it is often called 'punning'; it is
a bit like the overloading of identifiers in typed programming
languages (though simpler). Logics we are developing for the
intelligence community and the Common Logic spec uses this technique
widely throughout its formal semantics, so a single name can refer to
a class, a property, a function, a proposition and an individual all
at the same time, because the logical syntax keeps the various roles
clearly separated.

BTW, this is what I meant by 'local context' in my other message:
here, the FOAF domain and range information is enough to establish
that some occurrences of http://jo-lamda.blogspot.com/ refer to the
person, while others refer to a homepage; which is all that is needed
in order to make the 'semantic' machinery work properly.

>As I understand it, if you want to use the URI
><http://jo-lamda.blogspot.com/> to _indirectly identify_ Jo, you
>have to do something like:
>
>_:aaa foaf:homepage <http://jo-lamda.blogspot.com/>;
> _:aaa foaf:name "Jo Lambda".

The tag architecture document doesn't mention blank node
constructions. This isn't indirect, anyway: all the references here
are direct.

But look, compare this with the 'clashing' usage:

<http://jo-lamda.blogspot.com/> foaf:homepage <http://jo-lamda.blogspot.com/> .
<http://jo-lamda.blogspot.com/> foaf:name "Jo Lambda"

This simply entails the bnode version, so anything you can infer
using that can also be inferred using this. So using bnodes certainly
does not *add* any functionality. The case for it, then, must be that
it avoids making some inferences that would follow from the second
rendering and that would cause a problem somewhere. This would have
to be an RDF subgraph containing <http://jo-lamda.blogspot.com/>
that is actively harmful (probably, which produces a contradiction)
but where the analogous subgraph with a blank node does not. Well,
maybe, but I havn't seen any actual examples.

>Similarly, if you want to use the URI of Jo's internet mail box
><mailto:***@example.org> to _indirectly identify_ Jo, you have
>to do something like:
>
>_:aaa foaf:mbox <mailto:***@example.org>;
> _:aaa foaf:name "Jo Lambda".
>
>Then, because foaf:mbox is an inverse functional property (as is
>foaf:homepage), if it were declared that:
>
>_:bbb foaf:mbox <mailto:***@example.org>.
>
>... we could arrive at the conclusion:
>
>_:bbb owl:sameAs _:aaa.
>
>... which in turn would lead to the conclusion:
>
>_:bbb foaf:name "Jo Lambda".
>
>(Is this correct?)

Yes, provided that this was all inside the same graph.

>This was what I understood by 'indirect identification' as
>implemented in RDF/OWL.

Its not what I understand by that term, since this style of working
doesn't use indirection at all: all the URIs and bnodes are being
used unambiguously here without any overloading. This is not
analogous to the use of "Downing Street" to refer to the UK
government (the example given in [4]).

>To say:
>
><http://jo-lamda.blogspot.com/> foaf:name "Jo Lambda".
>
>... is to use the URI <http://jo-lamda.blogspot.com/> to _directly
>identify_ both Jo and her home page. I.e. this is a URI collision.

Im not sure what the TAG architecture document means by this term, to
be honest, but this term "directly identify" is, ironically,
ambiguous, and is used ambiguously throughout the architecture
document (and through a number of previous documents). It can be
understood to mean, roughly, 'is a locator of'; or it can be
understood to mean 'refers to'. These are not the same notion. It is
perfectly possible for a URI to locate one thing and refer to
another, and no harm is thereby caused, provided only that one keeps
in mind that to refer to something is not the same as to access it
over the Web. To have a URI locating two different things is
architecturally impossible: to have it referring (ambiguously) to two
or more different things is inevitable (though you can imagine an
ideal fantasy world where it never happens: one is described in book
three of Gulliver's Travels, and another is described in the Earthsea
novels of Ursula LeGuin) but to have it referring to one thing while
being used to locate something else (such as a description of the
referent, or something used conventionally to refer to or indicate
the referent), seems to me should not be called a 'clash' at all.

>If both Jo's home page URI and her internet mail box URI were used
>to _directly identify_ Jo, you could end up drawing the conclusion
>that:
>
><http://jo-lamda.blogspot.com/> owl:sameAs <mailto:***@example.org>.
>
>Surely we want to avoid that?

Well, that does look kind of silly, I will concede, and might even
produce a contradiction if we had enough OWL content to prove that
pages and emailboxes were disjoint. But my own reaction to this would
be that such an OWL ontology would in fact be wrong, given the state
of actual usage, since such sameAs assertions can indeed be treated
as true, using widely used conventions about reference. Of course
both of these URIs also have network-functional roles, and to read
this owl:sameAs as identifying those roles would indeed be a mistake;
and therein lies one danger. The moral I would draw is that it is
risky to use owl:sameAs reasoning to conclude that any kind of Web
operations can be performed on a URI (such as using mailto:foo in an
http GET); but this would be a pretty poor design in any case. Its a
bit like using
Pat_Hayes = Patrick_J_Hayes
"Pat_Hayes" contains an abbreviation
to conclude that
"Patrick_J_Hayes" contains an abbreviation

By the way, both of the webpage/emailbox conventions can be
summarized as a single one, that the referential use of something
that identifies a reference or description of an entity, should be
treated as a reference to that entity: that the composition of
identification and reference should be treated as reference. I don't
justify this on theoretical semantic grounds, only empirically, as an
observation that human readers do this spontaneously and apparently
quite successfully. And then we just have to say that homepages and
emailboxes conventionally describe or refer to - not identify - their
owners, and everything works smoothly. This amounts to a systematic
blurring of the use/mention distinction that logicians get so
up-tight about (I speak as one, BTW, and reflexive ad hominem isn't
impolite.)

I'll concede that there is a perfectly reasonable objection to my
position along the lines, if http://jo-lamda.blogspot.com/ refers to
Jo, how can we refer to the website when we want to talk about it
rather than just GET something from it? That is, how do we 'turn off'
an indirect convention when it is not wanted? In simple cases (like
FOAF) there isn't any reason why we need to turn it off, since we can
use the URI in both ways at once, but in more complicated (and more
tightly constrained) cases this could be a problem. This is one
reason why I like the idea of explicitly naming RDF graphs instead of
using the http: URI, which gets a document containing a
representation of it, as the name for the graph. The same line of
thinking would reject the use of the website URI as a referring name
for the website, and would therefore require that we adopt some other
convention to refer to the website or mailbox (as opposed to access
it, using a transfer protocol such as http). For example, to adapt
one of the TAG suggestions, we might require that all URIs that are
being used referentially should give 303s when used with an http GET.
Not that I like this 303 redirect idea, but at least this version of
it would have the merit of not requiring anyone to come up with a
clear account of what exactly is the difference between a web
resource and a non-web resource, and it would place the distinction
where it belongs, between reference and access, rather than where it
does not belong, in an under-defined ontological distinction. There
is a transition cost, but not very high: previously published OWL/RDF
could be fixed just by changing the Qnames in all the headers to
point to redirecting URIs; whereas with the present muddle, someone
has to ask whether or not a resource is a web resource, which is
probably an unanswerable question in general. For example, a website
is closed down so that a GET on the old URI gives a 404 error, does
that convert the resource from a Web resource to a non-web resource?
After all, I can still *refer to* the website, perhaps in order to
say explicitly that it no longer exists.

Pat Hayes

--
---------------------------------------------------------------------
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
Miles, AJ (Alistair)
2006-01-25 19:30:54 UTC
Permalink
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:***@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-***@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-***@w3.org
>> [mailto:public-swbp-wg-***@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
>> ***@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
Bernard Vatant
2006-01-26 12:09:25 UTC
Permalink
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-***@w3.org
> [mailto:public-swbp-wg-***@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:***@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-***@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-***@w3.org
> >> [mailto:public-swbp-wg-***@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
> >> ***@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
>
>
>
>
Pat Hayes
2006-01-26 21:27:15 UTC
Permalink
>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.

That isn't how I read [4]. The kind of usage you describe is not
'indirect', since all the identifiers are being used with a single
referent in mind: "http://jo-lamda.blogspot.com/" denotes a web page
and "_:aaa" denotes its owner.

>
>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.

I apologize for using the c-word, which I normally try to avoid. I
didn't mean to imply that there are actual things called 'contexts'.
The context for a URI occurring in some RDF content is that RDF
itself, plus any other relevant RDF that can reasonably be presumed
to be accessible, e.g. the ontologies accessible from the base URIs
of other identifiers in the transmitted RDF, or in imported
ontologies. I meant only that if the identifier is transmitted from
A to B, then there is enough information available at B to do the
necessary disambiguation, without having to go back to A and ask for
clarification. In ordinary conversation, this corresponds to not
having to say something like "what sense of 'bank' did you mean,
exactly?".

>How do I as a publisher ensure that sufficient 'context' is
>available for the applications I intend to support?

You don't. But how, as a publisher, do you ensure that there enough
of anything to support the processing you hope will happen at the
other end? You cannot establish this absolutely, in all cases. The
best you can do is to provide pointers to anything that you feel is
relevant, and in many cases rely on a presumption that both you and
your readers share some common ground. It seems to me that there is
absolutely no way to avoid making assumptions like this.

>What about unforeseen applications? As a consuming application, how
>do I get at the 'context'

see above

>, and how do I use it to resolve ambiguities?

Well, my point is that most of these apparent ambiguities will either
not in fact need to be resolved, or their resolution will be done by
applying conventions that have evolved within a community of use,
which in a Web context means a community which uses a particular
vocabulary consistently in a certain way. The use of webpage address
URIs to denote people in FOAF is an excellent example. But the basic
point is that inferential processing (drawing conclusions, querying,
checking consistency, etc.) can all be done without needing to
'resolve' ambiguities. The ambiguity of a URI's reference, if
present, can usually simply be left ambiguous. The logical semantics
underlying inference presumes that identifiers are ambiguous in this
way: ambiguity is the norm. In fact, the reduction (not total
elimination) of ambiguity is often one of the main reasons for doing
inference.

> 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.

Well, yes, it is hard to argue with that. But if 10|6 websites, say,
already use webpage URIs to refer to their owners, and if the
normative semantic theories in the specifications do not prohibit
this (as they do not) and all the machinery that processes this
information works (as it does) why is it considered 'good practice'
to set out to re-educate everyone and to oblige them to to change?
Seems to me it might be more productive to take a more empirical and
less judgmental stance, and ask why and how this situation, which
theory predicts should lead to confusion, apparently does not lead to
confusion. The TAG recommendations seem to be based on an implicit
theory of ambiguity and communication. Projects like FOAF seem to me
to be empirical refutations of this theory.

>Surely it is also good practice for publishers in the majority of
>cases to design systems that do not lead to ambiguity

No. Ambiguity is inherent in the very idea of using names to refer in
a descriptive formalism. This is the point I tried to get across to
the TAG. There is a common presumption that ambiguity is a Bad Thing,
and so we should make every reasonable effort to Stamp It Out. But
this is nonsense: ambiguity *of reference* is not only not a bad
thing, it is a *necessary* thing. There are theorems which show that
only an uncomputable amount of assertional effort could ever
completely remove it. Even trying to remove it in realistic cases is
unfeasible. Take an ordinary unambiguous name: what *exactly* does
"Mount Everest" refer to? (What is its volume? Where are its edges?
etc..) Or take my name, and ignore the fact that there are many Pat
Hayes' in the world: does the "Pat Hayes" that identifies me refer to
me now, me throughout my lifetime; me considered as a social agent,
me considered as an organism, etc.? These are all distinctions that
formal ontologies regularly make. So these are ambiguities too: the
fact that they are not acknowledged by linguists doesn't make them
any less real, it is just a testament to our human ability to
communicate successfully using ambiguous notations. Almost all names
are referentially ambiguous; and ironically, every attempt to remove
this ambiguity by imposing more exactly defined lexica
(mountain-as-physical-object, mountain-as-geographical-entity,
mountain-as-climbing-peak, etc.) actually makes the ambiguity worse
for all other names, since it provides for making finer and finer
ontological distinctions elsewhere, thereby creating (or perhaps
revealing) ambiguity where none was previously noticed. If there are
ten distinct referents for "Pat Hayes" and also for "Jackie Hayes"
then there are a hundred different types of binary relation between
us that could all be described as "marriedTo". There is no final end
state where every name is unambiguous: this vision is a chimera.

One reaction I meet when I try to point this out is along the lines:
even if what you say is true, it is like saying that the world is
full of sin: but still, we should all strive to be good. But this
misses my point. I'm not saying that the problem is unsolvable. Im
saying that there is no problem. Ambiguity does not get in the way of
communication or inference. Setting out to remove all ambiguity is
like setting out to walk to the moon: its a futile goal since it
can't be done, and also because there is absolutely no need to even
try to do it. It is certainly not good practice in general.

Of course there are cases (medicine, biology, science generally, law,
international standards) where 'ordinary' identifiers are not
precisely defined enough for some technical usage, and specialized
lexica are necessary, often requiring careful management, because
certain kinds of ambiguity must be caught and corrected. I don't mean
to imply that this kind of effort is pointless: only that to assert
as a general property of the Web architecture that all identifiers
should be unambiguous, is nonsensical.

>, 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.

Well, that might be a good case, but the conclusion isn't obvious.
I'd like to see a really good (mathematical?) account of why and how
less ambiguity makes for improved portability. I can see good
informal arguments both ways.

>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?

No. Absolutely not.

>Don't domains and ranges become effectively useless also?

No. Although, to be fair, one common way to understand domains and
ranges, as 'constraints' on what can be said, which can be 'checked'
to detect 'errors', would indeed be in opposition to what Im saying
here. But none of those words Ive highlighted have any natural place
in an inferential framework: they all come from thinking about
programming language design.

>E.g. if I have:
>
><http://jo-lamda.blogspot.com/> foaf:mbox <mailto:***@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?

I don't vouch for its usefulness, but I would argue that it is a
reasonable statement of exactly the overloading or punning condition
that I have no problems with, which is that a single URI can usefully
play several referential roles at the same time. So, it might not be
particularly useful, but it can be harmlessly true.

Pat

>
>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-***@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-***@w3.org
>>> [mailto:public-swbp-wg-***@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
>>> ***@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


--
---------------------------------------------------------------------
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
Jeremy Carroll
2006-01-27 11:58:05 UTC
Permalink
Pat Hayes wrote:
> Well, yes, it is hard to argue with that. But if 10|6 websites, say,
> already use webpage URIs to refer to their owners, and if the normative
> semantic theories in the specifications do not prohibit this (as they do
> not) and all the machinery that processes this information works (as it
> does) why is it considered 'good practice' to set out to re-educate
> everyone and to oblige them to to change? Seems to me it might be more
> productive to take a more empirical and less judgmental stance, and ask
> why and how this situation, which theory predicts should lead to
> confusion, apparently does not lead to confusion. The TAG
> recommendations seem to be based on an implicit theory of ambiguity and
> communication. Projects like FOAF seem to me to be empirical refutations
> of this theory.


Big cheer from the sidelines ...

Jeremy
Ben Adida
2006-01-27 19:01:47 UTC
Permalink
[... much useful discussion ...]

Thank you all for these very useful comments. I have added warnings
in Sections 2 and 3 of the RDF/A Primer (2006-01-24) [1].

I would like to ask for some clarification on one issue so we can
narrow down the source of the debate. I'm particularly worried about
the implication that a URI with a # in it cannot be used to reference
a non-information-resource entity if the containing URI (without a #)
is an XHTML document.

Specifically, here's an alternative way to present the FOAF metadata
in RDF/A:

=========
<html>
<head><title>Ben Adida's Page</title></head>
<body>
<p about="#me">
Welcome to my <a rel="foaf:homepage">homepage</a>.
You can contact me at <span property="foaf:mbox">***@mit.edu</span>.
</p>
</body>
</html>
=========

which would yield the triples:

<#me> foaf:homepage <>.
<#me> foaf:mbox "***@mit.edu".

Is this still wrong according to the TAG, because the <> URI resolves
to an XHTML document and thus <#me> cannot be a foaf:person? That is
what I understood from Alistair's early email. I want to point out
that, if that is the case, then as Mark described, that is seriously
problematic for RDF/A whose goal it is to describe the document that
is actually carrying the RDF/A itself.

-Ben
Ben Adida
2006-01-27 19:05:45 UTC
Permalink
The [1] reference was meant to point to:

[1] http://www.w3.org/2001/sw/BestPractices/HTML/2006-01-24-rdfa-primer

-Ben

On Jan 27, 2006, at 2:01 PM, Ben Adida wrote:

>
>
> [... much useful discussion ...]
>
> Thank you all for these very useful comments. I have added warnings
> in Sections 2 and 3 of the RDF/A Primer (2006-01-24) [1].
>
> I would like to ask for some clarification on one issue so we can
> narrow down the source of the debate. I'm particularly worried
> about the implication that a URI with a # in it cannot be used to
> reference a non-information-resource entity if the containing URI
> (without a #) is an XHTML document.
>
> Specifically, here's an alternative way to present the FOAF
> metadata in RDF/A:
>
> =========
> <html>
> <head><title>Ben Adida's Page</title></head>
> <body>
> <p about="#me">
> Welcome to my <a rel="foaf:homepage">homepage</a>.
> You can contact me at <span property="foaf:mbox">***@mit.edu</span>.
> </p>
> </body>
> </html>
> =========
>
> which would yield the triples:
>
> <#me> foaf:homepage <>.
> <#me> foaf:mbox "***@mit.edu".
>
> Is this still wrong according to the TAG, because the <> URI
> resolves to an XHTML document and thus <#me> cannot be a
> foaf:person? That is what I understood from Alistair's early email.
> I want to point out that, if that is the case, then as Mark
> described, that is seriously problematic for RDF/A whose goal it is
> to describe the document that is actually carrying the RDF/A itself.
>
> -Ben
>
Frank Manola
2006-01-24 21:21:41 UTC
Permalink
All the points I raised in my earlier email
http://lists.w3.org/Archives/Public/public-swbp-wg/2006Jan/0114.html
still apply to this new version. A couple of additional points:

1. The new Section 2 provides a possible place to introduce what a
"property" is in a simple way. In Section 2.2, the sentence that
starts "Jo then looks through the FoaF vocabulary..." could be changed to:

"Jo then looks through the FoaF vocabulary, and sees that the pieces of
information that she has in her page--name, phone number and email
address--are all the names of properties within FoaF."

A more extensive introduction to the "property" notion might be better,
but this suggestion at least involves little added text.

2. At the very beginning of Section 2.2, the second sentence says "All
Jo needs to do is to add some *tags* [my emphasis] to her home page...".
The third sentence goes on to say "The *tags* that Terri's address
book understands come from a special list-often called a vocabulary...".
In neither case is "tag" the right word (particularly since this is
XHTML). Syntactically, what you're adding are attributes (and their
values), although you may want to use some informal alternative, since
the attributes themselves don't come from something like FoaF (although
their values do), but rather from RDF/A.

--Frank

Ben Adida wrote:
>
>
> 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
>
Ben Adida
2006-01-24 21:33:33 UTC
Permalink
Frank,

Yes, I want to make it very clear that I did not attempt to factor
any comments into this version *yet*, just so I could keep the level
of confusion to a minimum. Of course, we intend to promptly address
every comment in time for WD #2.

-Ben

On Jan 24, 2006, at 4:21 PM, Frank Manola wrote:

> All the points I raised in my earlier email http://lists.w3.org/
> Archives/Public/public-swbp-wg/2006Jan/0114.html
> still apply to this new version. A couple of additional points:
>
> 1. The new Section 2 provides a possible place to introduce what a
> "property" is in a simple way. In Section 2.2, the sentence that
> starts "Jo then looks through the FoaF vocabulary..." could be
> changed to:
>
> "Jo then looks through the FoaF vocabulary, and sees that the
> pieces of information that she has in her page--name, phone number
> and email address--are all the names of properties within FoaF."
>
> A more extensive introduction to the "property" notion might be
> better, but this suggestion at least involves little added text.
>
> 2. At the very beginning of Section 2.2, the second sentence says
> "All Jo needs to do is to add some *tags* [my emphasis] to her home
> page...". The third sentence goes on to say "The *tags* that
> Terri's address book understands come from a special list-often
> called a vocabulary...". In neither case is "tag" the right word
> (particularly since this is XHTML). Syntactically, what you're
> adding are attributes (and their values), although you may want to
> use some informal alternative, since the attributes themselves
> don't come from something like FoaF (although their values do), but
> rather from RDF/A.
>
> --Frank
>
> Ben Adida wrote:
>> 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
Frank Manola
2006-01-24 21:54:49 UTC
Permalink
Ben--

Makes sense. BTW, the new Section 2 is an excellent addition.

--Frank

Ben Adida wrote:
>
> Frank,
>
> Yes, I want to make it very clear that I did not attempt to factor any
> comments into this version *yet*, just so I could keep the level of
> confusion to a minimum. Of course, we intend to promptly address every
> comment in time for WD #2.
>
> -Ben
>
e***@cme.nist.gov
2006-01-24 22:36:30 UTC
Permalink
David Booth wrote:
>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 have the same reaction. These problems should be fixed before
publication. Kudos to Alistair for spotting the problems!

-Evan
Mark Birbeck
2006-01-24 22:55:12 UTC
Permalink
David/Ben,

I think Ben is right that this is not something that can be resolved
quickly...or rather the URI collision part isn't. (Speaking for myself I'm
happy to see dc:creator removed--it's always confused people.)

One part of the problem is that the whole point of RDF/A is to be able to
carry metadata within a 'normal' document. This means that *by definition*
we have what could be perceived as two resources at the same URL--we have an
XHTML document, and we have metadata for that document. Both are 'carried'
by the same set of XML elements, but how they are *processed* depends on the
agent retrieving them. It seems to me that the TAG work on fragment
identifiers does not allow for this possibility, since it says that if the
document is XHTML, then a fragment identifier must be referring to an XML
element. (In passing this seems wrong to me anyway, since it is supposed to
be up to the user agent to make use of the fragment identifier.)

Anyway, I'm not saying that this can't be resolved in some way that fits
with the TAG work, and I have some ideas that I would like to bounce around
the list, but I would again agree with Ben's point that we should go ahead
with the draft, but with an understanding that this work will continue.

Regards,

Mark


Mark Birbeck
CEO
x-port.net Ltd.

e: ***@x-port.net
t: +44 (0) 20 7689 9232
b: http://internet-apps.blogspot.com/
w: http://www.formsPlayer.com/

Download our XForms processor from
http://www.formsPlayer.com/

> -----Original Message-----
> From: public-rdf-in-xhtml-tf-***@w3.org
> [mailto:public-rdf-in-xhtml-tf-***@w3.org] On Behalf Of Ben Adida
> Sent: 24 January 2006 21:31
> To: Booth, David (HP Software - Boston)
> Cc: SWBPD list; public-rdf-in-xhtml task force
> Subject: Re: [ALL] RDF/A Primer Version
>
>
>
> David,
>
> I agree, I think we should mark the problems. I'd rather not
> try to rush the fixing of these problems, though, as I think
> they'll need very careful editing. Assuming we do mark the
> problem carefully, do you think the impact of section #2 is
> small enough to warrant moving ahead?
>
> -Ben
>
> On Jan 24, 2006, at 3:48 PM, Booth, David (HP Software -
> Boston) wrote:
>
> >
> > 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.
> >
> > 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-***@w3.org
> >> [mailto:public-swbp-wg-***@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
> >> ***@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
> >>
> >>
> >
>
>
>
Jeremy Carroll
2006-01-25 12:30:29 UTC
Permalink
Mark Birbeck wrote:
> One part of the problem is that the whole point of RDF/A is to be able to
> carry metadata within a 'normal' document. This means that *by definition*
> we have what could be perceived as two resources at the same URL--we have an
> XHTML document, and we have metadata for that document. Both are 'carried'
> by the same set of XML elements, but how they are *processed* depends on the
> agent retrieving them. It seems to me that the TAG work on fragment
> identifiers does not allow for this possibility, since it says that if the
> document is XHTML, then a fragment identifier must be referring to an XML
> element. (In passing this seems wrong to me anyway, since it is supposed to
> be up to the user agent to make use of the fragment identifier.)

strong agreement. (no additional argument though!)

Jeremy
Booth, David (HP Software - Boston)
2006-01-24 23:00:34 UTC
Permalink
If each example in question is clearly marked as known to be incorrect
(with at least a pointer to some explanation), so that readers are not
tempted to naively mimic the examples, then I think I would be okay with
publishing.

BTW, Section 2 is a nice addition -- good narrative. A couple editorial
things:

1. Sec 2.2.3 example is missing the foaf namespace declaration.

BTW, are all examples being tested by an RDF/A parser to verify the RDF
they produce? For this draft I don't think it's essential, but I think
it should be done before the document is finalized, because machines
have a way of catching mistakes that human eyes miss. ;)

2. s/deparment/department/

David Booth


> -----Original Message-----
> From: Ben Adida [mailto:***@mit.edu]
> Sent: Tuesday, January 24, 2006 4:31 PM
> To: Booth, David (HP Software - Boston)
> Cc: SWBPD list; public-rdf-in-xhtml task force
> Subject: Re: [ALL] RDF/A Primer Version
>
>
>
> David,
>
> I agree, I think we should mark the problems. I'd rather not try to
> rush the fixing of these problems, though, as I think they'll need
> very careful editing. Assuming we do mark the problem carefully, do
> you think the impact of section #2 is small enough to warrant moving
> ahead?
>
> -Ben
>
> On Jan 24, 2006, at 3:48 PM, Booth, David (HP Software -
> Boston) wrote:
>
> >
> > 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.
> >
> > 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-***@w3.org
> >> [mailto:public-swbp-wg-***@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
> >> ***@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
> >>
> >>
> >
>
>
Jeremy Carroll
2006-01-25 12:32:01 UTC
Permalink
Booth, David (HP Software - Boston) wrote:
> BTW, are all examples being tested by an RDF/A parser to verify the RDF
> they produce? For this draft I don't think it's essential, but I think
> it should be done before the document is finalized, because machines
> have a way of catching mistakes that human eyes miss. ;)
>

I don't believe so, but I am happy to own this (by next publication, not
this one).

Jeremy
Gary Ng
2006-01-25 09:36:34 UTC
Permalink
I think section 2 is a very good addition, and by large it addresses nicely my original concern on a quick overview of the language capability right up front within the Primer.

Regarding the 'collision' issue, I tend to agree with the responses by Mark Birbeck [1] and Pat Hayes [2].

I strongly believe what is really important is for the tools to retrieve *unambiguously* what the author of the metadata intended the tools to retrieve.

[Mark]> "it is supposed to be up to the user agent to make use of the fragment identifier.)"

[Pat]> "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."

Along this line however, I've noticed within the new Section 2 in [3] possibly another ambiguity which is related to URI dereferencing, perhaps Alistair can chime in as well (as I am no expert in the dereferencing issue):

How does one (a tool or human) decides whether the href="..." is physically dereferenceable and the location indeed contains more metadata about it?

There must be situations where the href="..." is only logical and is not deferenceable, or in another situations where the author really intend to just assert that resource reference as a piece of metadata and has no intension for anyone to dereference?

For example,

A. Don't want to dereference for metadata:
foaf:mbox = "mailto:***@example.org"

B. Those to dereference for more metadata (e.g in the Department members page) to build up a contact list:
<a rel="foaf:member" href="http://jo-lamda.blogspot.com/">Jo Lamda</a>

C. Those to dereference but there is going to be nothing there so we need to add metadata locally. In this case it seems like the approach is to use additional elements with about="..." to specify.

>From the use case in section 2, it would seem the tools automatically updating contact details would need to at least differentiate situations A and B, because the language does not currently distinguish them.

If the default behaviour is A, then the tool will get some uneven/incomplete metadata by the Department members page example since all 3 situations are contained in the document.

If the default behaviour is B, then there exists not just problems with A, but a web crawling problem in that: when do you stop dereferencing and retrieving only just those metadata relevant to your tool?

I am fine with going forward to WD, base on this version with updates from all the review comments.

Cheers,

Gary

p.s. In addition, the last example of Section 2 (a departmental member without a homepage) is intriging:

<li id="andrew" about="#andrew">
<link rel="rdf:type" href="[foaf:member]" />
<span property="foaf:firstname">Andrew</span>
<span property="foaf:surname">Smith</span> can be contacted on
<span property="foaf:phone">+1 777 888 9998</span>
</li>

I think the link element is incorrect as it states #andrew rdf:type foaf:member, which is an rdf:Property?


[1] http://lists.w3.org/Archives/Public/public-swbp-wg/2006Jan/0137.html
[2] http://lists.w3.org/Archives/Public/public-swbp-wg/2006Jan/0139.html


________________________________________
From: public-swbp-wg-***@w3.org [mailto:public-swbp-wg-***@w3.org] On Behalf Of Booth, David (HP Software - Boston)
Sent: Tuesday, January 24, 2006 12:49 PM
To: Ben Adida; SWBPD list
Cc: 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.

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-***@w3.org
> [mailto:public-swbp-wg-***@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
> ***@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
>
>
Jeremy Carroll
2006-01-25 12:39:59 UTC
Permalink
Gary Ng wrote:
> There must be situations where the href="..." is only logical and is not
> deferenceable, or in another situations where the author really intend to
> just assert that resource reference as a piece of metadata and has no
> intension for anyone to dereference?
>
> For example,
>
> A. Don't want to dereference for metadata:
> foaf:mbox = "mailto:***@example.org"
>
> B. Those to dereference for more metadata (e.g in the Department members page)
> to build up a contact list:
> <a rel="foaf:member" href="http://jo-lamda.blogspot.com/">Jo Lamda</a>
>
> C. Those to dereference but there is going to be nothing there so we need to
> add metadata locally. In this case it seems like the approach is to use
> additional elements with about="..." to specify.
>

My understanding is that when loading an RDF graph from a document,
however it is serialized, there is always the issue of whether you want
to dereference the resources referred to, in order to get more triples.
Common practice is not to; but cwm, for instance, supports a mode where
you do read everything, recursively ...

It is clear that if the scheme does not support a GET operation then you
cannot, so A. unambiguously cannot be dereferenced. For case B, one
could do a GET, with appropriate accept-headers, and if what comes back
is RDF (in any form, RDF/XML, N3, RDF/A ...) then you could read it as
more metadata. There is no consensus about the status of the
relationship between the propositional attitudes expressed in the two
documents loaded.

So I don't see this as an RDF/A issue, but a much wider semantic web issue.

Jeremy
DuCharme, Bob (LNG-CHO)
2006-01-27 15:55:44 UTC
Permalink
This looks much better, and is really going to help sell RDF/A. My
comments are mostly tech writer oriented.

General comments

While the use cases will make it much easier for readers to see the
benefits of RDF/A, the document has a very academic tone in places, with
a lot of "we this" and "we that" making it sound like it's a
presentation of research findings and not a primer, so I offered some
alternatives below.

Is Jo's last name lamda or lambda? Both come up a lot. Replace all
instances of one with the other.

A lot of the examples in pre elements have lines that are well over 80
characters, so they get cut off when printed.

I just noticed at least one change ("One immediately wonders" to "one
might wonder") from the 24 January draft that I printed out to read to
the one that's up on the 26th, so some of the things I reference may not
be the same any more.

I was trying to read this from the perspective of the Jos and Terris out
there as they wonder what's going on here and if it's worth the trouble.
With my tech writer hat on, I particularly watched for terms and syntax
that were used without being introduced.

section 1

Either say why it's called RDF/A or else change the name! Because it's a
method for storing RDF information in HTML primarily by using the "a"
hypertext linking anchor element? If you want to sell something, its
name should make some sense to the people you're selling it to.

In the list in the first paragraph, you might mention microformats after
SVG. Nice trendy buzzword.

2.2

The paragraph beginning "One of Jo's friends" has single hyphens where
it should have em dashes, which do show up two paragraphs later ("Jo
then looks..."). This makes list-often and vocabulary-specifically look
like hyphenated terms.

"Jo then looks" paragraph: the discussion of properties and values in
the numbered list after this paragraph jumps up too many levels of
abstraction from the use case all at once, so this paragraph needs
something to ease the transition better, e.g. adding the following after
"within FOAF":

She will add this information to her document as properties of that
document.

Or, something else that relates the concept of property values to Jo's
task.

I had to read the second half of numbered list item 1 too many times to
understand it. How about ending it like this:

then the rel ("relationship") attribute can be added to the element
with the property name as its value.

I believe this is the first mention of the rel attribute, which is why
it should have the parenthetical expression after it. We want these
attribute names to have meaning to people, instead of being magic words.

2.2.3

The example document isn't as complete as the primer claims; it should
include the xmlns:foaf namespace declaration in the first tag. For that
matter, all examples that show the html start-tag should include the
xmlns="http://www.w3.org/1999/xhtml" attribute setting as well, because
a key reason to use XHTML instead of HTML is to allow the kind of
automated use of documents that Jo Lambda is laying the groundwork for
with the markup she's adding.

2.3

After the first example but before the line "The title of the group..."
add this:

Square brackets enclose "foaf:Group" because it's a special form of a
URI called a CURIE, which is covered in more detail in section 4.4 of
this document.

Don't just throw in new syntax and hope the reader won't notice! Also,
shouldn't the "G" in "foaf:Group" be in lower case? If not, explain why
in the document.

Last paragraph of 2.3 after "and not to the individual member of the
group" I had written in "why" there, but later wrote in this as
something to add: "for reasons we'll see in section 4.2." (If you don't
want to refer to specific sections as a style thing and just say "later
in this document" instead, that's fine, but it's good to reassure the
readers that the obvious questions that crop up in their minds as they
read will be addressed at some point.)

Add to very end of paragraph after "to be set to foaf:member":

by entering this in square braces as the link element's href value.

It would be nice to add a section 2.4 that sums up what Jo's done and
mentions her clicking a button on some "update departmental information"
page to kicks off a script to harvest the information she's added to her
pages so that the intranet departmental address book, etc. all get
updated. It would be a nice finish to the scenario by showing the data
being put to a good use that anyone can understand.

3.1

Third paragraph: "We'll show" instead of "We explore."

Fourth paragraph: "We consider literal properties first and the URI
properties second." How about

We'll look at two kinds of properties that we can add: literal
properties and URI properties.

3.2

After

An RDF/A-aware browser would thus extract the following RDF triples

add

, expressed here in N3 notation:

eighth paragraph: drop ", at this point in the presentation, "

4. Very nice intro.

4.2 Tie this in with the about="#andrew" issue from section 2.3.

"One might now wonder..." Don't even mention bnodes if you're not going
to say something about what they are. (The RDF Primer doesn't mention
them.) This paragraph could say something like this:

It is possible for meta and link elements to describe parent elements
that have no name identified in an id or about attribute, but this
requires the use of more advanced RDF syntax.

4.4

Change

We now address URI duplication, RDF/A's most significant data
duplication issue, with Compact URIs, known as CURIEs.

to something like

Compact URIs, known as CURIEs, ease the URI duplication problem we've
seen in the above examples, making data more compact.

Again, I think this primer has taken a great step toward becoming
something that will convince people of the value of RDF/A in particular
and RDF in general.

Bob
http://www.snee.com/bobdc.blog
Jeremy Carroll
2006-01-27 21:48:46 UTC
Permalink
> Is Jo's last name lamda or lambda? Both come up a lot. Replace all
> instances of one with the other.

lambda is the correct spelling of the name of the greek letter.

Jeremy
Miles, AJ (Alistair)
2006-01-30 17:32:08 UTC
Permalink
Hi Ben,

I think that, because no element with the id attribute value "me" is actually present in the document, then current specifications [3,4] do not allow any conclusions about the nature of <#me> to be drawn from the content-type of the document.

As I understand it, the TAG position is that, if an element with id "me" is present in the document, then:

<#me> rdf:type ???:XMLElement.

... follows (is implied? is entailed?), because ...

>From [3]: 'The semantics of a fragment identifier are defined by the set of representations that might result from a retrieval action on the primary resource.'

>From [4]:

'... fragment
identifiers for XHTML documents designate the element with the
corresponding ID attribute value ...'

(I use '???:' above because I'm not aware that anyone has actually declared the class of 'XML elements'.)

Then if FOAF were to declare:

foaf:Person owl:disjointWith ???:XMLElement.

... this can lead to (implies? entails?) an 'inconsistency' (is that the same thing as a 'contradiction'?)

But, if I have understood correctly, Pat argues [5,6] that this type of 'inconsistency', even if it were to arise, would not actually cause any problems, i.e. is not at all harmful in any way, and is in fact very useful.

Please note my position given at [7]: 'I support publication of this document as a Working Draft'. I do not think the publication of RDF/A as Working Draft should be delayed because of this particular discussion thread.

Al.

[3] http://www.w3.org/TR/2004/REC-webarch-20041215/#media-type-fragid
[4] http://www.ietf.org/rfc/rfc3236.txt
[5] http://lists.w3.org/Archives/Public/public-swbp-wg/2006Jan/0152.html
[6] http://lists.w3.org/Archives/Public/public-swbp-wg/2006Jan/0153.html
[7] http://lists.w3.org/Archives/Public/public-swbp-wg/2006Jan/0113.html

> [... much useful discussion ...]
>
> Thank you all for these very useful comments. I have added warnings
> in Sections 2 and 3 of the RDF/A Primer (2006-01-24) [1].
>
> I would like to ask for some clarification on one issue so we can
> narrow down the source of the debate. I'm particularly worried about
> the implication that a URI with a # in it cannot be used to
> reference
> a non-information-resource entity if the containing URI
> (without a #)
> is an XHTML document.
>
> Specifically, here's an alternative way to present the FOAF metadata
> in RDF/A:
>
> =========
> <html>
> <head><title>Ben Adida's Page</title></head>
> <body>
> <p about="#me">
> Welcome to my <a rel="foaf:homepage">homepage</a>.
> You can contact me at <span
> property="foaf:mbox">***@mit.edu</span>.
> </p>
> </body>
> </html>
> =========
>
> which would yield the triples:
>
> <#me> foaf:homepage <>.
> <#me> foaf:mbox "***@mit.edu".
>
> Is this still wrong according to the TAG, because the <> URI
> resolves
> to an XHTML document and thus <#me> cannot be a foaf:person?
> That is
> what I understood from Alistair's early email. I want to point out
> that, if that is the case, then as Mark described, that is seriously
> problematic for RDF/A whose goal it is to describe the document that
> is actually carrying the RDF/A itself.
Pat Hayes
2006-01-30 22:07:56 UTC
Permalink
>Hi Ben,
>
>I think that, because no element with the id
>attribute value "me" is actually present in the
>document, then current specifications [3,4] do
>not allow any conclusions about the nature of
><#me> to be drawn from the content-type of the
>document.
>
>As I understand it, the TAG position is that, if
>an element with id "me" is present in the
>document, then:
>
><#me> rdf:type ???:XMLElement.
>
>... follows (is implied? is entailed?)

I do hope they didn't actually say that, because
therein lies the problem, seems to me.

>, because ...
>
>>From [3]: 'The semantics of a fragment
>>identifier are defined by the set of
>>representations that might result from a
>>retrieval action on the primary resource.'

As I read this, it seems to say that the
retrieval action yields a *representation* of the
semantics of the fragID, and this representation
defines the semantics of it, i.e. what it means.
The most direct interpretation of what that
means, applied to RDF, would be that the RDF you
get from the primary resource is a representation
which defines the semantics of the fragID; so,
the RDF semantic theory is what should be used to
determine the meaning of the identifiers used in
the RDF: and that is exactly what the RDF spec
also says. If this is what this all means, then
it doesn't follow at all that the fragID has to
denote some piece of XML syntax. That would be a
use/mention confusion, seems to me: the fragID
*is* a piece of the XML syntax machinery, which
is used to encode a representation: what it
*denotes* or *means* is determined by that very
representation. Surely that is exactly what the
above quote says.

>
>>From [4]:
>
> '... fragment
> identifiers for XHTML documents designate the element with the
> corresponding ID attribute value ...'

Again, there is an implicit pun on "designate".
You seem to be reading this to mean "denotes" ,
but I don't think that is what the TAG group had
in mind at all. I think they are using
'designate' here to mean something like
'indicate' or 'stand in for'. If they really did
mean 'denote', then XML text would refer to
itself, and XML would be a semantically reflexive
language, which would be a very peculiar kind of
thing. This doesn't seem to jibe with uses of XML
in real life.

>(I use '???:' above because I'm not aware that
>anyone has actually declared the class of 'XML
>elements'.)

Indeed. It would be tricky to do.

>Then if FOAF were to declare:
>
>foaf:Person owl:disjointWith ???:XMLElement.
>
>... this can lead to (implies? entails?

Yes to both. 'Entails' is the semantic version of 'implies'.

>) an 'inconsistency' (is that the same thing as a 'contradiction'?)
>

Again, to be pedantic, "inconsistency" is a
semantic notion while "contradiction" refers to
the syntactic or computational signal of the
presence of an inconsistency. But what the hell,
as Mehitabel used to say.

>But, if I have understood correctly, Pat argues
>[5,6] that this type of 'inconsistency', even if
>it were to arise, would not actually cause any
>problems, i.e. is not at all harmful in any way,
>and is in fact very useful.

For the record, my position isn't tolerant of
formal inconsistency, so there would indeed be
something wrong about this situation; but I would
locate the source of the problem as being the
interpretation of the text you cite earlier, ie
the claim that <#me> rdf:type ???:XMLElement.

>Please note my position given at [7]: 'I support
>publication of this document as a Working
>Draft'. I do not think the publication of RDF/A
>as Working Draft should be delayed because of
>this particular discussion thread.

I agree.

Pat


>
>Al.
>
>[3] http://www.w3.org/TR/2004/REC-webarch-20041215/#media-type-fragid
>[4] http://www.ietf.org/rfc/rfc3236.txt
>[5] http://lists.w3.org/Archives/Public/public-swbp-wg/2006Jan/0152.html
>[6] http://lists.w3.org/Archives/Public/public-swbp-wg/2006Jan/0153.html
>[7] http://lists.w3.org/Archives/Public/public-swbp-wg/2006Jan/0113.html
>
>> [... much useful discussion ...]
>>
>> Thank you all for these very useful comments. I have added warnings 
>> in Sections 2 and 3 of the RDF/A Primer (2006-01-24) [1].
>>
>> I would like to ask for some clarification on one issue so we can 
>> narrow down the source of the debate. I'm particularly worried about 
>> the implication that a URI with a # in it cannot be used to
>> reference 
>> a non-information-resource entity if the containing URI
>> (without a #) 
>> is an XHTML document.
>>
>> Specifically, here's an alternative way to present the FOAF metadata 
>> in RDF/A:
>>
>> =========
>> <html>
>> <head><title>Ben Adida's Page</title></head>
>> <body>
>> <p about="#me">
>> Welcome to my <a rel="foaf:homepage">homepage</a>.
>> You can contact me at <span
>> property="foaf:mbox">***@mit.edu</span>.
>> </p>
>> </body>
>> </html>
>> =========
>>
>> which would yield the triples:
>>
>> <#me> foaf:homepage <>.
>> <#me> foaf:mbox "***@mit.edu".
>>
>> Is this still wrong according to the TAG, because the <> URI
>> resolves 
>> to an XHTML document and thus <#me> cannot be a foaf:person?
>> That is 
>> what I understood from Alistair's early email. I want to point out 
>> that, if that is the case, then as Mark described, that is seriously 
>> problematic for RDF/A whose goal it is to describe the document that 
>> is actually carrying the RDF/A itself.
>
>


--
---------------------------------------------------------------------
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
Booth, David (HP Software - Boston)
2006-01-30 18:11:01 UTC
Permalink
> From: Pat Hayes [mailto:***@ihmc.us]
> . . .
> That isn't how I read [4]. The kind of usage you describe is not
> 'indirect', since all the identifiers are being used with a single
> referent in mind: "http://jo-lamda.blogspot.com/" denotes a web page
> and "_:aaa" denotes its owner.

I think what you're trying to elucidate is good, but the sentence above
does not seem quite right. When a single identifier is used with more
than one referent in mind, that would normally be called "ambiguous",
not "indirect".

[4] WebArch: http://www.w3.org/TR/webarch/#indirect-identification

David Booth
Pat Hayes
2006-01-30 23:11:44 UTC
Permalink
> > From: Pat Hayes [mailto:***@ihmc.us]
>> . . .
>> That isn't how I read [4]. The kind of usage you describe is not
>> 'indirect', since all the identifiers are being used with a single
>> referent in mind: "http://jo-lamda.blogspot.com/" denotes a web page
>> and "_:aaa" denotes its owner.
>
>I think what you're trying to elucidate is good, but the sentence above
>does not seem quite right. When a single identifier is used with more
>than one referent in mind, that would normally be called "ambiguous",
>not "indirect".

OK, let me re-phrase. In the example using bnodes, there is no case
where an identifier which has a 'normal' meaning is being
systematically used to refer to something else. The example given in
[4] is the use of "Downing Street" to refer to the UK government
rather than a London street, even though it of course can also refer
to a London street, and in fact this is the basis for this indirect
use. But in the RDF I was referring to, no identifier is being
overloaded in this way. The intuitive reading of the example has each
identifier clearly referring to a single intended referent, and there
is nothing which requires any identifier to be re-interpreted or
overloaded by anything like the downing-street/government kind of
double entendre. So I don't see this kind of example as having
anything to do with indirect identification at all.

Pat Hayes

>[4] WebArch: http://www.w3.org/TR/webarch/#indirect-identification
>
>David Booth


--
---------------------------------------------------------------------
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
Booth, David (HP Software - Boston)
2006-01-30 18:11:02 UTC
Permalink
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:***@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:***@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:***@example.com>
iPreferences:likesToEat
<http://example.org/recipies/applePie> .

More precisely, it indicates that "The person whose mailbox is
***@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:***@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:***@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:***@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
Jeremy Carroll
2006-02-01 12:28:20 UTC
Permalink
Slightly off-topic,
on indirect identification ...

a well-deployed version of indirect identification (not using URIs) is
dc:creator (and also many similar systems).

dc:creator is normally used with a text string being the name of the
creator. This indirectness of what is actually interesting (the person
who is the creator, rather than their name) is conveyed by the
definition of dc:creator.

There are of course some difficulties with ambiguity, but not enough to
justify the amount of effort and lifelessness in giving every person a
truly unique id, rather than the name that there parents gave them.

It is important to not give too much ground to the ambiguity police. We
live and breathe ambiguity.

Jeremy
Booth, David (HP Software - Boston)
2006-01-30 18:37:11 UTC
Permalink
Bernard,

> 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.

Your overall point may be correct -- I don't know, I'm still trying to
figure it out! -- but what you've stated above seems to fly in the face
of RFC 3986[8] (the definition of URIs). RFC 3986 is very clear that a
URI identifies a resource as a whole -- not a specific representation of
that resource.

The idea that it may be okay for a URI to have multiple referents also
seems to conflict fundamentally with the principle that "By design, a
URI identifies one resource"[8] (regardless of context). If there
really is no conflict between these views, then I think the community as
a whole is badly in need of greater education to understand why not. I
know I am!

[4] WebArch on URI collision:
http://www.w3.org/TR/webarch/#URI-collision

[7] RFC 3986:
http://www.ietf.org/rfc/rfc3986.txt

[8] WebArch on indirect identification:
http://www.w3.org/TR/webarch/#indirect-identification

David Booth
Bernard Vatant
2006-01-31 09:30:57 UTC
Permalink
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
<font face="Courier New" size="-1">David<br>
<br>
</font>"RFC 3986 is very clear that a
URI identifies a resource as a whole -- not a specific representation
of
that resource."<br>
<br>
<font face="Courier New" size="-1">Agreed on that point. I did not
write that the resource is not uniquely defined by its URI. RFC 3986
has a completely circular or tautological (maybe I should not use that
word with logicians around)to put it, which opens no door to any other
interpretation.<br>
&nbsp;&nbsp;&nbsp; 1. A resource is whatever is identified by a URI<br>
&nbsp;&nbsp;&nbsp; 2. A URI identifies a single resource<br>
<br>
So what is identified is the resource. What is identification? RFC 3986
also says:<br>
</font><br>
"An identifier embodies the information required to distinguish what is
being identified from all other things within its scope of
identification."<br>
<br>
<font size="-1"><font face="Courier New">I'm curious BTW to know how
folks here understand "scope of identification"? Is it the whole of
possible process where URIs are used, that is the Web process at large,
plus all possible systems using URIs locally? Is it a given protocol,
such as e-mail, ftp, http? <br>
<br>
In any case, what I wrote is that the *referent* is not uniquely
*defined* (by a URI). Take the example of a person identified in many
ways in so many different contexts : e-mail address, phone number,
credit card number, SS number ... Each of those identifiers are used to
make the person distinct from other persons *in a given scope of
identification*. In each of those scopes, the resource bearing this
identifier and other properties, can be considered as a a proxy for the
person, but not the referent, the person herself, living in a realm
where identification makes no sense. This is what I understand from
Pat's point, if I catch it well : we should no confuse the resource
(which is uniquely identified by the URI and has formal descriptions)
and the referent (which is beyond the realm of identification). <br>
<br>
So the reference is always indirect:<br>
1. The URI identifies a resource<br>
2. The resource acts as a proxy of a referent<br>
<br>
Identification and other logical process take place at level 1. At
level 2, referents are, like Pat Hayes or Mount Everest, beyond all
possible identification or logical process. But that is not an issue.
It's the nature of things, "neti, neti". <br>
<br>
<br>
Cheers<br>
<br>
Bernard<br>
<br>
</font></font><font face="Courier New" size="-1"></font>
<div class="moz-signature">--<br>
<title></title>
<meta http-equiv="Content-Type" content="text/html; ">
<meta content="MSHTML 6.00.2900.2802" name="GENERATOR">
<font size="2">
<div align="left">
<p class="MsoNormal" style="margin: 0cm 0cm 0pt;"><strong><span
style="font-size: 11pt; color: gray; font-family: Arial;">Bernard
Vatant</span></strong></p>
<p class="MsoNormal" style="margin: 0cm 0cm 0pt;"><span
style="font-size: 10pt; color: gray; font-family: Arial;"></span><span
style="font-size: 11pt; color: gray; font-family: Arial;"><o:p><font
size="2">Knowledge Engineering</font></o:p></span></p>
<p class="MsoNormal" style="margin: 0cm 0cm 0pt;"><span
class="important1"><b><span
style="font-size: 11pt; font-family: Arial;" lang="EN"><font
color="#901b3f">Mondeca<span class="901565122-29122005"> </span></font></span></b></span><b><span
style="color: navy; font-family: Arial;"><br>
</span></b><span
style="font-size: 10pt; color: gray; font-family: Arial;">3, cit&eacute;
Nollez 75018 Paris <st1:place w:st="on"><st1:country-region w:st="on">France</st1:country-region></st1:place><o:p></o:p></span></p>
<p class="MsoNormal" style="margin: 0cm 0cm 0pt;"><span
style="font-size: 10pt; color: gray; font-family: Arial;" lang="EN-GB">Tel.
+33 (0) 871 488 459&nbsp;</span></p>
<p class="MsoNormal" style="margin: 0cm 0cm 0pt;"><span
style="font-size: 10pt; color: gray; font-family: Arial;" lang="EN-GB">Mail:
</span><span style="font-size: 10pt; color: gray; font-family: Arial;"><a
href="mailto:***@mondeca.com"><span
style="color: gray; text-decoration: none;" lang="EN-GB">***@mondeca.com</span></a></span><span
style="font-size: 10pt; color: gray; font-family: Arial;" lang="EN-GB"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin: 0cm 0cm 0pt;"><span
style="font-size: 10pt; color: navy; font-family: Arial;"><font
color="#000000">Web: </font><a href="http://www.mondeca.com"><span
style="color: navy;" lang="EN-GB">www.</span><span style="color: navy;">mondeca.com</span></a></span></p>
<p class="MsoNormal" style="margin: 0cm 0cm 0pt;"><span
style="font-size: 10pt; color: navy; font-family: Arial;"><font
color="#000000">Blog : <a href="http://universimmedia.blogspot.com">universimmedia.blogspot.com</a>
</font></span></p>
</div>
</font></div>
</body>
</html>
Jeremy Carroll
2006-01-31 10:47:28 UTC
Permalink
Bernard Vatant wrote:

> "An identifier embodies the information required to distinguish what is
> being identified from all other things within its scope of identification."
>


file://localhost/home/me/

has context specific reference and the world has not collapsed.
I believe this is what "scope of identification." is referring to.

Jeremy
John McClure
2006-01-31 21:59:29 UTC
Permalink
The primer states that RDF/A can be used in XML streams other than XHTML2
(the primer mentions XHTML1 and SVG). I am wondering if a sample to that
effect can be included using, for instance, Dublin Core elements ....

<foo:Person rdf:about='someURI'>
<dc:title rdfa:property='FullName'>Jon Doe</dc:title>
<dc:identifier rdfa:property='SSN'>999-99-9999</dc:identifier>
</foo:Person>

Please note that an rdfa: namespace is presumed necessary, unless one
expects every XML dialect to be as kind as XHTML has been to hardwire the
RDF/A attributes. Also note that the rdf: namespace is used for the 'about'
attribute.

Thanks
John
Ben Adida
2006-01-31 22:06:11 UTC
Permalink
John,

Yes, we set ourselves up for this one, didn't we! :)

I should point that the Primer is careful to say "one should be able
to use RDF/A with other XML dialects, e.g. XHTML1, SVG, given proper
schema additions." That's a bit of handwaving on our part.

We believe that RDF/A will be useful in other contexts, and will be
usable via XML Schema Modularization, but we have *not* done the
legwork to actually make that happen yet, and we probably don't want
to give the impression that RDF/A is immediately ready for use in
these other languages.

I assume from your comment that, at the very least, we need to make
the above points much clearer.

-Ben

On Jan 31, 2006, at 4:59 PM, John McClure wrote:

> The primer states that RDF/A can be used in XML streams other than
> XHTML2 (the primer mentions XHTML1 and SVG). I am wondering if a
> sample to that effect can be included using, for instance, Dublin
> Core elements ....
>
> <foo:Person rdf:about='someURI'>
> <dc:title rdfa:property='FullName'>Jon Doe</dc:title>
> <dc:identifier rdfa:property='SSN'>999-99-9999</dc:identifier>
> </foo:Person>
>
> Please note that an rdfa: namespace is presumed necessary, unless
> one expects every XML dialect to be as kind as XHTML has been to
> hardwire the RDF/A attributes. Also note that the rdf: namespace is
> used for the 'about' attribute.
>
> Thanks
> John
John McClure
2006-01-31 23:40:07 UTC
Permalink
Ben,
Hmm, it sounds like you're not willing to go there yet -- I wish you would
be though! -- and that you're leaning towards removing the statements
altogether if a "generic XML application" presents too many problems.

OK, a few other issues related to usage in XHTML2 not in any XML dialect.

1. The primer/spec should clearly state its relationship with Modular XHTML.
I suspect the XHTML2 crew is creating an optional module that contains the
RDF/A attributes; therefore the RDF/A attributes can be used in XHTML Family
document types other than just XHTML2. If not, then I'd suggest you contact
them to ensure it does perhaps requesting that it be named "RDFA" or
something. It's fortunate for RDF/A that the id and href attributes are
required in all Modular XHTML doctypes.

2. It's not clear that RDF/A attributes are used on XHTML2 namespace
elements, regardless of the type of XML entity in which they are located. In
other words, the XHTML2 elements are not necessarily located in XHTML2
entities; they can be located in any XML entity. I suggest an example of
this technique would be useful.

<foo:Document>
<html:section about='url'>
<span property='dc:title foo:FullName'>Jon Doe</span>
</html:section>
</foo:Document>

Please note that I still assume that the 'property' attribute is defined as
QNAMES, not just QNAME, in the module. If that is not to be, please tell me
why not. If it is, let me know so that I can stop asking about it.

3. An XHTML2-oriented guideline may have more gravitas if it were
co-authored with the XHTML2 WG. Within the text, I suggest readers be
directed to relevant information in the XHTML2 specification and, for the
RDF/A spec, you likely need to indicate which spec has precedence -- yours
or the XHTML2 spec -- and in what matters.

Thanks,
John
-----Original Message-----
From: Ben Adida [mailto:***@mit.edu]
Sent: Tuesday, January 31, 2006 2:06 PM
To: John McClure
Cc: public-swbp-***@w3.org
Subject: Re: [RDF/A] A non-XHTML Example




John,


Yes, we set ourselves up for this one, didn't we! :)


I should point that the Primer is careful to say "one should be able to
use RDF/A with other XML dialects, e.g. XHTML1, SVG, given proper schema
additions." That's a bit of handwaving on our part.


We believe that RDF/A will be useful in other contexts, and will be usable
via XML Schema Modularization, but we have *not* done the legwork to
actually make that happen yet, and we probably don't want to give the
impression that RDF/A is immediately ready for use in these other languages.


I assume from your comment that, at the very least, we need to make the
above points much clearer.


-Ben


On Jan 31, 2006, at 4:59 PM, John McClure wrote:


The primer states that RDF/A can be used in XML streams other than
XHTML2 (the primer mentions XHTML1 and SVG). I am wondering if a sample to
that effect can be included using, for instance, Dublin Core elements ....
<foo:Person rdf:about='someURI'>
<dc:title rdfa:property='FullName'>Jon Doe</dc:title>
<dc:identifier rdfa:property='SSN'>999-99-9999</dc:identifier>
</foo:Person>
Please note that an rdfa: namespace is presumed necessary, unless one
expects every XML dialect to be as kind as XHTML has been to hardwire the
RDF/A attributes. Also note that the rdf: namespace is used for the 'about'
attribute.
Thanks
John
Ben Adida
2006-02-03 04:54:06 UTC
Permalink
John,

Thanks for your detailed comments, again.

> Hmm, it sounds like you're not willing to go there yet -- I wish
> you would be though! -- and that you're leaning towards removing
> the statements altogether if a "generic XML application" presents
> too many problems.

Well, we certainly believe that RDF/A in other XML dialects is a good
idea, we just don't want to bite off more than we can chew (the task
force is small). Our feeling (or maybe it's just *my* feeling) is
that RDF/A should prove itself in XHTML before we claim that every
other dialect should adopt it. We have done the best we can to ensure
that this *can* happen at some point.

> 1. The primer/spec should clearly state its relationship with
> Modular XHTML. I suspect the XHTML2 crew is creating an optional
> module that contains the RDF/A attributes; therefore the RDF/A
> attributes can be used in XHTML Family document types other than
> just XHTML2. If not, then I'd suggest you contact them to ensure it
> does perhaps requesting that it be named "RDFA" or something. It's
> fortunate for RDF/A that the id and href attributes are required in
> all Modular XHTML doctypes.

Yes, the XHTML2 WG is definitely creating this as a module, and I
suspect they will explain this clearly in their specification. The
Primer should probably make it clear that while I'm on the SWBPD WG,
Mark Birbeck (co-author) is on the XHTML2 WG, so this is definitely
joint work.

> 2. It's not clear that RDF/A attributes are used on XHTML2
> namespace elements, regardless of the type of XML entity in which
> they are located. In other words, the XHTML2 elements are not
> necessarily located in XHTML2 entities; they can be located in any
> XML entity. I suggest an example of this technique would be useful.
>
> <foo:Document>
> <html:section about='url'>
> <span property='dc:title foo:FullName'>Jon Doe</span>
> </html:section>
> </foo:Document>
>
> Please note that I still assume that the 'property' attribute is
> defined as QNAMES, not just QNAME, in the module. If that is not to
> be, please tell me why not. If it is, let me know so that I can
> stop asking about it.

This is an interesting point we have not considered, whether property
can include multiple possibilities. We'll take it up in the TF.

> 3. An XHTML2-oriented guideline may have more gravitas if it were
> co-authored with the XHTML2 WG. Within the text, I suggest readers
> be directed to relevant information in the XHTML2 specification
> and, for the RDF/A spec, you likely need to indicate which spec has
> precedence -- yours or the XHTML2 spec -- and in what matters.

So, again, just to be clear, all of this work is co-authored with the
XHTML2 WG. Mark Birbeck and Steven Pemberton are on the TF. We should
make that much clearer, as we certainly could not have done this work
without their help.

-Ben
Booth, David (HP Software - Boston)
2006-01-31 17:06:04 UTC
Permalink
> From: Miles, AJ (Alistair) [mailto:***@rl.ac.uk]
>
> I think that, because no element with the id attribute value
> "me" is actually present in the document, then current
> specifications [3,4] do not allow any conclusions about the
> nature of <#me> to be drawn from the content-type of the document.

I don't think that's quite correct. The WebArch makes no requirement
that the fragment identifier actually exist in the retrieved document.
The dependency is on whether a *representation* exists when the primary
resource is dereferenced. From WebArch sec 3.2.1:
[[
The semantics of a fragment identifier are defined by the set of
representations that might result from a retrieval action on the primary
resource. The fragment's format and resolution are therefore dependent
on the type of a potentially retrieved representation, even though such
a retrieval is only performed if the URI is dereferenced. If no such
representation exists, then the semantics of the fragment are considered
unknown and, effectively, unconstrained.
]]

Thus, my interpretation of the WebArch is that if http://example.org/foo
returns application/xhtml+xml, then RFC3236 applies, which states:

". . . fragment identifiers for XHTML documents designate
the element with the corresponding ID attribute value".

If no such element exists, then http://example.org/foo#me identifies a
non-existent element. The fact that no such element actually exists
does not change the fact that that is what the URI identifies.

> . . .
> Please note my position given at [7]: 'I support publication
> of this document as a Working Draft'. I do not think the
> publication of RDF/A as Working Draft should be delayed
> because of this particular discussion thread.

I agree. I think the warning that Ben has added is adequate.

David Booth

>
> [3] http://www.w3.org/TR/2004/REC-webarch-20041215/#media-type-fragid
> [4] http://www.ietf.org/rfc/rfc3236.txt
> [5]
> http://lists.w3.org/Archives/Public/public-swbp-wg/2006Jan/0152.html
> [6]
> http://lists.w3.org/Archives/Public/public-swbp-wg/2006Jan/0153.html
> [7]
> http://lists.w3.org/Archives/Public/public-swbp-wg/2006Jan/0113.html
Jeremy Carroll
2006-01-31 17:50:02 UTC
Permalink
It is of course conceivable that we are identifying a bug with the web
architecture document rather than a bug in our use of URIs.

The space of URIs available for non-Information resources seems to be
getting smaller and smaller, soon the Semantic Web will be disallowed by
the Web Architecture document.

Jeremy

Booth, David (HP Software - Boston) wrote:
>
>> From: Miles, AJ (Alistair) [mailto:***@rl.ac.uk]
>>
>> I think that, because no element with the id attribute value
>> "me" is actually present in the document, then current
>> specifications [3,4] do not allow any conclusions about the
>> nature of <#me> to be drawn from the content-type of the document.
>
> I don't think that's quite correct. The WebArch makes no requirement
> that the fragment identifier actually exist in the retrieved document.
> The dependency is on whether a *representation* exists when the primary
> resource is dereferenced. From WebArch sec 3.2.1:
> [[
> The semantics of a fragment identifier are defined by the set of
> representations that might result from a retrieval action on the primary
> resource. The fragment's format and resolution are therefore dependent
> on the type of a potentially retrieved representation, even though such
> a retrieval is only performed if the URI is dereferenced. If no such
> representation exists, then the semantics of the fragment are considered
> unknown and, effectively, unconstrained.
> ]]
>
> Thus, my interpretation of the WebArch is that if http://example.org/foo
> returns application/xhtml+xml, then RFC3236 applies, which states:
>
> ". . . fragment identifiers for XHTML documents designate
> the element with the corresponding ID attribute value".
>
> If no such element exists, then http://example.org/foo#me identifies a
> non-existent element. The fact that no such element actually exists
> does not change the fact that that is what the URI identifies.
>
>> . . .
>> Please note my position given at [7]: 'I support publication
>> of this document as a Working Draft'. I do not think the
>> publication of RDF/A as Working Draft should be delayed
>> because of this particular discussion thread.
>
> I agree. I think the warning that Ben has added is adequate.
>
> David Booth
>
>> [3] http://www.w3.org/TR/2004/REC-webarch-20041215/#media-type-fragid
>> [4] http://www.ietf.org/rfc/rfc3236.txt
>> [5]
>> http://lists.w3.org/Archives/Public/public-swbp-wg/2006Jan/0152.html
>> [6]
>> http://lists.w3.org/Archives/Public/public-swbp-wg/2006Jan/0153.html
>> [7]
>> http://lists.w3.org/Archives/Public/public-swbp-wg/2006Jan/0113.html
>
>
>
Ben Adida
2006-01-31 18:02:30 UTC
Permalink
Continuing on this point, I guess that implies the following thing:

If http://example.com/foo resolves to an XHTML document, then http://
example.com/foo#bar can only be an information resource. However, if
http://example.com/foo resolves to an N3 document, then http://
example.com/foo#bar *can* be an information resource, because there
is no way to get a fragment of an N3 document.

The first consequence is that XHTML documents are somehow second-
class citizens to N3 in expressing semweb statements. That would be
truly unfortunate.

The second consequence is that the RDF type of a frag URI now depends
on the Mime Type of the non-frag URI. That seems bad, too.

-Ben

On Jan 31, 2006, at 12:50 PM, Jeremy Carroll wrote:

>
> It is of course conceivable that we are identifying a bug with the
> web architecture document rather than a bug in our use of URIs.
>
> The space of URIs available for non-Information resources seems to
> be getting smaller and smaller, soon the Semantic Web will be
> disallowed by the Web Architecture document.
>
> Jeremy
>
> Booth, David (HP Software - Boston) wrote:
>>> From: Miles, AJ (Alistair) [mailto:***@rl.ac.uk]
>>> I think that, because no element with the id attribute value "me"
>>> is actually present in the document, then current specifications
>>> [3,4] do not allow any conclusions about the nature of <#me> to
>>> be drawn from the content-type of the document.
>> I don't think that's quite correct. The WebArch makes no requirement
>> that the fragment identifier actually exist in the retrieved
>> document.
>> The dependency is on whether a *representation* exists when the
>> primary
>> resource is dereferenced. From WebArch sec 3.2.1:
>> [[
>> The semantics of a fragment identifier are defined by the set of
>> representations that might result from a retrieval action on the
>> primary
>> resource. The fragment's format and resolution are therefore
>> dependent
>> on the type of a potentially retrieved representation, even though
>> such
>> a retrieval is only performed if the URI is dereferenced. If no such
>> representation exists, then the semantics of the fragment are
>> considered
>> unknown and, effectively, unconstrained.
>> ]]
>> Thus, my interpretation of the WebArch is that if http://
>> example.org/foo
>> returns application/xhtml+xml, then RFC3236 applies, which states:
>> ". . . fragment identifiers for XHTML documents designate the
>> element with the corresponding ID attribute value". If no such
>> element exists, then http://example.org/foo#me identifies a
>> non-existent element. The fact that no such element actually exists
>> does not change the fact that that is what the URI identifies.
>>> . . .
>>> Please note my position given at [7]: 'I support publication of
>>> this document as a Working Draft'. I do not think the publication
>>> of RDF/A as Working Draft should be delayed because of this
>>> particular discussion thread.
>> I agree. I think the warning that Ben has added is adequate.
>> David Booth
>>> [3] http://www.w3.org/TR/2004/REC-webarch-20041215/#media-type-
>>> fragid
>>> [4] http://www.ietf.org/rfc/rfc3236.txt
>>> [5] http://lists.w3.org/Archives/Public/public-swbp-wg/2006Jan/
>>> 0152.html
>>> [6] http://lists.w3.org/Archives/Public/public-swbp-wg/2006Jan/
>>> 0153.html
>>> [7] http://lists.w3.org/Archives/Public/public-swbp-wg/2006Jan/
>>> 0113.html
>
>
>
Steven Pemberton
2006-02-01 12:16:46 UTC
Permalink
Ben Adida wrote:
> Continuing on this point, I guess that implies the following thing:
>
> If http://example.com/foo resolves to an XHTML document, then
> http://example.com/foo#bar can only be an information resource. However,
> if http://example.com/foo resolves to an N3 document, then
> http://example.com/foo#bar *can* be an information resource, because
> there is no way to get a fragment of an N3 document.
>
> The first consequence is that XHTML documents are somehow second-class
> citizens to N3 in expressing semweb statements. That would be truly
> unfortunate.
>
> The second consequence is that the RDF type of a frag URI now depends on
> the Mime Type of the non-frag URI. That seems bad, too.

Following on from what I believe Mark was saying at the last call,
http://example.com/foo may resolve to both an XHTML document *and* an N3
document (and many other things) depending on the accept: headers, so
http://example.com/foo#bar could represent (many) different things.

Steven

>
> -Ben
>
> On Jan 31, 2006, at 12:50 PM, Jeremy Carroll wrote:
>
>>
>> It is of course conceivable that we are identifying a bug with the web
>> architecture document rather than a bug in our use of URIs.
>>
>> The space of URIs available for non-Information resources seems to be
>> getting smaller and smaller, soon the Semantic Web will be disallowed
>> by the Web Architecture document.
>>
>> Jeremy
>>
>> Booth, David (HP Software - Boston) wrote:
>>>> From: Miles, AJ (Alistair) [mailto:***@rl.ac.uk]
>>>> I think that, because no element with the id attribute value "me" is
>>>> actually present in the document, then current specifications [3,4]
>>>> do not allow any conclusions about the nature of <#me> to be drawn
>>>> from the content-type of the document.
>>> I don't think that's quite correct. The WebArch makes no requirement
>>> that the fragment identifier actually exist in the retrieved document.
>>> The dependency is on whether a *representation* exists when the primary
>>> resource is dereferenced. From WebArch sec 3.2.1:
>>> [[
>>> The semantics of a fragment identifier are defined by the set of
>>> representations that might result from a retrieval action on the primary
>>> resource. The fragment's format and resolution are therefore dependent
>>> on the type of a potentially retrieved representation, even though such
>>> a retrieval is only performed if the URI is dereferenced. If no such
>>> representation exists, then the semantics of the fragment are considered
>>> unknown and, effectively, unconstrained.
>>> ]]
>>> Thus, my interpretation of the WebArch is that if http://example.org/foo
>>> returns application/xhtml+xml, then RFC3236 applies, which states:
>>> ". . . fragment identifiers for XHTML documents designate the
>>> element with the corresponding ID attribute value". If no such
>>> element exists, then http://example.org/foo#me identifies a
>>> non-existent element. The fact that no such element actually exists
>>> does not change the fact that that is what the URI identifies.
>>>> . . .
>>>> Please note my position given at [7]: 'I support publication of this
>>>> document as a Working Draft'. I do not think the publication of
>>>> RDF/A as Working Draft should be delayed because of this particular
>>>> discussion thread.
>>> I agree. I think the warning that Ben has added is adequate.
>>> David Booth
>>>> [3] http://www.w3.org/TR/2004/REC-webarch-20041215/#media-type-fragid
>>>> [4] http://www.ietf.org/rfc/rfc3236.txt
>>>> [5]
>>>> http://lists.w3.org/Archives/Public/public-swbp-wg/2006Jan/0152.html
>>>> [6]
>>>> http://lists.w3.org/Archives/Public/public-swbp-wg/2006Jan/0153.html
>>>> [7]
>>>> http://lists.w3.org/Archives/Public/public-swbp-wg/2006Jan/0113.html
>>
>>
>>
>
>
Jeremy Carroll
2006-02-01 12:42:44 UTC
Permalink
Steven Pemberton wrote:
> Following on from what I believe Mark was saying at the last call,
> http://example.com/foo may resolve to both an XHTML document *and* an N3
> document (and many other things) depending on the accept: headers, so
> http://example.com/foo#bar could represent (many) different things.
>

I feel this indicates a clean view of secondary resources. A secondary
resource is not a secondary resource directly derived from the primary
resource, but is a secondary resource derived from a representation of
the primary resource. Depending on which representation of the primary
resource you get, the secondary resource varies (but when multiple
representations all implement something to do with the same fragment it
is reasonable to expect some coherency)

Jeremy
Jeremy Carroll
2006-02-01 12:13:20 UTC
Permalink
Ben Adida wrote:
>
>
> Continuing on this point, I guess that implies the following thing:
>
> If http://example.com/foo resolves to an XHTML document, then
> http://example.com/foo#bar can only be an information resource. However,
> if http://example.com/foo resolves to an N3 document, then
> http://example.com/foo#bar *can* be an information resource, because
> there is no way to get a fragment of an N3 document.
>
> The first consequence is that XHTML documents are somehow second-class
> citizens to N3 in expressing semweb statements. That would be truly
> unfortunate.
>

It also seems to force a separation between the Web and SemWeb, which
seems to me to be wholly against my understanding of the spirit of our
activity.

So in my analysis of foaf identities of TBL, DanC and NormW in

http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2006Jan/0065

TimBL is distinguished by having a URI (with fragment) where the URI
(without fragment) only has an N3 and an RDF/XML representation. This
avoids the problem we are discussing but at the cost of if you find
Tim's URI for himself of:
http://www.w3.org/People/Berners-Lee/card#i
and stick it into a Web browser, then you get gibberish (unless you are
SemWeb enabled).

I like the interwovenness of Norm's URI for himself of:
http://norman.walsh.name/knows/who#norman-walsh
which works both as a Web URI and a SemWeb URI, and I would assert that
it works without any practical ambiguity. I see any claim that there is
ambiguity between the HTML version of the URI and the RDF/XML version as
largely dancing on pinheads, rather than any articulated
interoperability failure. I, of course, enjoying dancing, particularly
on pinheads ... but ... the goal to me is about making the SemWeb real
by leveraging the success of the Web. This requires that the URI spaces
for the Web and SemWeb are the same (or at least with large overlap),
and not disjoint.

I feel it is very important that the SWBPD and the SemWeb community
should resist an interpretation of WebArch that does not permit URIs to
be used both as operational instructions on the Web for finding text,
and as identifiers in SemWeb for arbitrary things. Such an
interpretation will be a significant obstacle to the take up of SemWeb.

Jeremy


[[Note: in the apparent differences of opinion between me and David
Booth, I hope it is clear that there is not yet an HP position, and each
of us are primarily speaking personally, rather than in a representative
capacity. I suspect that we will need to come to an 'HP' viewpoint
sooner or later.]]

PS Perhaps the resolution of this will be that if you want a URI to be
semweb enabled (at all) then your webserver should always give a 303 for
it .... (oh how horrid, but at least implementable)
Dan Connolly
2006-02-01 15:54:11 UTC
Permalink
On Tue, 2006-01-31 at 13:02 -0500, Ben Adida wrote:
>
> Continuing on this point, I guess that implies the following thing:
>
> If http://example.com/foo resolves to an XHTML document, then http://
> example.com/foo#bar can only be an information resource.

I don't believe that's the case. What suggests that it is?


--
Dan Connolly, W3C http://www.w3.org/People/Connolly/
D3C2 887B 0F92 6005 C541 0875 0F91 96DE 6E52 C29E
Booth, David (HP Software - Boston)
2006-02-01 17:58:16 UTC
Permalink
> From: Dan Connolly [mailto:***@w3.org]
>
> On Tue, 2006-01-31 at 13:02 -0500, Ben Adida wrote:
> > Continuing on this point, I guess that implies the following thing:
> >
> > If http://example.com/foo resolves to an XHTML document,
> > then http://example.com/foo#bar can only be an information resource.
>
> I don't believe that's the case. What suggests that it is?

I think Ben may have been a bit imprecise above. According to my read
of the WebArch and httpRange-14 decision, if http://example.com/foo
resolves to an XHTML document, then the resource that
http://example.com/foo#bar identifies *is* a location within an HTML
document. AFAIK this may not preclude it from *also* being a member of
some other class.

More explanation in my reply to Jeremy:
http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2006Feb/0005.
html

David Booth
Ben Adida
2006-02-03 05:03:54 UTC
Permalink
On Feb 1, 2006, at 12:58 PM, Booth, David (HP Software - Boston) wrote:

> I think Ben may have been a bit imprecise above. According to my read
> of the WebArch and httpRange-14 decision, if http://example.com/foo
> resolves to an XHTML document, then the resource that
> http://example.com/foo#bar identifies *is* a location within an HTML
> document. AFAIK this may not preclude it from *also* being a
> member of
> some other class.

Now I'm very confused.

I thought we were discussing whether a resource that *might* be an
HTML document *could* also be a non-information resource, say a
person. Let's take a precise example.

DanC's FOAF Person URI is <http://www.w3.org/People/Connolly/#me>,
but <http://www.w3.org/People/Connolly/> returns HTML, which makes
<http://www.w3.org/People/Connolly/#me> a (potential) HTML element.

DBooth, I thought you were saying that this is probably a bad thing,
assuming HTMLElement subclasses InformationResource, etc...

Did I misunderstand?

If DanC's setup is okay by the TAG, then I *think* that means that a
secondary resource can be a non-information resource, even when its
primary resource is an information resource. Someone correct me if
I've lost it.

-Ben
Dan Connolly
2006-02-03 14:41:30 UTC
Permalink
On Fri, 2006-02-03 at 00:03 -0500, Ben Adida wrote:
> On Feb 1, 2006, at 12:58 PM, Booth, David (HP Software - Boston) wrote:
[...]
> DanC's FOAF Person URI is <http://www.w3.org/People/Connolly/#me>,
> but <http://www.w3.org/People/Connolly/> returns HTML, which makes
> <http://www.w3.org/People/Connolly/#me> a (potential) HTML element.
>
> DBooth, I thought you were saying that this is probably a bad thing,
> assuming HTMLElement subclasses InformationResource, etc...
>
> Did I misunderstand?
>
> If DanC's setup is okay by the TAG,

I don't think the TAG endorses what I'm doing there.

The most relevant TAG issues are still open.
http://www.w3.org/2001/tag/issues#fragmentInXML-28
http://www.w3.org/2001/tag/issues#abstractComponentRefs-37

I'm starting to think that the profile attribute is key:
if you get an HTML representation of /baseballplayers
with <div id="peterose"> then baseballplayers#peterose
identifies that div element, unless the author says otherwise
using the <head profile> element.

This is a post-hoc refinement of the html media types
and the XHTML specs; i.e. I think those specs should
be ammendmended to specify this practice.

> then I *think* that means that a
> secondary resource can be a non-information resource, even when its
> primary resource is an information resource. Someone correct me if
> I've lost it.
>
> -Ben
--
Dan Connolly, W3C http://www.w3.org/People/Connolly/
D3C2 887B 0F92 6005 C541 0875 0F91 96DE 6E52 C29E
Booth, David (HP Software - Boston)
2006-02-04 04:57:52 UTC
Permalink
Cut to the chase: My best guess at this point is that the practice of
having http://www.w3.org/People/Connolly/#me identify both a location
within a document *and* a foaf:Person is NOT actually in conflict with
the WebArch, although the WebArch is confusing in this area. Full
explanation below.

> From: Ben Adida [mailto:***@mit.edu]
> . . .
> Now I'm very confused.
>
> I thought we were discussing whether a resource that *might* be an
> HTML document *could* also be a non-information resource, say a
> person. Let's take a precise example.
>
> DanC's FOAF Person URI is <http://www.w3.org/People/Connolly/#me>,
> but <http://www.w3.org/People/Connolly/> returns HTML, which makes
> <http://www.w3.org/People/Connolly/#me> a (potential) HTML element.

The httpRange-14 decision says that if an HTTP GET of
http://www.w3.org/People/Connolly/ returns a 2xx status, then
http://www.w3.org/People/Connolly/ is an "information resource".

The WebArch says that the meaning of the fragment identifier ("#me") is
determined by the media type that is returned. In the case of HTML, it
identifies a location with the HTML document. Therefore, according to
the WebArch plus the httpRange-14 decision,
http://www.w3.org/People/Connolly/#me identifies a location within an
HTML document.

If Dan is also using http://www.w3.org/People/Connolly/#me to identify a
foaf:Person, then the same URI is being used both to identify a
foaf:Person and an "information resource". Is this okay? Pat Hayes
does not see this as a problem, as he has eloquently explained.
However, the WebArch says that a URI should only identify one resource,
so my issue was this behavior seemed inconsistent with the WebArch.

On the other hand, the WebArch also says that if multiple media types
are served using content negotiation, then because the meaning of the
fragment identifier could differ for different media types, the URI
owner should ensure that all such meanings are "sufficiently
consistent"[1] (and hence conceptually would still only identify a
single resource). The WebArch also says that "The representation
provider decides when definitions of fragment identifier semantics are
are sufficiently consistent".

Is it reasonable to think that the use of
http://www.w3.org/People/Connolly/#me as a location within a document
would be "sufficiently consistent" with its use as a foaf:Person? I
would not have thought so, since, to me, a document seems very different
from a person. In fact, I could well imagine the class of
tag:Location-Within-An-HTML-Document as being owl:disjointWith
foaf:Person.

However, as Jeremy pointed out, there clearly is an intentional
relationship between them: the location within the HTML document
provides a human-readable description of the same foaf:Person. I.e., in
some sense, a coercion is possible between them. If this is the kind of
"consistency" that the TAG intended, then my concern about this practice
conflicting with the WebArch is unfounded. Also, I just ran across some
of TimBL's earlier thoughts[2] on the TAG's RDFinXHTML-35 issue[3], and
they give further evidence that this *is* the kind of "consistency" that
the TAG intended.

So my best guess at this point is that the practice of having
http://www.w3.org/People/Connolly/#me identify both a location within a
document *and* a foaf:Person is NOT actually in conflict with the
WebArch, although the WebArch is confusing in this area.

>
> DBooth, I thought you were saying that this is probably a bad thing,
> assuming HTMLElement subclasses InformationResource, etc...
>
> Did I misunderstand?

Answered above.

>
> If DanC's setup is okay by the TAG, then I *think* that means that a
> secondary resource can be a non-information resource, even when its
> primary resource is an information resource. Someone correct me if
> I've lost it.

That is definitely true. I don't think the debate was ever about that.
However, it depends on the *media* *type* that is returned -- not merely
on the fact that the primary resource is an information resource.

Ben, thanks for all your work on this. It's a very nice primer.

David Booth

[1] WebArch on fragment identifiers and content negotiation:
http://www.w3.org/TR/webarch/#frag-coneg

[2] TimBL thoughts on RDF in HTML:
http://www.w3.org/2002/04/htmlrdf

[3] TAG issue RDFinXHTML-35:
http://www.w3.org/2001/tag/issues.html#RDFinXHTML-35

[4] RDF/A Primer:
http://www.w3.org/2001/sw/BestPractices/HTML/2006-01-24-rdfa-primer

[5] Alistair's issues on URI usage in RDF/A primer:
http://lists.w3.org/Archives/Public/public-swbp-wg/2006Jan/0113.html
Booth, David (HP Software - Boston)
2006-02-04 05:06:44 UTC
Permalink
Ben,

Regarding the warning that you added to the RDF/A Primer, I suggest
substantially softening it along the lines of:
[[
There is some debate about whether the foaf examples are consistent with
the intended usage of the foaf ontology and/or the TAG's WebArch
guidance, because they use the same URI to identify both a foaf:Person
and a person's Web page (or location within a Web page). TAG issue
RDFinXHTML-35[1] seems relevant.
]]

[1] TAG issue RDFinXHTML-35:
http://www.w3.org/2001/tag/issues.html#RDFinXHTML-35

David Booth
Loading...