Re: WebID definitions and specs: conceptual vs functional

On 22 March 2013 23:53, Ted Thibodeau Jr <tthibodeau@openlinksw.com> wrote:

>
> On Mar 22, 2013, at 10:14 AM, Melvin Carvalho wrote:
> > On 22 March 2013 14:48, Ted Thibodeau Jr <tthibodeau@openlinksw.com>
> wrote:
> >
> >> 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.
> >
> > Opacity is an ideal which is NEVER actually used in practice.  Consider
> a URI, you introspection on the string before the : to find out the
> protocol.  Similarly, you will parse an HTTP URI in accordance with the
> HTTP regular expressions, gleaning from it what you can.  That said, it's
> better to be opaque if you can.
>
> Melvin --
>
> I submit that your URI introspection is *part of the functional
> process of dereferencing.*  It is not part of the conceptual
> act of identifying, where the only question is whether *this*
> URI string is the same as *that* URI string.
>
> You don't need to know the scheme (which leads you to the
> protocol) until dereferencing.
>
> You don't parse an HTTP URI until you know it's HTTP, which
> you don't need to know until you're dereferencing.
>
> Etc.
>
>
> >> 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.)
> >
> > A bit of a mouthful.  I made my mind up on this 1-2 years ago, and that
> is that I will support the consensus view.  I'm keen to see WebID shipped,
> whatever the smaller details are, I know in my mind what a WebID is and
> what it can be used for.
>
> I want to get the broad conceptual definition right so that "what
> WebID *can* be used for" (my emphasis) is preserved -- because if
> we limit the conceptual definition according to the limited initial
> functional implementations (which are likely to have their own
> operational definitions, and that's fine!), we severely limit
> what it *could* be used for.
>

Conceptually WebID is about a clean separation of concerns (axioms of
modularity and simplicity), it is wide ranging (axiom of universality, test
of independent invention).

Now, the current spec violates some of this, for perceived short term gains
e.g. by tying some WebID to Turtle or FOAF or HTTP etc.    And that's fine.

What's important for us is to remember the long term value of WebID in line
with web axioms, using the spec as a guide, without needing to be a
straight jacket.

In time all of this will converge.


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