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

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

From: Thomas Baker <tbaker@tbaker.de>
Date: Fri, 31 Mar 2006 10:14:20 +0200
To: SW Best Practices <public-swbp-wg@w3.org>
Message-ID: <20060331081420.GA1780@Octavius>

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
Zakim: +1-617-761-6200
Conference code 8683# ('VMTF')


    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.


    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


    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.


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
    defining classes
    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

VM TASK FORCE WEB PAGE - as of November 2005

   Short-term objectives

   -- To define (in a 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
   -- 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
      requires 303 (Redirect). This was discussed in a mailing list
      In July, Dan asked TAG
      whether a 302 response on a purl.org URI would be acceptable. As
      of November, Alistair has included purl.org scenarios in the draft

   -- 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"

   -- 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
      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
      <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

   -- 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

          o Part 2. Metadata

   -- Principles of Good Practice (see Wiki draft
          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

   See also

   -- 2005-11-22, Vocabulary Management Task Force progress report


   -- SWBP Thesaurus Task Force (THES)
   -- TAG decision on httpRange-14
   -- SWBP response to TAG decision on httpRange-14

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

-- 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:

   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 08:14:21 UTC

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