Simple Conneg scheme for RDFa sites

[Joachim]

Hi pedantics,

I wonder what you think about the following scheme for URIs and
content negotiation for RDFa sites:

1) a thing URI like http://example.com/xyz
2) an information resource URI http://example.com/xyz/about
3) a 303 redirect from the thing URI to the information resource URI,
e.g. http://example.com/xyz to http://example.com/xyz/about
4) files xyz/about.{lang}.html, xyz/about.{lang}.xhtml (a duplicate of
the former, served as application/xhtml+xml), xyz/about.{lang}.rdf,
etc.
5) let Apache (Option +MultiViews) figure out all the rest

An example .htaccess file for this setup is added below. For me, on
the site http://zbw.eu/beta/pm20/ it seems to work nicely.

Two minor flaws I spotted:
1) There seems to be no way to define a default mime type, so without
Accept header a random response is delivered, and a 406 when a non-
available type is requested. My feeling is that this should not hurt
too much.
2) RDFa pages to browsers are normally served as text/html. I see this
as a feature more than a bug, since it works with MSIE (as opposed to
application/xhtml+xml - which should be used according to the RDFa
spec).

I wonder if there are other disadvantages, or if the ones mentioned
above would overstretch your more sensitive and considerate side ;)

The main advantage of this setup, from my point of view, is that it's
really simple to implement, and that there are hardly things that can
be messed up by home-brewed rewrite rules. Furthermore, if desired you
can link directly to the specific pages (for example, to make an
explicit language choise by the user sticky).

Cheers, Joachim


