W3C home > Mailing lists > Public > public-swbp-wg@w3.org > January 2006

[VM] 2006-01-17 telecon report

From: Thomas Baker <tbaker@tbaker.de>
Date: Wed, 18 Jan 2006 12:21:20 +0100
To: SW Best Practices <public-swbp-wg@w3.org>
Message-ID: <20060118112120.GA2732@baker>

SWBPD VM 2006-01-17 telecon report


Agenda:  http://lists.w3.org/Archives/Public/public-swbp-wg/2006Jan/0063.html
IRC log: http://www.w3.org/2006/01/17-vmtf-irc
Present: Libby Miller, Tom Baker (chair), Alistair Miles (Scribe), Ralph Swick

Next telecon 2006-01-24 1500 UTC

----------------------------------------------------------------------
RESOLUTION: Title will be "Best Practice Recipes for Serving 
            RDFS and OWL Vocabularies

----------------------------------------------------------------------
DBooth/G1 -- Ralph responded; we don't know if David is satisfied

----------------------------------------------------------------------
DBooth/G2 --

Tom: wouldn't want the purl.org material to disappear
entirely, though it could be in a separate section, perhaps
in the context of persistence of URIs.  Would like to have
guidance that DCMI could implement without assuming we can get
changes in the purl.org implementation.  This guidance does
not necessarily need to be in the body of the cookbook, so we
can keep the scope of the body of the note to Best Practices.

Ralph: Problem with purls maybe more difficult than first
appeared.  It is not enough to change all 302s to 303s because
302 is appropriate for most URIs.  So the purl.org maintainers
would have to implement a feature for users to specify that
some resource is a non-information resource.  This would require
changes to the database.

Are there any options to do a double redirection? I.e. if
purl returns a 302 redirect, then my own server does a 303.
Although this is inefficient from network point of view,
I wonder if this is a workaround.  Bottom line: the draft
should maybe better to stay silent on PURLs for the moment.
Certainly need to help DCMI (and other PURL-maintaining
vocabularies), but maybe with another doc?

Alistair: Regarding double redirect, on hazy ground here. In
my understanding, TBL has been saying it is reasonable for
an app to make some inferences based on the response code.
If that is the case, the only response code that matters is
from the initial code; therefore, double redirect is just
as bad (Ralph fears Alistair is correct on this).  But this
has to do with interaction btw web/sw architecture; lots of
conflicting views; haven't seen spelled out clearly.

Ralph: this issue is worth investigating.  Pragmatically, we
should work with TAG to clarify remaining qsts.  I'm willing
to have a first draft that does include PURLs with a big
cautionary note "This is not Best Practice" -- bottom line
is we don't yet have a solution for purl.org.

Alistair suggests tag coin a uri for "information resource";
using this, "you can draw the following inferences".

ACTION: Alistair draft the question (i.e., that only the
initial response code matters) for discussion in VM, then
send to TAG.

Alistair: if all purls taken out of cookbook - create
"short-term suggestions for maintainers of purl.org namespaces".
Doesn't completely conform, but step in right direction.

Ralph: we need a section on importance of persistence namespaces.

Tom: Important to address persistence in the main body.
Moving purl.org to an appendix makes for a very long appendix.
Moving the purl material to a separate document has the
advantage of making the main cookbook slimmer.

ACTION: Alistair to put the purl.org material into an Appendix.

Note: http://lists.w3.org/Archives/Public/public-swbp-wg/2005Dec/0016.html
note on MultiViews versus conditional redirects

Note: rdf as the default response
http://lists.w3.org/Archives/Public/public-swbp-wg/2005Dec/0022.html



-- 
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 Wednesday, 18 January 2006 11:21:31 UTC

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