SWBPD VM Task Force

In preparation for today's telecon, Alistair described how SKOS currently handles dereferencing URIs and proposed some changes to the current policy.

RalphS My response to Alistair's thoughts didn't make complete sense as I momentarily forgot that SKOS URIs use '#'.

Tom: Here's the problem: if you click on http://purl.org/dc/elements/1.1/title in your browser, you get a screenful of angle brackets -- the top of the RDF schema. So far, we have assumed this is reasonable practice, but in Madrid, we agreed this is no longer good enough in 2005... The options are: 1) some sort of content negotiation, or 2) a Web page that somehow points or redirects to the RDF schema (e.g. via the link attribute). The idea is that by default, users are shown a readable Web page, and applications which want to consume RDF can do so. In Madrid, no definite conclusion on best way forward.

Ralph: Important to use solution that respects compatibility with current tools, which expect to do a GET on property URIs and expect RDF/XML content. So if we require they do accept application/rdf+xml it is probably okay.

Alistair: What I proposed regarding SKOS Core tries to do both of these things: requesting text/html returns a human-readable document. This is different from what DCMI currently does. If the clients asks for RDF/XML it gets redirected to something that is RDF/XML. This feature of DCMI -- using redirects -- is a good idea. So I'm in favor of using content negotiation.

Tom: The content negotiation option seems clear; the other option fuzzy. Was it to have a Web page with an embedded pointer to the RDF schema, and if enough people did it then applications would have to handle it?

Danbri: Remember EricM saying something about linking to RDF.

RalphS: Published recommendation says something about link.

Danbri: Webarch provides for content negotiation -- see http://www.w3.org/TR/webarch/#def-coneg.

Tom: So do we have a consensus here for content-negotiation?

RalphS: Other option is embedded RDF (XHMTL 2.0)

Danbri: Previous FOAF specs have embedded RDF/XML at the expense of validation.

Ralph: Support as much RDF as we can as embedded, but not necessarily everything. RDF/A syntax is what HTML TF is converging on, is it reasonable to express RDF schema as RDF/A? But RDF/A solution does not address deployed tools.

Tom: Does content negotiation raise issues with regard to deployed tools?

RalphS: Yes, but cheap and tools should change to do this anyway. Wanted to ask if embedded RDF was talked about in Madrid.

Danbri: I am trying to figure out what do do with FOAF namespace. Currently, it uses the wrong 30x redirect. Currently, it goes from a term URI to the namespace URI -- e.g., Apache "RedirectTemp /foaf/0.1/Organization http://xmlns.com/foaf/0.1/" goes from http://xmlns.com/foaf/0.1/Organization to http://xmlns.com/foaf/0.1/. Can then get that with HTML or RDF. We have discussed doing redirect so that e.g. http://xmlsn.com/foaf/0.1/mbox redirects to spec#term_mbox. But problem with hash and encoding in Apache with rewriting... Reasonable for clients to get redirects depending on content type requested.

RalphS [re Accept: application/rdf+xml] -- it's a shame it took us several years to tell application developers what content type to request, but oh well. But with the above options, redirects are content-type-specific? How do you configure in Apache?

Danbri Current: RedirectTemp /foaf/0.1/Organization http://xmlns.com/foaf/0.1/. Possible: RedirectTemp /foaf/0.1/Organization http://xmlns.com/foaf/0.1/#term_Organization. Problem 1: # gets escaped somehow (reported by Al). Problem 2: This becomes representation-specific: #term_Organization is an anchor only in the HTML version of the namespace document; it means nothing in the RDF version.

RalphS It doesn't strike me that different redirects based on Accept: is architecturally bad, but if there's no apache support that's an issue for us.

Alistair Current browsers preserve their fragID across redirects.

RalphS So a redirect that includes a fragID would lead to fragID clashes? Suspect Alistair is right but wonder if it is actually endorsed by HTTP spec. If it is not endorsed then not all browsers may do it.

Danbri Ah, so a link such as <a href="http://xmlns.com/foaf/0.1/Organization#term_Organization">Organization</a> might redirect to right part of the HTML document.

RalphS Perhaps we could ask the TAG if it is legitimate for a server to return a fragID in a redirect -- ask the TAG if it is legit for a server to return a URI with a hash in a redirect?

Tom: Stepping back, we seem to have consensus on content-negotiation on this call, so we could as a next step write up how this works, leading to issues with the TAG and compatibility with spec?

Alistair Apache URI-encodes '#' before serving a redirect to the client but purl.org leaves '#' un-encoded.

Danbrieg <a href="http://xmlns.com/foaf/0.1/Organization#term_Organization">Organization</a> took me to http://xmlns.com/foaf/0.1/#term_Organization. The option of "redirect with content negotiation", on a / namespace, means that term URIs can't redirect to parts of the HTML spec. Am realising that / namespace URIs prevent us getting clickable term URIs for correct sections of a document.

