- From: Libby Miller <libby@asemantics.com>
- Date: Fri, 31 Mar 2006 05:46:34 -0800 (PST)
- To: Thomas Baker <tbaker@tbaker.de>
- cc: SW Best Practices <public-swbp-wg@w3.org>
arrgh, Tom, apologies, I knew I wasn't going to make this but forgot
regrets.
Libby
On Fri, 31 Mar 2006, Thomas Baker wrote:
>
> SWBPD VM 2006-03-31 telecon agenda
>
> Note that as of 2006-03-26, Central Europe is on "Summer Time"!
>
> Friday, 13:00 UTC -- 14:00 London -- 15:00 Berlin
> http://www.w3.org/Guide/1998/08/teleconference-calendar#D20060331
> Zakim: +1-617-761-6200
> Conference code 8683# ('VMTF')
> irc://irc.w3.org:6665/vmtf
>
> ----------------------------------------------------------------------
> AGENDA
>
> As agreed on 2006-03-17, this last telecon of the VM
> Task Force under the current SW BPD charter will focus
> on taking stock of outstanding issues.
>
> At a minimum, we should discuss the issues listed below
> under "Remaining Issues to Discuss".
>
> Time-permitting, we should look at issues from the "VM
> Task Force Web page", also listed below.
>
> The final, edited version of this document can serve as
> a point of departure for discussion in the context of a
> new SW working group.
>
> ----------------------------------------------------------------------
> LINKS
>
> Reports of recent telecons
> [1] 2006-02-07: http://lists.w3.org/Archives/Public/public-swbp-wg/2006Feb/0059.html
> [2] 2006-02-14: http://lists.w3.org/Archives/Public/public-swbp-wg/2006Feb/0115.html
> [3] 2006-03-17: http://lists.w3.org/Archives/Public/public-swbp-wg/2006Mar/0051.html
>
> Current draft, under discussion
> [4] http://www.w3.org/2001/sw/BestPractices/VM/http-examples/2006-01-18/
>
> David Booth's re-review comments of Feb 15
> [5] http://lists.w3.org/Archives/Public/public-swbp-wg/2006Feb/0109.html
>
> Current VM Task Force Web page
> [6] http://www.w3.org/2001/sw/BestPractices/VM/
>
> Older, abandoned draft, not to lose sight of...
> [7] http://esw.w3.org/topic/VocabManagementNote
>
> ----------------------------------------------------------------------
> OUTSTANDING ACTIONS
>
> ACTION (ongoing): Ralph to test recipes with W3C configuration.
>
> ACTION 2006-03-17 Ralph: Contact Matthew Ellison about our interest in
> having STC participate in VM writing.
>
> AGREED 2006-03-17 to focus the last telecon on clarifying
> the list of issues to be carried forward into future
> chartered working groups.
>
> ----------------------------------------------------------------------
> REMAINING ISSUES TO DISCUSS
>
> 1. David Booth's review, Point 7: "Interpretation of fragment identifiers"
> Recipe 3. Hash Configuration, Extended:
> I don't think the comment from my previous review was addressed:
> "Because the interpretation of a fragment identifier in
> the presence of 303 redirects is unclear as far as I know, I think
> this recipe should note that the browser may or may not apply the
> fragment identifier to the secondary URI."
>
> 2. Hash namespace URIs
>
> On 2006-02-14, Ralph pointed out [*] that the Cookbook shows
> vocabulary
> http://isegserv.itd.rl.ac.uk/VM/http-examples/example1
> defining classes
> http://isegserv.itd.rl.ac.uk/VM/http-examples/example1#ClassA
> http://isegserv.itd.rl.ac.uk/VM/http-examples/example1#ClassB
> consistently omitting the trailing '#' from the vocabulary name.
>
> [*] http://lists.w3.org/Archives/Public/public-swbp-wg/2006Feb/thread.html#msg105
>
> "I claim this is a fundamental mistake and would argue it on the
> basis of both semantics and what the RDF core specifications
> state. The semantic point is that [a] should be the name of the
> vocabulary while [b] is the name of a document that might (should)
> describe that vocabulary."
>
> [a] http://isegserv.itd.rl.ac.uk/VM/http-examples/example1#
> [b] http://isegserv.itd.rl.ac.uk/VM/http-examples/example1
>
> 3. Longer-term issue: alignment of content-negotiation ideas
> in the cookbook with TAG:
> -- http://www.w3.org/2001/tag/issues.html#namespaceDocument-8
> -- Associating Resources with Namespaces
> Draft TAG Finding 13 December 2005
> http://www.w3.org/2001/tag/doc/nsDocuments-2005-12-13/
>
> ----------------------------------------------------------------------
> VM TASK FORCE WEB PAGE - as of November 2005
>
> Short-term objectives
>
> -- To define (in a Note
> <http://www.w3.org/2003/glossary/keyword/Process.rdf/?keywords=Note>
> or Editor's Draft) a set of good-practice "recipes" for
> configuring an Apache server for content negotiation such that:
> o If a person tries to dereference the URI of a class or
> property (i.e. via a Web browser), they end up at the
> relevant bit of human-readable documentation.
> o If a machine tries to dereference the URI of a class or
> property, they end up with a serialisation of a set of RDF
> statements describing that class or property, with a
> provenance that allows differentiation of different
> 'versions' of an RDF schema/ontology.
> o The dereferencing solution complies with TAG resolution on
> httpRange-14.
> -- To wrap those recipes in enough context to make them usable by
> vocabulary maintainers to provide documentation and schemas for
> their vocabularies.
>
> Long-term issues
>
> -- URIs based on PURL.ORG. DC, RSS, and vocab.org use URIs based on
> purl.org, which currently responds to GET requests with 302
> (Temporarily Moved). The TAG decision on httpRange-14
> <http://lists.w3.org/Archives/Public/www-tag/2005Jun/0039.html>
> requires 303 (Redirect). This was discussed in a mailing list
> thread
> <http://lists.w3.org/Archives/Public/public-swbp-wg/2005Aug/0037.html>.
> In July, Dan asked TAG
> <http://lists.w3.org/Archives/Public/public-swbp-wg/2005Jul/0056.html>
> whether a 302 response on a purl.org URI would be acceptable. As
> of November, Alistair has included purl.org scenarios in the draft
> cookbook
> <http://www.w3.org/2001/sw/BestPractices/VM/http-examples/2005-11-18/>.
>
> -- Awareness of multiple representations. If content negotiation is
> handled in the background and alternative representations of a
> vocabulary in RDF or HTML are served up to a user seemingly
> automatically -- on the basis of Apache configurations -- how
> would an interested user know which other representations were
> available <http://www.w3.org/2005/10/28-vmtf-minutes.html>?
> Should there be some way for a user to learn about other
> representations (e.g., via cross-references or an overview page)?
> --Notion of a "Definitive RDF description". Peter Patel-Schneider
> has questioned the focus on one "definitive RDF description" for
> each RDFS/OWL class, property, or individual -- as opposed to an
> RDFS description, an OWL description, or multiple "definitive"
> descriptions
> <http://lists.w3.org/Archives/Public/public-swbp-wg/2005Nov/0075.html>.
>
> -- Provenance and URIs. Provenance is supported by using the final
> URI from the chain of redirects as the name of the graph;
> different URIs represent different versions of a vocabulary. Tom
> has noted that, in practice, "date-stamped" URIs are often used
> <http://lists.w3.org/Archives/Public/public-swbp-wg/2005Nov/0078.html>
> and suggests we explicitly acknowledge both that URI strings are
> in theory opaque and unparsable and that there are de-facto social
> conventions for using date stamps or version numbers.
>
> -- rdfs:isDefinedBy. Clarifying the dereferencing options provides
> an opportunity to clarify good practice for the use of
> rdfs:isDefinedBy
> <http://www.w3.org/2000/01/rdf-schema#isDefinedBy>. Instead of
> relying on URI string manipulation in an attempt to heuristically
> locate a namespace, namespaces should be declared with
> rdfs:isDefinedBy.
>
> -- Change management for RDFS/OWL ontologies.
> There was discussion on whether this should more properly be
> called "change management" or even "version documentation".
> Current DCMI practice
> <ftp://ftp.cenorm.be/public/ws-mmi-dc/mmidc148.pdf> has been
> described. The emerging consensus is that it is best to version
> the description of a property (i.e., the RDF statements about it),
> not the property itself. I.e. each 'version' is a named graph;
> provenance information can then be used to distinguish between
> different descriptions of a property. Alistair notes that the
> issues of versioning and change management are coming to the fore
> in the OWL community.
> o Part 1. Naming
> <http://isegserv.itd.rl.ac.uk/cvs-public/~checkout~/swbp/vm/change-management/part1.html>
>
> o Part 2. Metadata
> <http://isegserv.itd.rl.ac.uk/cvs-public/~checkout~/swbp/vm/change-management/part2.html>
>
> -- Principles of Good Practice (see Wiki draft
> <http://esw.w3.org/topic/VocabManagementNote>).
> o Identify Terms with URIs.
> o Articulate and publish maintenance policies for the Terms
> and their URIs.
> o Identify the historical version of a Vocabulary or its Terms.
> o Provide natural-language documentation about the Terms.
> o Declare the Terms using a formal, machine-processable schema
> language.
>
> See also
>
> -- 2005-11-22, Vocabulary Management Task Force progress report
> <http://lists.w3.org/Archives/Public/public-swbp-wg/2005Nov/0122.html>.
>
> Dependencies
>
> -- SWBP Thesaurus Task Force (THES)
> <http://www.w3.org/2004/03/thes-tf/mission>
> -- TAG decision on httpRange-14
> <http://lists.w3.org/Archives/Public/www-tag/2005Jun/0039.html>
> -- SWBP response to TAG decision on httpRange-14
> <http://lists.w3.org/Archives/Public/public-swbp-wg/2005Sep/0010.html>
>
> ----------------------------------------------------------------------
> ISSUES ALREADY DISCUSSED - David Booth's re-review [5]
>
> -- Point 1: As decided on the Feb 20 BPD telecon, Tom added
> text about URIs coined using the
> http://thing-described-by.org 303-redirect service [a,b,c].
>
> [a] http://lists.w3.org/Archives/Public/public-swbp-wg/2006Mar/0027.html
> [b] http://www.w3.org/2001/sw/BestPractices/VM/http-examples/2006-01-18/#other
> [c] http://www.w3.org/2001/sw/BestPractices/VM/http-examples/2006-01-18/#redirect
>
> David's point: Using a 303-redirect service, while quite
> new as an approach, would theoretically be simpler to
> implement than the recipe in the Cookbook claimed to be
> "the simplest". Suggests adding an editor's note. Tom took
> this as an action on the Feb 20 telecon and followed up
> by adding some text [5], which David Booth approved.
>
> Alistair is not convinced that using 303 redirects is
> actually simpler; he hasn't written up his thoughts yet.
> A 303 redirect service is not new; that's exactly what
> purl.org is. He is also not sure that 303 is simple
> for slash namespaces -- see recipe 2a. You still need a
> rule that catches multiple targets. It is similar to the
> partial redirect problem in purl.org. If t-d-b could be
> configured then lots would be easier, but without that
> t-d-b is functionally equivalent to purl.org partial
> redirects; and t-d-b relies on the persistence of 2 URIs
> whereas purl.org only relies on the persistence of one
> (purl.org) URI. This option has not been fully explored,
> so we should look more closely at the supposed simplicity
> of the 303-redirect solution and consider whether TDB is
> really the best alternative.
>
> -- Point 2: "Title of Section 3" "Big-picture overview of
> server configuration steps" David suggests some text to add
> [2].
>
> -- Point 3: "Title of Section 3"
> Currently called "Some considerations when choosing a URI
> namespace". David suggests: "Choosing a namespace URI: hash
> versus slash".
>
> Alistair opposed to renaming the section to include
> "hash vs slash" text (Ralph agrees): we want to take out
> all references to past quagmires and think about readers
> coming to document for first time - they want clean,
> concise look at problem.
>
> -- Point 4: "Wording in Section 3"
> David suggests a change of wording in one sentence in line
> the new title (see 3 above).
>
> Ditto for wording of section three: better not to bring up
> old arguments about hash versus slash.
>
> ACTION Ralph: Contact Matthew Ellison about our interest in
> having STC participate in VM writing.
>
> Matthew Ellison <matthew.ellison@email.com>: represents
> Society for Technical Communication (STC), a W3C that is
> providing volunteer resources for a range of W3C writing
> and eLearning development activities. These activities
> include editing specifications, developing tutorials
> for W3C tools and technologies, and writing summaries on
> emerging W3C technologies and specifications.
>
> -- "More-helpful comment line in the recipes"
> Suggests a few more words.
>
> -- Point 5: "Pros and cons of
> hash versus slash URIs". David requests
> "more-explicit guidance on hash versus slash URIs" --
> additional discussion of Pros and Cons.
>
> Alistair: Text of David's suggested editor's note isn't
> quite correct. Also, prefer to keep this document at the
> need-to-know level. If some pros and cons are to go into
> this document, they ought to be as simple as possible and
> gently worded. Would prefer if all document on making
> choices were made externally to this document (i.e.,
> in another document), then just cite it.
>
> Ralph: Hard to keep this document both simple, and detailed
> enough for people curious to look under the hood. Feels
> right to have an entirely separate discussion document.
>
> -- Point 8: Numbering of sections is requested.
>
> -- Point 9: s/URI namespace/namespace URI/ throughout
>
> ----------------------------------------------------------------------
> ISSUES ALREADY DISCUSSED - Structure of Cookbook document as a whole
>
> -- Tom proposed putting the requirements at the top, etc:
> http://lists.w3.org/Archives/Public/public-swbp-wg/2006Mar/0048.html
>
> Tom: As currently written, there is nothing in the
> introductory sections that simply says: "This document shows
> you how to publish both machine- and human-readable versions
> of a vocabulary." The requirements need to be expressed
> up-front in some form, if only in a sentence or two.
>
> Alistair: Deliberately put the "Requirements" section at
> the back of the document because it is not need-to-know
> for the reader -- it's really there for the WG. I'd rather
> the Requirements were not there at all.
>
> Ralph: Putting in alot of editorial notes, then stripping
> them out in the final product is not a bad process.
>
> Alistair: the "Apache Configuration" section is another
> thing that could be moved to an Appendix. The important
> section is Choosing a recipe -- we want to get the reader
> there as quickly as possible. Introduction, then Choosing a
> Recipe, directly.
>
> Tom, Ralph, Alistair agree: Need to provide the motivation
> for this specification in the introduction. Alot of the
> detail could be pushed to appendix: URI namespaces; the
> second Apache configuration. We need to decide what to
> expect of readers - will help us decide what to keep in.
>
> If we physically move stuff down, then flavor becomes
> "we don't think you want to see the details..."...
> That tone is a dramatic change from what we have now.
> Diagrams helped us, but may not be necessary for the
> intended users. Simple visual images could perhaps convey
> these choices with less detail.
>
> -- Recipe 6 is still a placeholder [*].
> [*] http://www.w3.org/TR/2006/WD-swbp-vocab-pub-20060314/#recipe6
>
> --
> 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 Friday, 31 March 2006 13:47:05 UTC