See also: IRC log
<danbri> Copied a blog post to to the SWBP list on how the FOAF namespace currently works: http://lists.w3.org/Archives/Public/public-swbp-wg/2005Oct/0187.html (I s/\//#/ in the post subsequently)
tom: The URI of a MARC Relator term resolves to a Web page that just defines that one term. Using content negotiation would also allow resolution to RDF... But from the user point of view it is quite nice, because the user gets just the bit they're looking for... For example, dereferencing http://www.loc.gov/loc.terms/relators/ILL returns the label and definition of just one term. The HTML is (I believe) generated from a database.
danbri: I had forgotten that option, sounds attractive ... This leaves lots of space on the page for (potentially) other stuff, e.g. status metadata, translations, context, versioning information.
tom: I like the principle that the URI for a term resolves to a human-readable depiction of that term ... Can we agree on this as a guiding principal?
<Alistair> A single Apache directive should be able to give an Apache redirection match to the HTML. Should be same as I'm using for SKOS except it uses a regex. Asking for HTML causes a redirect, which uses part of the request URI in the redirected URI
<DanBri> Does an RDF client always get one big document?
<Alistair> Have options; can make a request for application/rdf+xml to return anything we want -- independently of a request for text/html. The practicality of each option depends on how big the vocabulary itself is and some user considerations.
tom: Another option on html side is to have one big document and go to one part of that doc ...
<RalphS> ... except that for "/" namespaces you can't redirect to a specific point in a document because of #-encoding.
<DanBri> dublincore.org returns a redirect containing '#'. This might not be possible with some Apache versions.
<Alistair> Could this lead to situations where the client sees two fragments?
<RalphS> I think we should accept the apache constraints and work around them. We may need to have many small HTML documents and this would be the right solution.
<danbri> see http://chatlogs.planetrdf.com/swig/2005-10-25.html#T09-08-08 for a log of what PURL DC does.
<Tom> Are we agreed that it is nice to resolve the URI of a term to that single term? Even if the server requires a single document per term?
<danbri> PURL DC behaviour above was http 1.0; here's the http 1.1 headers:
Content-Type: text/html; charset=iso-8859-1
<Alistair> Appears that loc.gov/loc.terms/ is using Cocoon to either query a database or transform an XML document.
<Tom> LOC does have RDF descriptions, they're just located at different URIs -- with .rdf appended.
<Alistair> I expect most installations would manage the RDF form in an RDF service. Could write a velocity servlet, for example; this would be a more advanced solution. Small static pages would also work. Fine for the URI of a term to resolve to a small bit of HTML describing only that term. Another possibility: run an XSLT program over a SPARQL query result.
bernard: How does the
human user being redirected know that there are other
representations? How do you know what request the client
is making? Before making the request, the user may not
know what representations are available. For example,
with SKOS example, you should be able to find out what
representations are available before making a blind
Question is: is you have different aspects (representations) available for a resource, there is no way of knowing before hand which are available. This description should be available; it's part of the description of the resource. The user does not have access e.g. to the type-map file ...
ralph: Given a URI for a class or prop, do we want to serve multiple representations at that URI? ... This is different from asking: if there are other representations, in what way should those other URIs cite the URI of the term. It is quite reasonable for an application to assume they can dereference URI of class or prop using preferred set of representation types -- i.e. you can ask for html first, rdf/xml second, so client doesn't need to guess what are available, it lists the things its willing to deal with in order ... If you have a list of the representations you want to work with, you provide that list in order in the HTTP request. Other linking is application specific, e.g. DC might have a seeAlso statement pointing to some other representation. If you get back something you didn't ask for, assume server doesn't have what you did ask for. What are circumstances where you need to know beforehand?
<Alistair> There might be some utility for functionality to learn the available representations ahead of time. I don't know of a way in HTTP to do this directly, but we can go a long way without having this functionality. I don't think we should worry about this just now.
<DanBri> I don't think HTTP requires this, but the www.w3.org behavior is, e.g. in the case of the W3C icon, when you ask for a representation that doesn't exist you get back a page describing the available representations. When dereferencing the W3C icon, if you send HEADER for content-type it doesn't have, you get back message pointing to available types. So it's possible to configure Web servers to give you an inspection ability.
<RalphS> Do we agree that Best Practice is to serve an RDF representation at a minimum -- that an RDF form be served at a property or class URI?
tom: I think so. This is in the requirements that Alistair posted, which are attached to today's agenda.
ralph: Given that this is the case, if our consensus is that you must serve some RDF at this URI, how strongly do we want to say e.g. you may serve an HTML representation? Do we feel confident recommending this? If we find a way to do it which is consistent with webarch and can reasonably be implemented by web servers, we could say that best practice is to serve both RDF and HTML. Then it feels like Bernard's question goes away, because then the client can assume that both RDF and HTML are available.
tom: How does a user know that other representations are available? It desirable that the user of an HTML page see links to or an overview of other representations. Maybe could add a cross reference from html page to rdf page as link ....
ralph: The client could assume both RDF and HTML representations are available. Are you saying, there might be a third type available? Ah, Tom did say "user", not "client"... The client should assume both are available and make that information available to the user.
<Tom> If a user is viewing a Web page, how do they know there are RDF representations for the same things?
<Alistair> This issue is separate from Best Practices for dereferencing URIs. It is about best practices for documenting your vocabulary in HTML.
bernard: My point is similar to Tom's point -- the user's point of view -- but I agree this is not in focus for today, we're not speaking of different things.
tom: We don't need to agree on that level of detail today, because just getting the content negotiation issue solved is progress enough, but users shouldn't click on the URI for a term and assume no RDF is available because they can't see it ...
<RalphS> ah, perhaps the usability question involves a browser issue -- e.g. if users had some interface to easily tell their browser what representation to prefer on a given 'click'...
<RalphS> ACTION: Tom produce a small draft of the consensus we've reached, starting with the text at the bottom of the agenda in http://lists.w3.org/Archives/Public/public-swbp-wg/2005Oct/0217.html [recorded in http://www.w3.org/2005/10/28-vmtf-minutes.html#action01]
<Alistair> I wrote a proposed dereferencing configuration for SKOS. I'd like to actually try this out and would like some discussion before I try this.
<RalphS> I could probably persuade the W3C Webmaster and some other Team Apache geeks to join us in telecon.
<Alistair> I want to know both from an architectural point of view and an implementation point of view whether what I'm proposing is acceptable.
<RalphS> Proposed next telecon: Tuesday 15 Nov at 1400 UTC
<RalphS> ACTION: Ralph to invite Matthieu, Gerald, Vivien, Ted to 15 Nov telecon [recorded in http://www.w3.org/2005/10/28-vmtf-minutes.html#action02]
<RalphS> ACTION: Alistair to write agenda for 15 Nov [recorded in http://www.w3.org/2005/10/28-vmtf-minutes.html#action03]