- From: (unknown charset) Thomas Baker <tbaker@tbaker.de>
- Date: Wed, 6 Jul 2005 18:15:38 +0200
- To: (unknown charset) SW Best Practices <public-swbp-wg@w3.org>
Meeting: SWBPD VM Task Force, 2005-07-05 IRC log: http://www.w3.org/2005/07/05-vmtf-irc Attendees 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 http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3: 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: application/rdf+xml"? 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. DanBri: http://rdfweb.org/viewcvs/viewcvs.cgi/xmlns.com/htdocs/foaf/0.1/.htaccess 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/ etc 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 dc:description. 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, http://dublincore.org/usage/terms/history/#contributor-003 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, http://rdfweb.org/viewcvs/viewcvs.cgi/xmlns.com/htdocs/foaf/0.1/index.rdf. 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.: http://dublincore.org/1997/10/02-dces http://dublincore.org/1997/10/02-dces.xml http://dublincore.org/1999/10/27-dces http://dublincore.org/2000/03/13/dces http://dublincore.org/2001/08/14/dces http://dublincore.org/2002/08/13/dces http://dublincore.org/2003/03/24/dces 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, http://dublincore.org/documents/dcmi-namespace/. 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