I also tested redirects with hash for FOAF -- http://xmlns.com/foaf/0.1/Organization#xyz. So Apache hash encoding makes sense if browsers hang on to fragIDs across redirects.

RalphS: Above redirect is broken.

Danbri: Can document this as one of the tradeoffs for hash vs slash.

RalphS: Is there a document which describes FOAF URI resolution policy now, and what it should be in light of the Madrid discussion? Can you write this up? Propose you write how it is now, then write best guess on how it should work -- along the lines of Alistair's SKOS Core resolution message.

<danbri> http://rdfweb.org/viewcvs/viewcvs.cgi/xmlns.com/htdocs/foaf/0.1/.htaccess

<scribe> ACTION: danbri to write up how foaf URI dereferencing works now, and how it should be done. [recorded in http://www.w3.org/2005/09/27-vmtf-minutes.html#action01]

<scribe> ACTION: tom to write up current DCMI URI dereferencing works now, and how it should be done. [recorded in http://www.w3.org/2005/09/27-vmtf-minutes.html#action02]

Alistair We can state our [DCMI, SKOS, FOAF] requirements, perhaps more simply than we can describe what currently is implemented.

Ralph: It's fine to use MUST and SHOULD in a requirements document.

Tom: MARC Relator codes are currently declared as RDF properties. Clicking on a term [http://www.loc.gov/loc.terms/relators/ILL currently gets you to a Web page (see also http://www.loc.gov/loc.terms/relators/dc-relators.html), but you have to know to go elsewhere for the RDF [http://www.loc.gov/loc.terms/relators/dc-relators.xml]. This is nice for humans, but not ideal for applications.

Bernard: In recently posting, ask about relationship to Published Subjects. If we go down this route of making URIs friendly to both humans and computers they start to behave alot like publish subjects. Can we characterise the similarities and differences? When we did Published Subjects, recommendation for way that computers would use annexed schemas was not clear. Published Subjects primarily directed at humans. Now with this new state of things we could revisit pubsub.

RalphS: Useful line of investigation ... gives us way to do convergence. But one issue is if there is a disagreement between interpretation of human-readable and machine-readable, which do you believe?

Bernard: TMs have no notion of a contradiction, no notion of consistency, just some binding points for bits of information about a subject. But no way to make sure these things are consistent -- which is why AI folks don't like TMs. But consistency between human and computer descriptions is difficult to control.

<danbri> "This specification does not attempt to enumerate all the possible forms of vocabulary description that are useful for representing the meaning of RDF classes and properties. Instead, the RDF vocabulary description strategy is to acknowledge that there are many techniques through which the meaning of classes and properties can be described. ..."

<danbri> rdfs is (on purpose) agnostic re which forms of vocab desc take precedence

Tom: Longer-term, DCMI needs to re-examine the policy implications of declaring vocabularies by expressing the same information both in a Web document and in an RDF schema -- when does DCMI want to say which resource is 'authoritative'? Providing parallel representations implicitly assumes that the representations are in sync. DCMI tries to ensure this by generating both forms of documentation from a single source. Currently, the Web pages present somewhat more information (e.g., historical versions of term descriptions) than the current RDF schema. The Web page [http://dublincore.org/documents/dcmi-terms/] currently asserts itself to be an "authoritative specification"; the RDF schemas do not currently make the same assertion. Dublin Core started as an RFC [http://www.ietf.org/rfc/rfc2413.txt] and as Web documents, and this precedence of the Web document was never explicitly changed. This situation could change in the future, especially as DCMI moves towards saying more about the terms in a formal sense. DCMI would need to be explicit on authoritative nature of the representations.

RalphS: Is it a proper subset? Are there e.g. domains and ranges in RDF overlooked in HTML?

Tom: DCMI terms are not currently defined with domains and ranges. A DCMI working group is currently looking at domains and ranges which might in principle be assigned to existing DCMI properties in order to reinforce semantics as they are currently interpreted. Such a step is seen as a positive step in principle, while recognizing the danger that such additional assertions could in fact restrict semantics as they are used in practice.

Danbri: One can say e.g. 'we believe these things are always in sync, if not tell us'

Bernard: Machine readable is normative, human readable is informative ... go in this direction?

Alistair "Which variant is authoritative" is a longer-term issue for SKOS too. In SKOS, some constraints currently only described in prose and would be hard to express formally; perhaps by using SPARQL. The RDF schema does not have enough information to specify all of the constrains -- e.g., broader/narrower, and "there should be only one preferred label per language".

DanBri: RDFS had a class ConstraintResource