Re: WebID definitions and specs: conceptual vs functional

On 3/22/13 9:48 AM, Ted Thibodeau Jr 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.
>
>
> 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

+1

seeAlso: http://twitpic.com/cbjxkj  -- it's also "use hash based HTTP 
URIs for examples" compliant.

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


-- 

Regards,

Kingsley Idehen	
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen