W3C home > Mailing lists > Public > public-awwsw@w3.org > January 2011

reviewing the charter of awwsw

From: Jonathan Rees <jar@creativecommons.org>
Date: Fri, 14 Jan 2011 17:30:19 -0500
Message-ID: <AANLkTin=053ZmBtZZyy9CkB3AZrRTNuptQZtUF0JwCUi@mail.gmail.com>
To: AWWSW TF <public-awwsw@w3.org>
Feeling a bit exposed by the addition of a new person, I just took a
few minutes to look at the genesis of our charter, which was recorded


Here are some of the topics that were discussed at that meeting:

  'information resource'
  how to make the semantic web work reliably
  what URIs to use in HCLS context
  RDF & URIs in published papers
  URI insurance policies
    e.g. fallbacks when links are found to be broken
  promises of stability (TBL suggested 'fixed resource')
  warnings of instability ('this is a demo')
  dual use of URI in denoting and providing access - the "magic of webarch"
  trust earned by info: and LSID
  unreliability of 303

Somehow the precipitate of all this was to convene a series of calls
"on HTTP semantics". I'm not sure this wording accurately describes
what those who signed up for it had in mind - there's no record
linking what transpired in the meeting to the action to form the
group.  It may have been scribed this way because of Dan Connolly's
observation that something was the "same thing as Tim's call to do a
group to formalize HTTP" (for which I don't have a reference).

So where do we stand on the above issues?
  - Little tangible progress on 'information resource' but I haven't given up.
  - Henry T. and I have been working on reliable URIs as TAG ISSUE-50.
This is very hard and outside the scope of AWWSW.
  - What URIs to use for HCLS - this question ended up being outside
AWWSW - e.g. the "shared names" coalition took Dan C's recommendation
seriously; still somewhat hostage to the reliable URIs question.
  - Fallbacks - as far as I know the only movement on this is the
statement in the GBIF identifiers report (which I helped write), which
indeed is what Dan C would describe as taking parts of URI space by
eminent domain.
  - warnings - not much demand yet, but demand might be stimulated by
any new persistence solution
  - dual use of URI  - related to 'information resource' - this has
ended up taking most of my attention here in AWWSW
  - info: and LSID - this question has faded from view as LOD blooms -
info: seems to be moribund, and LSID has only a few new adopters (in
biodiviersity informatics) - however URNs generally continue to have a
following, and the reliability of http: is still an open question
  - unreliability of 303 - LOD is exerting a lot of standardization
pressure here.  Alan R is probably still bothered by the lack of any
expectation setting.  In my mind it's less of an issue than I thought
it was at the time (I didn't know no non-LOD 303s were deployed, and I
didn't know how ready HTTPbis would be to endorse GET/303)

Questions like "how do you figure out what a URI means" didn't come up.

TimBL presciently said "A danger is failing to focus the group
sufficiently narrowly.  Risk is that the group tries to do
everything." He was referring to the HCLS URI note I think, but that's
way too broad and goes way beyond 'HTTP semantics'. The need to limit
scope may explain why it ended up as "HTTP semantics," putting
reliability and nose-following out of scope for us, and why I've
insisted on hammering on the "dual use" issue, which is the only
remaining intersection between the discussion at the meeting and the
heading "HTTP semantics".

So I have now refreshed my understanding of why this is the topic that
I've been pushing on so hard here.

In spite of this focus I have found it very difficult to untangle the
issues. For me to understand "dual use" with any depth it seems I have
to pick apart all the core web specs (3986, 2616, AWWW) as well as RDF
semantics; on top of this I need to understand document semantics
(still an open problem in library science) and all sorts of
philosophical nastiness I'm unqualified to process.

The rest of our work on HTTP is still relevant, but relatively easier,
so I'm not too worried about it. If we had a customer for it that
would help move it along faster.

Reliability and nose-following are clearly important. Maybe they
should have their own task forces.

Received on Friday, 14 January 2011 22:30:48 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:21:08 UTC