W3C home > Mailing lists > Public > public-swbp-wg@w3.org > October 2005

[VM] Skip Oct 11 telecon? (next Oct 25)?

From: Thomas Baker <tbaker@tbaker.de>
Date: Mon, 10 Oct 2005 15:54:37 +0200
To: SW Best Practices <public-swbp-wg@w3.org>
Message-ID: <20051010135437.GA2812@baker>

Dear all,

The 27 Sep telecon is reported at
http://www.w3.org/2005/09/27-vmtf-minutes.html (and in clear
text below).  There were two main actions:

    1) Danbri to write up how foaf URI dereferencing
       works now and how it should be done.

    2) Tom - same for DCMI.

I have been liaising with DCMI colleagues on this and have
nothing to report back yet but do expect to have this before
Oct 25.  Dan?

I would prefer to skip tomorrow's scheduled telecon and aim
at the next, on Tuesday, October 25 (1300 UTC/1500 Amsterdam).

If others have progress to report and would prefer to keep to
the scheduled time, I could arrange to do this though, in that
case, I would prefer to keep the meeting to under 50 minutes.

What do others prefer?



SWBPD VM Task Force 

27 Sep 2005 Telecon 

Agenda: http://lists.w3.org/Archives/Public/public-swbp-wg/2005Sep/0111.html 

IRC log: IRC http://www.w3.org/2005/09/27-vmtf-irc 

Previous telecon: 2005-07-19


        Tom Baker 
        Alistair Miles 
        Dan Brickley 
        Ralph Swick 
        Bernard Vatant 

Summary of Action Items 

[NEW] ACTION: danbri to write up how foaf URI dereferencing
works now, and how it should be done. [recorded in

[NEW] ACTION: tom to write up current DCMI URI dereferencing
works now, and how it should be done. [recorded in

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

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

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

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


<scribe> ACTION: danbri to write up how foaf URI dereferencing
works now, and how it should be done. [recorded in

<scribe> ACTION: tom to write up current DCMI URI dereferencing
works now, and how it should be done. [recorded in

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

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 
[End of minutes]

First draft of minutes formatted by David Booth's scribe.perl version 1.127 (CVS 
$Date: 2005/09/27 14:00:42 $ 

Dr. Thomas Baker                      baker@sub.uni-goettingen.de
SUB - Goettingen State                            +49-551-39-3883
and University Library                           +49-30-8109-9027
Papendiek 14, 37073 Göttingen
Received on Monday, 10 October 2005 13:55:08 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:31:13 UTC