(unknown charset) [VM] Report on telecon, 2005-07-05

Meeting: SWBPD VM Task Force, 2005-07-05

IRC log: http://www.w3.org/2005/07/05-vmtf-irc

    Tom Baker
    Alistair Miles
    Dan Brickley
    Ralph Swick

Regrets: Libby Miller

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

Topic: Basic Principles for Managing an RDF Vocabulary 
-- latest version at http://www.w3.org/2001/sw/BestPractices/VM/principles/20050705 

An important function of this note is be to explain good
practice for resolving term URIs, so that when you click on
a term, you get a document.

Tom: Does Dublin Core do this 'right'?  Am willing to pursue
an action to fix if not.

HTTP responses can be checked with tools such as
http://livehttpheaders.mozdev.org/, so we check the responses:

    HEAD http://purl.org/dc/elements/1.1/title
        302 Found 

The purl.org server resolves this to:

    HEAD http://dublincore.org/2003/03/24/dces#title 
        200 OK 
        Server: Apache/1.3.28 (Unix) mod_jk/1.1.0 
        Content-Length: 15064 
        Content-Type: text/plain 

DanBri: TAG would prefer "303 See Other" rather than
"302 Found".  Specs for 303 and 302 can be found at

        10.3.3 302 Found

        The requested resource resides temporarily under a different
        URI. Since the redirection might be altered on occasion,
        the client SHOULD continue to use the Request-URI for future
        requests. This response is only cacheable if indicated by a
        Cache-Control or Expires header field.

        The temporary URI SHOULD be given by the Location field in the
        response. Unless the request method was HEAD, the entity of the
        response SHOULD contain a short hypertext note with a hyperlink
        to the new URI(s).

        If the 302 status code is received in response to a request other
        than GET or HEAD, the user agent MUST NOT automatically redirect
        the request unless it can be confirmed by the user, since this
        might change the conditions under which the request was issued.

              Note: RFC 1945 and RFC 2068 specify that the client is not
              allowed to change the method on the redirected request.
              However, most existing user agent implementations treat
              302 as if it were a 303 response, performing a GET on the
              Location field-value regardless of the original request
              method. The status codes 303 and 307 have been added for
              servers that wish to make unambiguously clear which kind
              of reaction is expected of the client.

        10.3.4 303 See Other

        The response to the request can be found under a different URI
        and SHOULD be retrieved using a GET method on that resource. This
        method exists primarily to allow the output of a POST-activated
        script to redirect the user agent to a selected resource. The new
        URI is not a substitute reference for the originally requested
        resource. The 303 response MUST NOT be cached, but the response
        to the second (redirected) request might be cacheable.

        The different URI SHOULD be given by the Location field in the
        response. Unless the request method was HEAD, the entity of the
        response SHOULD contain a short hypertext note with a hyperlink
        to the new URI(s).

              Note: Many pre-HTTP/1.1 user agents do not understand the
              303 status. When interoperability with such clients is a
              concern, the 302 status code may be used instead, since
              most user agents react to a 302 response as described here
              for 303.

ACTION Danbri: Send note to PURL developers, ask whether they
would consider making 303 an option.

Ralph: Is there a reason to ask them to make 303 an option,
or maybe just ask them to change it?  Is there a reason for
staying with 302?

Ralph: Strictly speaking, the way Dublin Core's RDF schema is
served up, it is a text document with lots of angle brackets.

Alistair: Should dublincore.org return something other than
"Content-Type: text/plain"?  Should it return "Content-Type:

Question arises: if HTML representations are made available
too, then what is "http://dublincore.org/2003/03/24/dces#title"
the URI of?

Alistair: Does the TAG resolution preclude us from
content-negotiating on a hash URI (e.g., every term in the
SKOS Core vocabulary)?

DanBri: Because DC is redirecting to ...#title, some of the
issues go away.  The meaning of #frag is relative to the
media type.  One is still left with the ugly business of
content negotiation on the hash thing.  If there is only an
RDF representation ("application/rdf+xml"), then no problem.
But if there is also an HTML document there, then we're stuck
with #Title meaning something specific in HTML.

Alistair: I wrote once before that hash URIs must _not_ support
content negotiation.  See http://esw.w3.org/topic/SkosDev.

Ralph: could take less extreme position: that if you serve an
HTML document, it must not use any of the RDF concepts as IDs.
All IDs using an HTML document should (or must!) refer to HTML
fragments and should not overlap with RDF terms (in order to
HTML validate).

DanBri suggests PURL for DC might redirect to a URI
without a #, maybe?  What if all DC terms redirect
to http://dublincore.org/2003/03/24/dces?  In practice,
currently dublincore.org returns the same document for all
DC terms anyway.

RedirectTemp /foaf/0.1/Person http://xmlns.com/foaf/0.1/ 
RedirectTemp /foaf/0.1/Agent http://xmlns.com/foaf/0.1/ 
RedirectTemp /foaf/0.1/Project http://xmlns.com/foaf/0.1/ 
RedirectTemp /foaf/0.1/Image http://xmlns.com/foaf/0.1/ 
RedirectTemp /foaf/0.1/Document http://xmlns.com/foaf/0.1/ 

Ralph: We need to find an answer to Alistair's content
negotiation question.  When users (as opposed to tools) use
URIs, different representations are more helpful than others
-- they benefit from being able to see something useful in
their browsers .  That is a very common question users have.

Alistair: everyone still treats HTTP servers as file servers 

Ralph: http://dublincore.org/2003/03/24/dces is something like
a namespace document or an RDF schema but it's not necessarily
either one as it doesn't appear at the namespace URI.  We may
find it useful to have a role name for this document

Alistair: An 'RDF Vocabulary Description Document'?

Tom: dc:title of http://dublincore.org/2003/03/24/dces is
"The Dublin Core Element Set v1.1 namespace providing access
to its content by means of an RDF Schema".

Nobody likes this, and DanBri suggests "Dublin Core Element Set
vocabulary description".  Shortening the title might reduce
some confusion.  See http://www.w3.org/2004/02/skos/core:
dc:title is 'SKOS Core Vocabulary'.  FOAF has dc:title "Friend
of a Friend (FOAF) vocabulary", dc:description="The Friend
of a Friend (FOAF) RDF vocabulary, described using W3C RDF
Schema and the Web Ontology Language."

Tom: we considered that, as the title looks
confusing when displayed by schema browsers (e.g.,
http://www.schemaweb.info/), but were ultimately uncertain
about implications.  First we need to understand the model
and convey that somewhere (not necessarily in the title).

Ralph suggests holding off on changing title.

DanBri notes that FOAF namespace document uses dc:description
to describe itself.  The dc:description has some of the
things that the Dublin Core document puts into its dc:title
(e.g. the phrase "providing access via ..."); maybe in dc,
could also push detail into dc:description?  Short, snappy
title (DC Namespace), then put versioning information into

Alistair: SKOS Core dc:description: "An RDF vocabulary for
encoding simple concept schemes such as thesauri and subject
heading lists."

Tom: In Dublin Core, historical versions of
the descriptions of terms have URIs in the form
of anchors in an HTML document.  For example,
is a historical version of the description of
http://purl.org/dc/elements/1.1/contributor.  The URI
functions as the URI for a description of a term at a
specific point in time.  DCMI does not give the document
http://dublincore.org/usage/terms/history/ a very high profile
as it has the potential to confuse users.  We thought about
modeling this in RDF but were not sure what the requirements
were.  We were aware that good practice might evolve in this
area but we wanted to capture the information somewhere in
the meantime, and HTML was easy.

Danbri: FOAF index.rdf is under CVS control,
However, this is not exposed very easily to RDF processors.  One might
exploit such information with SPARQL.

Tom: all of the RDF schemas are still in the Web, i.e.:

Ralph notes that this 'how to version vocabularies' question
is an open issue for VM and/or PORT.

Alistair: DC has the beginning of tight management system
for RDF vocabulary -- the beginnings of what looks like a
configuration management system.  We should build on that.
But questions about those URIs that point to anchors in
versioning history document: If each identifies the description
of a term at a given point in time, then fine to use. But if
they identify version, then could not do content negotiation.
Patrick Stickler thinks it is bad to give URIs to "versions"
of a term, but good to give URIs to "descriptions" of a term.
I.e., let's not say "historical version of term". 

Tom: Agreed.  We are giving URIs for "versions of a description
of a term".

Ralph agrees this is a subtle and important distinction.

Danbri: we are telling stories here...  We have one and we
are saying things about it at different times.  In the early
RDF schema spec, I encouraged people: "if you changed it,
you have something new, so make a new schema...." etc.

Ralph: The threashold is very community-sensitive.

Tom: Defining that threshold is the
purpose of the DCMI Namespace Policy,

Ralph interprets Patrick's caution as being against implicitly
relying on some sort of URI similarity to convey semantics.
Even in RDF, between the original 1999 namespace and the
current one: they differ in subtle ways, but a decision
was made not to change the names (URIs) of the terms for
practical reasons.

Danbri: In some cases we "altered the semantics" of the
terms to correspond to "what the semantics actually are"
(in terms of authorial intent and deployment).  One could
argue that "we changed the description to better describe
the real semantics of the property".

Ralph: I trust that the DC community has the right body of
expertise to get these things right -- i.e., when a description
can be clarified to match some notion of the 'true semantics'
vs when there is enough difference to merit a new name.
Some of that perspective may be driven by application behavior. 

Danbri: This is fine for DC-length vocabularies. But in
description-logic-type vocabularies, different situation.
DC community focuses on prose definitions. Other communities
focus on inferencing structures.

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, 6 July 2005 16:09:53 UTC