WebID definitions and specs: conceptual vs functional

All --

The bulk of the past several WebID Community Group calls has been 
lost to rehashing (pun somewhat intended) the definition of WebID, 
and trying to move on from there.

I am hoping that the following will help us to finally get past
this, and to start making real progress on developing both the
conceptual and functional specifications.

In sum --

In October, we had one spec document [a], which horribly blurred 
the lines between conceptual and functional, and tried to handle 
both things at once.  This led to the very broken definition of 
WebID that came out of TPAC.

[a] https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/index-respec.html


In November, we still had just the one document, and in a long 
call with TimBL and others (who mainly haven't joined since), 
where we concluded that we *should* have *two* (to start, with 
more to come in time), with clear separation between the broad 
conceptual spec and the much more targeted and thus much more 
limited functional spec.

In December or January, a new document [b] was created, to be 
the conceptual spec.  The original doc was to be replicated
into [c] and have the content which was redundant against [b]
removed, thereby to become the first functional spec -- i.e., 
WebID-over-TLS.  As I understood things, [a] was then to be
discarded except for historical purposes.

[b] https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/identity-respec.html

[c] https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/auth-respec.html


The functional spec [c] was to be intentionally narrow in focus,
dealing only with HTTP URIs for WebIDs, and showing only hash-
based URIs in the examples, all intended to make the early
implementer's job easier -- all as discussed in that November
concall.

The conceptual spec [b], on the other hand, was to retain the 
original breadth of vision -- see ISSUE-42 [d], ISSUE-55 [e]) --
among other things, allowing for other URI schemes (whether FTP, 
SPDY, LDAP, or otherwise), getting specific only where vital -- 
i.e., *URI dereferenceability.*

[d] http://www.w3.org/2005/Incubator/webid/track/issues/42

[e] http://www.w3.org/2005/Incubator/webid/track/issues/55


Since then, we've been going in circles, re-blurring and re-
clarifying the lines between conceptual and functional, and 
even as everyone on recent calls has agreed that *conceptually* 
speaking, a WebID should be "a dereferenceable URI", we no sooner 
agree on that than someone says that we voted to define a WebID 
as "an HTTP(S) URI" ... entirely overlooking or ignoring the fact
that the ballot was not clearly written to say whether the question
was regarding the definition to be used in the *functional* spec 
(as I was thinking) or the *conceptual* spec (as it seems some 
*may* have been thinking), and that the voting took place while
there was still only *one* spec.


Re-reading ISSUE-55 just now, I saw again the quote DanBri put
in from TimBL's DesignIssue "Axioms" [f] --

   "There is a lot of flexibility and growth to be gained by 
   allowing any sort of URI, not one from a particular scheme, 
   in most circumstances. Similarly, one should not make 
   assumptions about the schemes involved. This is a facet of 
   the particular parameters about how the technology is  used. 
   The choice of type URI in a [practical] use of a language is 
   an important flexibility point."

[f] <http://www.w3.org/DesignIssues/Axioms.html>

-- and I was inspired to go look at Axions once more myself.  

There I found this remarkably relevant gem --

   Axiom: Opacity of URIs

   The only thing you can use an identifier for is to refer to 
   an object. When you are not dereferencing, you should not 
   look at the contents of the URI string to gain other 
   information.

In other words -- whether it contains a hash or not; whether
its scheme is http or spdy or lmnop; whether it's short or long,
human comprehensible or pure gibberish -- all of this must be 
ignored *except* when *actually dereferencing,* which is not 
conceptual, but functional.
  

PROPOSAL: WebID Definition *for the Conceptual Spec [b]*: 

   A WebID is a URI which denotes an Agent, and which, when 
   dereferenced, yields a document which describes that same 
   Agent, which document includes internal statements which 
   self-describe it as describing that Agent, *and* which use
   the same URI as was dereferenced to GET that this document 
   to identify that Agent.  (This URI need not be the *only*
   URI which identifies this Agent, nor even the *primary* URI
   used in this document.)


Other definitions, restricting to HTTP(S) URIs, or otherwise,
may be appropriate to particular functional specifications, 
such as the currently planned WebID-over-TLS.  I will leave
proposals for such until later (or for others to make).

Be seeing you,

Ted

 


--
A: Yes.                      http://www.guckes.net/faq/attribution.html
| Q: Are you sure?
| | A: Because it reverses the logical flow of conversation.
| | | Q: Why is top posting frowned upon?

Ted Thibodeau, Jr.           //               voice +1-781-273-0900 x32
Senior Support & Evangelism  //        mailto:tthibodeau@openlinksw.com
                             //              http://twitter.com/TallTed
OpenLink Software, Inc.      //              http://www.openlinksw.com/
         10 Burlington Mall Road, Suite 265, Burlington MA 01803
     Weblog   -- http://www.openlinksw.com/blogs/
     LinkedIn -- http://www.linkedin.com/company/openlink-software/
     Twitter  -- http://twitter.com/OpenLink
     Google+  -- http://plus.google.com/100570109519069333827/
     Facebook -- http://www.facebook.com/OpenLinkSoftware
Universal Data Access, Integration, and Management Technology Providers