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

Re: [VM] Final telecon, Friday 2006-03-31 - note times!

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>
Message-ID: <20060331054605.T81967@skutsje.san.webweaving.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

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