Re: WebID definitions and specs: conceptual vs functional

On 22 Mar 2013, at 14:48, Ted Thibodeau Jr <tthibodeau@openlinksw.com> wrote:

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

The voting was closed on 1 Febuary 2013
https://www.w3.org/2002/09/wbs/51933/webid-hash/

The identity spec was created 4 months ago in November 18th as you 
can see from the hg history:

https://dvcs.w3.org/hg/WebID/log/99ffbed7a6b4/spec/identity-respec.html

It was not that different when we voted on the WebID definition from
what it is now.

We went through a formal vote using the W3C voting system. This
gave us the consensus from which we are now working. 

I don't see that why we would get a different response now if
we tried again.

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

Social Web Architect
http://bblfish.net/