Global setting (somewhere in /etc/httpd/conf.d/*):

Option +MultiViews

in .htaccess file within the application root:

# deliver en, when no or languages other than de are requested
LanguagePriority en de
ForceLanguagePriority Fallback

# ensure files are served with appropriate content types
# (if not present in main apache config)
AddType application/xhtml+xml .xhtml
AddType text/turtle .ttl
AddType application/rdf+xml .rdf

# Rewrite engine setup
RewriteEngine On
RewriteBase /beta/pm20

# rely on content negotiation
# 303 redirect for /beta/pm20
RewriteRule ^/?$ http://zbw.eu/beta/pm20/about [R=303,L]
# 303 redirect for URIs below /beta/pm20/person, ...
RewriteRule ^((person|company)(/[0-9]+)*)$ http://zbw.eu/beta/pm20/$1/about
[R=303,L]

[Richard Cyganiak]

Hi Joachim,

The approach you describe below only works for static files, which
makes it applicable only in a very narrow selection of scenarios. In
practice, almost everything on the web is dynamically generated.

As far as I can tell, your approach should work well in those rare
static scenarios.

That being said, I think when publishing RDFa it's so much easier to
just use hash URIs and drop the content negotiation stuff. That gives
you all the same benefits with much less complexity. The only cost is
slightly longer URIs and loss of compatibility with older clients that
speak only RDF/XML. (If you need language negotiation, then you'll
have to keep the conneg, but using hash URIs still allows you to
remove all the black magic from your htaccess.)

So personally I'd rather try to keep things as simple as possible, and
use </xyz#it> as subject URI, with files at </xyz.{lang}.html>.

(I don't know all the subtleties of text/html vs application/xhtml
+xml. Most RDFa parsers can deal with text/html just fine.)

Best,
Richard

[Thomas Baker]

Richard,

On Mon, Nov 23, 2009 at 01:01:34PM +0000, Richard Cyganiak wrote:
> The approach you describe below only works for static files, which
> makes it applicable only in a very narrow selection of scenarios. In
> practice, almost everything on the web is dynamically generated.
>
> As far as I can tell, your approach should work well in those rare
> static scenarios.
>
> That being said, I think when publishing RDFa it's so much easier to
> just use hash URIs and drop the content negotiation stuff. That gives
> you all the same benefits with much less complexity. The only cost is
> slightly longer URIs and loss of compatibility with older clients that
> speak only RDF/XML. (If you need language negotiation, then you'll
> have to keep the conneg, but using hash URIs still allows you to
> remove all the black magic from your htaccess.)

Have your views on this evolved since [1], and can you point to
a summary somewhere? I'm particularly interested in emerging
best practice for publishing large, continually growing
vocabularies.

Tom

[1] http://www.w3.org/TR/cooluris/

--
Tom Baker <tba...@tbaker.de>

[Joachim]

Hi Richard,

Thank you for your comments. You are right, this *is* an approach
limited to static files. It works well however if you want to serve
small to medium sized data sets, which are not dynamic in themselves
(thesauri or classifications, e.g.), and when you want to avoid
building an application which has to run on a server you do not own ;)
Generating the whole bunch of files and syncing it to some web dir is
so much easier than running - and debugging ... - an application in a
foreign environment.

For the ZBW press archives application with its millions and millions
of pages however I'll have to build such an application, so it's not
so far away - and I'll have to learn about REST frameworks and their
dealing with Accept-Header etc. Maybe I will reconsider the hash+html
only approach right then. For today, I hesitate to lock the RDF/XML
requesting clients out.

Maybe Michael could join in for the XHTML mime-type question.
According to the RDFa spec (chapter 4.1) the page SHOULD be delivered
as application/xhtml+xml. I don't want to do this by default since it
doesn't work in all but allegedly the newest (8.0) version of MSIE.
(There are workarrounds for this, but they are very messy). So
delivering text/html by default, but not returning a 406 when the
correct type is requested seems like a possible compromise.

Thanks again for all your work!

Cheers, Joachim

On 23 Nov., 14:01, Richard Cyganiak <rich...@cyganiak.de> wrote:
> Hi Joachim,
>
> The approach you describe below only works for static files, which  
> makes it applicable only in a very narrow selection of scenarios. In  
> practice, almost everything on the web is dynamically generated.
>
> As far as I can tell, your approach should work well in those rare  
> static scenarios.
>
> That being said, I think when publishing RDFa it's so much easier to  
> just use hash URIs and drop the content negotiation stuff. That gives  
> you all the same benefits with much less complexity. The only cost is  
> slightly longer URIs and loss of compatibility with older clients that  
> speak only RDF/XML. (If you need language negotiation, then you'll  
> have to keep the conneg, but using hash URIs still allows you to  
> remove all the black magic from your htaccess.)
>
> So personally I'd rather try to keep things as simple as possible, and  
> use </xyz#it> as subject URI, with files at </xyz.{lang}.html>.
>
> (I don't know all the subtleties of text/html vs application/xhtml
> +xml. Most RDFa parsers can deal with text/html just fine.)
>
> Best,
> Richard
>
> On 23 Nov 2009, at 11:17, Joachim wrote:
>
> > Hi pedantics,
>
> > I wonder what you think about the following scheme for URIs and
> > content negotiation for RDFa sites:
>

> > 1) a thing URI likehttp://example.com/xyz
> > 2) an information resource URIhttp://example.com/xyz/about

> > 3) a 303 redirect from the thing URI to the information resource URI,

> > e.g.http://example.com/xyztohttp://example.com/xyz/about

> > 4) files xyz/about.{lang}.html, xyz/about.{lang}.xhtml (a duplicate of
> > the former, served as application/xhtml+xml), xyz/about.{lang}.rdf,
> > etc.
> > 5) let Apache (Option +MultiViews) figure out all the rest
>
> > An example .htaccess file for this setup is added below. For me, on

> > the sitehttp://zbw.eu/beta/pm20/it seems to work nicely.

> > RewriteRule ^/?$http://zbw.eu/beta/pm20/about[R=303,L]

[Michael Hausenblas]

Joachim,

> Maybe Michael could join in for the XHTML mime-type question.
> According to the RDFa spec (chapter 4.1) the page SHOULD be delivered
> as application/xhtml+xml. I don't want to do this by default since it
> doesn't work in all but allegedly the newest (8.0) version of MSIE.
> (There are workarrounds for this, but they are very messy). So
> delivering text/html by default, but not returning a 406 when the
> correct type is requested seems like a possible compromise.

I can perfectly understand this compromise and IIRC this was one of the
reasons why we decided to have a SHOULD there and not a MUST.

Now, there are two components to it, IMHO: first, facing the reality of
browser vendors (esp. the ones who have a certain market share ;) and the
other one around the host language (think HTML5 [1], for example).

Could also be worth checking back with the people who provide/maintain
conneg libs [2] (Toby Inkster comes to mind ...) and in any case, definitely
worthwhile input for our RDFa/linked data tutorial [3]; rest assured that
you'll be credited ;)

Cheers,
Michael

[1] http://dev.w3.org/html5/rdfa/rdfa-module.html
[2] http://linkeddata.org/conneg-303-redirect-code-samples
[3] http://ld2sd.deri.org/lod-ng-tutorial/#checklist

--
Dr. Michael Hausenblas
LiDRC - Linked Data Research Centre
DERI - Digital Enterprise Research Institute
NUIG - National University of Ireland, Galway
Ireland, Europe
Tel. +353 91 495730
http://linkeddata.deri.ie/
http://sw-app.org/about.html

[Richard Cyganiak]

On 23 Nov 2009, at 14:10, Thomas Baker wrote:
>> That being said, I think when publishing RDFa it's so much easier to
>> just use hash URIs and drop the content negotiation stuff. That gives
>> you all the same benefits with much less complexity. The only cost is
>> slightly longer URIs and loss of compatibility with older clients
>> that
>> speak only RDF/XML. (If you need language negotiation, then you'll
>> have to keep the conneg, but using hash URIs still allows you to
>> remove all the black magic from your htaccess.)
>
> Have your views on this evolved since [1], and can you point to
> a summary somewhere?

[1] was first written before RDFa was ready for prime time, so content
negotiation was required if a URI was to be usable both in a web
browser and in an RDF client.

The following is all just my personal opinion. In my experience,
getting content negotiation right is difficult, and it's a persistent
source of interoperability problems. At the same time, I perceive the
303 approach as more complex than the hash approach. With hindsight, I
think it's a bit unfortunate that “303 + conneg to HTML and RDF” has
become the “canonical” way of deploying RDF on the Web, because it's
complex and error-prone, and there are simpler methods. The focus on
“303 + conneg” has created a perception that deploying RDF is harder
than it actually is.

With RDFa, we're in the happy situation that there is a selection of
technologies that make it possible to do away with all the complex
server configuration around content negotiation and 303 redirects. So
RDFa plus hash URIs hits a sweet spot in many situations.

> I'm particularly interested in emerging
> best practice for publishing large, continually growing
> vocabularies.

I think that the question of “hash vs. slash” and “RDFa vs. HTML+RDF/
XML” is largely orthogonal to the question of the size or change rate
of the dataset. You could use <items/3234584235> which 303s to a
describing document specific to that resource; or you could use <items/
3234584235.html#it> without 303s and conneg. I would use the latter if
I wanted to keep my server setup simple and if I can live with the
slightly uglier URIs.

Best,
Richard

[Thomas Baker]

On Tue, Nov 24, 2009 at 11:40:58AM +0000, Richard Cyganiak wrote:
> >>That being said, I think when publishing RDFa it's so much easier to
> >>just use hash URIs and drop the content negotiation stuff. That gives
> >>you all the same benefits with much less complexity. The only cost is
> >>slightly longer URIs and loss of compatibility with older clients
> >>that
> >>speak only RDF/XML. (If you need language negotiation, then you'll
> >>have to keep the conneg, but using hash URIs still allows you to
> >>remove all the black magic from your htaccess.)
> >
> >Have your views on this evolved since [1], and can you point to
> >a summary somewhere?
>
> [1] was first written before RDFa was ready for prime time, so content
> negotiation was required if a URI was to be usable both in a web
> browser and in an RDF client.

Hi Richard,

If Cool URIs ([1]) no longer reflects current opinion, is there
an updated document somewhere that describes the RDFa approach
in more detail (i.e., in terms of Web architecture)?

> I think that the question of ?hash vs. slash? and ?RDFa vs. HTML+RDF/
> XML? is largely orthogonal to the question of the size or change rate

> of the dataset. You could use <items/3234584235> which 303s to a
> describing document specific to that resource; or you could use <items/
> 3234584235.html#it> without 303s and conneg. I would use the latter if
> I wanted to keep my server setup simple and if I can live with the
> slightly uglier URIs.

I'm talking to a large international organization that wants
to put a thesaurus onto the Web as Linked Data, and based on
my understanding of the "state of the art", I'm inclined to
suggest they follow the example of ID.LOC.GOV, which resolves
the SKOS concept identifier:

http://id.loc.gov/authorities/sh00000382#concept

...to the document

http://id.loc.gov/authorities/sh00000382

However, both of these URIs gets the response code "HTTP/1.1
200 OK". BBC seems to take the same approach with the hash URI
http://www.bbc.co.uk/music/artists/a3cb23fc-acd3-4ce0-8f36-1e5aa6a18432#artist,
which also gets 200 OK.

I understand the part about a hash URI being acceptable
because "a URI that includes a hash cannot be retrieved
directly, and therefore does not necessarily identify a
Web document". However, if the httpRange-14 decision [2] says:

If an "http" resource responds to a GET request with a
2xx response, then the resource identified by that URI
is an information resource

...is the response code not saying that sh00000382#concept is an
information resource?

I contrast this to

http://www.w3.org/2004/02/skos/core#related
http://xmlns.com/foaf/0.1/knows

...both of which get HTTP/1.1 303 See Other.

Based on my understanding of the state of discussion, I want
to recommend id.loc.gov-style URIs for the large concept scheme
-- using numbers as identifiers for concepts, and presenting
them one concept per Web page, as with Library of Congress
Subject Headings.

For the property and class vocabularies, I want to recommend
either the hash style (like SKOS) or the slash style
(like FOAF), either way using recognizable words such as
"subject", "knows", or "prefLabel" (or is anyone recommending
a "knows#property" approach to forming URIs in property
vocabularies?). Whether property and class vocabularies
are presented using conneg (like SKOS) or RDFa (like FOAF)
seems orthogonal to the naming convention (indeed, ID.LOC.GOV
offers both).

But I am worried about your point that "If you need language
negotiation, then you'll have to keep the conneg", because
the thesaurus in question has labels translated into many
languages. And I am a bit worried about the interpretation
of a hash URI that gets a 200 OK response, especially
if the document in question were to have an id="concept"
attribute somewhere as a positional anchor. Also, is it
safer (or friendlier) to follow LC's example and provide RDFa
_as_well_as_ an "Accept: application/rdf+xml" alternative?

Have these various alternatives been summarized somewhere, or
is there perhaps a need for a revised and expanded Cool URIs?

Tom

[1] http://www.w3.org/TR/cooluris/
[2] http://lists.w3.org/Archives/Public/www-tag/2005Jun/0039.html

--
Tom Baker <tba...@tbaker.de>


--
Subscription settings: http://groups.google.com/group/pedantic-web/subscribe?hl=en

[Jonathan Rees]

Hi Richard -

Could you send me examples of use of RDFa that you find exemplary,
along the lines you gave? That is, RDFa as a substitute for HTML/RDF
conneg. I think this is a great idea if it can be made to work.

I've been avoiding this use of RDFa because RFC 3236 says that URIrefs
with fragment ids refer to XML elements. Maybe I'm just being overly
pedantic though.

Best
Jonathan

[Damian Steer]

On 23 Apr 2010, at 01:02, Jonathan Rees wrote:

> I've been avoiding this use of RDFa because RFC 3236 says that URIrefs
> with fragment ids refer to XML elements. Maybe I'm just being overly
> pedantic though.

I think it's more like: the fragment refers to the corresponding element. If there is no such element then it doesn't refer to an element.

So, in the absence of an id 'me' in this document:

...
<body about="#me" xmlns:foaf="http://xmlns.com/foaf/0.1/" typeof="foaf:Person">
<h1 property="foaf:name">Damian</h1>
...

The name is of BASE#me, a foaf:Person, but that isn't an element.

It feels like we tread a delicate line here, but so far it's working.

Damian

[Ed Summers]

Hi Tom,

When I was initially developing id.loc.gov at lcsh.info Dan Brickley
raised some concern about the use of hash fragment URIs in conjunction
with RDFa [1]. David Booth's response at the time [2] gave me some
comfort, and made me make a mental note not to not include an 'id'
attribute in an rdfa xhtml document that was the same as the fragment
portion of a non-information resource URI.

Other than that thread I haven't received any feedback indicating we
were doing anything wrong using URIs like:

http://id.loc.gov/authorities/sh95000541#concept

to identify non-information resources aka "things" [3]. As you pointed
out the rationale for using the hash fragment can be found in the Cool
URIs for the Semantic Web document [4].

On the subject of multiple language representations and SKOS I would
personally try to avoid minting language specific URIs for the SKOS
concepts themselves. An example of doing this can be found in
dewey.info [5]

--
<http://dewey.info/class/641/2009/08/about.en>
a skos:Concept ;
skos:prefLabel "Food & drink"@en ;
cc:attributionName "OCLC Online Computer Library Center, Inc." ;
cc:attributionURL <http://www.oclc.org/dewey/> ;
cc:morePermissions <http://www.oclc.org/dewey/about/licensing/> ;
dct:isVersionOf <http://dewey.info/class/641/> ;
dct:language "en"^^dct:RFC4646 ;
xhv:license <http://creativecommons.org/licenses/by-nc-nd/3.0/> ;
skos:broader <http://dewey.info/class/64/2009/08/about.en> ;
skos:inScheme <http://dewey.info/scheme/2009/08/about.en> ;
skos:notation "641"^^<http://dewey.info/schema-terms/Notation> .

<http://dewey.info/class/641/2009/08/about.fr>
a skos:Concept ;
skos:prefLabel "Nourriture et boisson"@fr ;
cc:attributionName "OCLC Online Computer Library Center, Inc." ;
cc:attributionURL <http://www.oclc.org/dewey/> ;
cc:morePermissions <http://www.oclc.org/dewey/about/licensing/> ;
dct:isVersionOf <http://dewey.info/class/641/> ;
dct:language "fr"^^dct:RFC4646 ;
xhv:license <http://creativecommons.org/licenses/by-nc-nd/3.0/> ;
skos:broader <http://dewey.info/class/64/2009/08/about.fr> ;
skos:inScheme <http://dewey.info/scheme/2009/08/about.fr> ;
skos:notation "641"^^<http://dewey.info/schema-terms/Notation> .
--

Personally I would've preferred to see the i18n features in SKOS [6]
used, and there being a single, language neutral URI for concepts:

--
<http://dewey.info/class/641/2009/08/about>
a skos:Concept ;
skos:prefLabel "Food & drink"@en ;
skos:prefLabel "Nourriture et boisson"@fr .
cc:attributionName "OCLC Online Computer Library Center, Inc." ;
cc:attributionURL <http://www.oclc.org/dewey/> ;
cc:morePermissions <http://www.oclc.org/dewey/about/licensing/> ;
dct:isVersionOf <http://dewey.info/class/641/> ;
dct:language "en"^^dct:RFC4646 ;
xhv:license <http://creativecommons.org/licenses/by-nc-nd/3.0/> ;
skos:broader <http://dewey.info/class/64/2009/08/about> ;
skos:inScheme <http://dewey.info/scheme/2009/08/about> ;
skos:notation "641"^^<http://dewey.info/schema-terms/Notation> .

--

//Ed

[1] http://markmail.org/message/nazjzbygg5ys6s3j
[2] http://markmail.org/message/si7sd4vjlbwickzr
[3] http://www.w3.org/DesignIssues/LinkedData.html
[4] http://www.w3.org/TR/2007/WD-cooluris-20071217/#hashuri
[5] http://dewey.info/class/641/about.rdf
[6] http://www.w3.org/TR/skos-reference/#L1567

[Richard Cyganiak]

Thomas,

On 21 Apr 2010, at 15:57, Thomas Baker wrote:
> If Cool URIs ([1]) no longer reflects current opinion, is there
> an updated document somewhere that describes the RDFa approach
> in more detail (i.e., in terms of Web architecture)?

No. This is worth writing down though; I'll see what I can do.

> I'm inclined to
> suggest they follow the example of ID.LOC.GOV, which resolves
> the SKOS concept identifier:
>
> http://id.loc.gov/authorities/sh00000382#concept
>
> ...to the document
>
> http://id.loc.gov/authorities/sh00000382
>
> However, both of these URIs gets the response code "HTTP/1.1
> 200 OK".

No. The first URI cannot be resolved via HTTP, and hence a server
cannot return a status code for it. Quote RFC 3986 [1]:

“As such, the fragment identifier is not used in the scheme-specific
processing of a URI; instead, the fragment identifier is separated
from the rest of the URI prior to a dereference, and thus the
identifying information within the fragment itself is dereferenced
solely by the user agent, regardless of the URI scheme.”

In other words, your HTTP client actually sends just the part before
the hash, and then it's up to your client to study the response and
make sense of the hash part. Thus, the hash is interpreted client-side
and plays no part in the HTTP protocol.

> I understand the part about a hash URI being acceptable
> because "a URI that includes a hash cannot be retrieved
> directly, and therefore does not necessarily identify a
> Web document". However, if the httpRange-14 decision [2] says:
>
> If an "http" resource responds to a GET request with a
> 2xx response, then the resource identified by that URI
> is an information resource
>
> ...is the response code not saying that sh00000382#concept is an
> information resource?

No, the response code says that sh00000382 is an information resource.
(And sh00000382#concept is whatever sh00000382 says it is.)

> I contrast this to
>
> http://www.w3.org/2004/02/skos/core#related
> http://xmlns.com/foaf/0.1/knows
>
> ...both of which get HTTP/1.1 303 See Other.

It's not skos:related that responds with 303, but it's the <.../core>
that responds with 303. This is actually unnecessary, the <.../core>
URI could just implement normal redirect-less content negotiation,
because all the involved HTTP-retrievable URIs (<core>, <core.rdf>,
<core.html>) are information resources, and the latter two are
variants (representations) of the former.

> Have these various alternatives been summarized somewhere, or
> is there perhaps a need for a revised and expanded Cool URIs?

I'm unaware of a document that discusses these issues and takes RDFa
into account.

From a strategic POV, it would make sense to start some work towards
a new document about deploying RDF on the web, that includes the
lessons learned since Cool URIs and How to Publish were written. This
should perhaps happen outside of W3C though for now. Currently there
is an active RDFa working group, and there is talk about restarting
the RDF Core working group to iron out some of the problems of the
original 2004 set of specifications. When those efforts have yielded
some results, then would perhaps be an excellent time for an
architecture-level document that focuses on best practices for RDF
publishing.

Best,
Richard

[Thomas Baker]

Thank you, Richard,

On Sun, Apr 25, 2010 at 03:03:26PM -0400, Richard Cyganiak wrote:
> In other words, your HTTP client actually sends just the part before
> the hash, and then it's up to your client to study the response and
> make sense of the hash part. Thus, the hash is interpreted client-side

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

> and plays no part in the HTTP protocol.

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
I was looking for confirmation of precisely this point.

> >Web document". However, if the httpRange-14 decision [2] says:
> >
> > If an "http" resource responds to a GET request with a
> > 2xx response, then the resource identified by that URI
> > is an information resource
> >
> >...is the response code not saying that sh00000382#concept is an
> >information resource?
>
> No, the response code says that sh00000382 is an information resource.
> (And sh00000382#concept is whatever sh00000382 says it is.)

That is indeed what I thought, but in the context of the
httpRange14 decision, the words "that URI" arguably gloss
over this key point -- i.e., the text does not say "that URI
(minus any fragment identifiers)".

> >I contrast this to
> >
> > http://www.w3.org/2004/02/skos/core#related
> > http://xmlns.com/foaf/0.1/knows
> >
> >...both of which get HTTP/1.1 303 See Other.
>
> It's not skos:related that responds with 303, but it's the <.../core>
> that responds with 303. This is actually unnecessary,

If true, then I can attest that this compounded my confusion
by seeming to reinforce the need to respond to a GET request
to "that URI" with 303.

> the <.../core>
> URI could just implement normal redirect-less content negotiation,
> because all the involved HTTP-retrievable URIs (<core>, <core.rdf>,
> <core.html>) are information resources, and the latter two are
> variants (representations) of the former.

Right.

> >Have these various alternatives been summarized somewhere, or
> >is there perhaps a need for a revised and expanded Cool URIs?
>
> I'm unaware of a document that discusses these issues and takes RDFa
> into account.

There is a clear need.

> From a strategic POV, it would make sense to start some work towards
> a new document about deploying RDF on the web, that includes the
> lessons learned since Cool URIs and How to Publish were written. This
> should perhaps happen outside of W3C though for now.

Even a wiki page would help. Right now, I wouldn't know where to
point. This could be done in three or four paragraphs, but they
should be citable.

> Currently there
> is an active RDFa working group, and there is talk about restarting
> the RDF Core working group to iron out some of the problems of the
> original 2004 set of specifications. When those efforts have yielded
> some results, then would perhaps be an excellent time for an
> architecture-level document that focuses on best practices for RDF
> publishing.

I agree, but that will take some time. In the meantime, a
description of the problem with pointers to implementations
such as FOAF, id.loc.gov, BBC, etc, would help. Maybe the
RDFa Working Group could take this on as a short Note, or perhaps
as an aspect of the tentatively planned RDFa Usage Cookbook [1].

Tom

[1] http://www.w3.org/2010/02/rdfa/

[Michael Hausenblas]

Thomas,

>> In other words, your HTTP client actually sends just the part before
>> the hash, and then it's up to your client to study the response and
>> make sense of the hash part. Thus, the hash is interpreted client-side
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> and plays no part in the HTTP protocol.
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> I was looking for confirmation of precisely this point.

You're not alone [1] ;)

> Even a wiki page would help. Right now, I wouldn't know where to
> point. This could be done in three or four paragraphs, but they
> should be citable.

Maybe use [2] for now - happy to extend it.

Cheers,
Michael

[1] http://lists.w3.org/Archives/Public/ietf-http-wg/2010AprJun/0069.html
[2] http://esw.w3.org/RDFa_vs_RDFXML

--
Dr. Michael Hausenblas
LiDRC - Linked Data Research Centre
DERI - Digital Enterprise Research Institute
NUIG - National University of Ireland, Galway
Ireland, Europe
Tel. +353 91 495730
http://linkeddata.deri.ie/
http://sw-app.org/about.html

> From: Thomas Baker <tba...@tbaker.de>
> Reply-To: Pedantic Web Group <pedant...@googlegroups.com>
> Date: Mon, 26 Apr 2010 06:11:59 -0400
> To: Pedantic Web Group <pedant...@googlegroups.com>

[Nathan]

Michael Hausenblas wrote:
> Thomas,
>
>>> In other words, your HTTP client actually sends just the part before
>>> the hash, and then it's up to your client to study the response and
>>> make sense of the hash part. Thus, the hash is interpreted client-side
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>> and plays no part in the HTTP protocol.
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> I was looking for confirmation of precisely this point.
>
> You're not alone [1] ;)

Yup I had a long conversation over on IETF about it too [3] - turns out
that #fragments are allowed in the Location header, but not the
request-target, so you can GET /foo/bar - which can 303 through to
Location: /bar#nugget

Which leads to the weird scenario of putting the following in your
address bar:

http://egg.com/foo/bar#baz

which will "request"

http://egg.com/foo/bar

which will redirect to:

http://egg.com/bar#nugget

which leads to a rather weirdy situation as you'll find in the
discussion below.

But point is, fragments are in the HTTP protocol, 2616 and HTTPbis, just
not in the request-target - still doesn't make much sense to me but..

>> Even a wiki page would help. Right now, I wouldn't know where to
>> point. This could be done in three or four paragraphs, but they
>> should be citable.
>
> Maybe use [2] for now - happy to extend it.
>
> Cheers,
> Michael
>
> [1] http://lists.w3.org/Archives/Public/ietf-http-wg/2010AprJun/0069.html
> [2] http://esw.w3.org/RDFa_vs_RDFXML
>

[3] http://lists.w3.org/Archives/Public/ietf-http-wg/2010JanMar/0293.html

Best,

Nathan

[Michael Hausenblas]

Thomas, All,

Re-reading AWWW sec '3.2.1. Representation types and fragment identifier
semantics' [1] and '3.2.2. Fragment identifiers and content negotiation' [2]
I think the issue is covered already from a Web architecture point-of-view.

Would you agree with this?

Cheers,
Michael

[1] http://www.w3.org/TR/webarch/#media-type-fragid
[2] http://www.w3.org/TR/webarch/#frag-coneg

--
Dr. Michael Hausenblas
LiDRC - Linked Data Research Centre
DERI - Digital Enterprise Research Institute
NUIG - National University of Ireland, Galway
Ireland, Europe
Tel. +353 91 495730
http://linkeddata.deri.ie/
http://sw-app.org/about.html



> From: Thomas Baker <tba...@tbaker.de>
> Reply-To: Pedantic Web Group <pedant...@googlegroups.com>
> Date: Mon, 26 Apr 2010 06:11:59 -0400
> To: Pedantic Web Group <pedant...@googlegroups.com>
> Cc: Ed Summers <ed...@loc.gov>, Ivan Herman <iv...@w3.org>, Manu Sporny
> <msp...@digitalbazaar.com>, Ben Adida <b...@mit.edu>
> Subject: Re: [pedantic-web] Simple Conneg scheme for RDFa sites
>

[Michael Hausenblas]

Thomas, All,

FYI: I've now created a new page on the ESW Wiki [1] which aims at
clarifying the issues discussed here wrt Web architecture. Any comments
welcome ;)

Please note that this is only a start and should motivate more work in this
area, as proposed by Richard (re lessons learned, good practices, example
deployments, etc.).

Cheers,
Michael

[1] http://esw.w3.org/RDFaHashURIs

--
Dr. Michael Hausenblas
LiDRC - Linked Data Research Centre
DERI - Digital Enterprise Research Institute
NUIG - National University of Ireland, Galway
Ireland, Europe
Tel. +353 91 495730
http://linkeddata.deri.ie/
http://sw-app.org/about.html



> From: Thomas Baker <tba...@tbaker.de>
> Reply-To: Pedantic Web Group <pedant...@googlegroups.com>
> Date: Mon, 26 Apr 2010 06:11:59 -0400
> To: Pedantic Web Group <pedant...@googlegroups.com>
> Cc: Ed Summers <ed...@loc.gov>, Ivan Herman <iv...@w3.org>, Manu Sporny
> <msp...@digitalbazaar.com>, Ben Adida <b...@mit.edu>
> Subject: Re: [pedantic-web] Simple Conneg scheme for RDFa sites
>

[Damian Steer]

On 27/04/10 11:56, Michael Hausenblas wrote:
>
> Thomas, All,
>
> FYI: I've now created a new page on the ESW Wiki [1] which aims at
> clarifying the issues discussed here wrt Web architecture. Any comments
> welcome ;)

One comment:

"Let us assume that the server has both RDFa and RDF/XML representations
for the resource http://example.com/alice available."

Ok, but that seems like you're begging the question. Suppose there
aren't, which is the typical case (being much easier to publish). None
of the cited recommendations are relevant to that case.

Damian

[Dan Brickley]

On Fri, Apr 23, 2010 at 10:00 AM, Damian Steer <pl...@mac.com> wrote:
>
> On 23 Apr 2010, at 01:02, Jonathan Rees wrote:
>
>> I've been avoiding this use of RDFa because RFC 3236 says that URIrefs
>> with fragment ids refer to XML elements. Maybe I'm just being overly
>> pedantic though.
>
> I think it's more like: the fragment refers to the corresponding element. If there is no such element then it doesn't refer to an element.
>
> So, in the absence of an id 'me' in this document:
>
> ...
> <body about="#me" xmlns:foaf="http://xmlns.com/foaf/0.1/" typeof="foaf:Person">
>  <h1 property="foaf:name">Damian</h1>
> ...
>
> The name is of BASE#me, a foaf:Person, but that isn't an element.
>
> It feels like we tread a delicate line here, but so far it's working.

Here's a design I have been wondering about:

<body about="#!me" xmlns:foaf="http://xmlns.com/foaf/0.1/" typeof="foaf:Person">

 <h1 property="foaf:name">Damian</h1>

Note the "#!me", intended more in the tradition of
http://en.wikipedia.org/wiki/Shebang_(Unix) than as negation. Idea
being that if we identify some characters that are legal in URI
References but not suited to be HTML IDs, then we loosen some
coordination problems and increase copy-and-pastability: you could
paste such a fragment into any HTML context without worrying that it
clashed with HTML IDs. Of course there are other things that could go
wrong (eg. accidental smushing if the page has another about="#!me")
but fencing our IDs off from HTMLs seems like a good start.

I'd like to be able to include an RDFa example in the FOAF spec that
gave a # fragment to the Person, in a manner that wasn't mixed up with
HTML ids. Am I right in thinking we use this sort of prefixing trick
to avoid clashes?

If so, what prefixes are available and attractive?

Dan

[Michael Hausenblas]

All,

FYI, Damian and I continued the discussion on IRC [1].

> One comment:
>
> "Let us assume that the server has both RDFa and RDF/XML representations
> for the resource http://example.com/alice available."
>
> Ok, but that seems like you're begging the question. Suppose there
> aren't, which is the typical case (being much easier to publish). None
> of the cited recommendations are relevant to that case.

Indeed. I *think* we agreed in the discussion on IRC that RFC3236 doesn't
tell us what should happen if the fragment ID used in the URI does NOT
correspond to an @id value of an HTML element.

Nevertheless, the applied principle of orthogonality [2] and the relevant
sections in AWWW (re frag Ids and conneg) suggest that where there is no
corresponding @id on an HTML element, the URI frag identifies whatever the
publisher's intention is.

Cheers,
Michael

[1] http://chatlogs.planetrdf.com/swig/2010-04-27.html#T11-55-45-1
[2] http://www.w3.org/TR/webarch/#orthogonal-specs

--
Dr. Michael Hausenblas
LiDRC - Linked Data Research Centre
DERI - Digital Enterprise Research Institute
NUIG - National University of Ireland, Galway
Ireland, Europe
Tel. +353 91 495730
http://linkeddata.deri.ie/
http://sw-app.org/about.html

> From: Damian Steer <pl...@mac.com>
> Reply-To: Pedantic Web Group <pedant...@googlegroups.com>
> Date: Tue, 27 Apr 2010 12:08:18 +0100
> To: Pedantic Web Group <pedant...@googlegroups.com>
> Subject: Re: [pedantic-web] Simple Conneg scheme for RDFa sites
>