Re: Web Identity draft spec released

On 25 November 2013 16:55, Manu Sporny <msporny@digitalbazaar.com> wrote:

> On 11/24/2013 08:59 PM, Melvin Carvalho wrote:
> > A few comments:
> >
> > 1. There may be a potential naming confusing with the proposed, and
> > quite similar:
> >
> > "Web Identity and Discovery:
> >
> > https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/identity-respec.html
>
> Agreed, any suggestions on what to change it to?
>

Both specs say roughly the same thing except that one has mandatory support
for turtle and the other has mandatory support for JSON LD.  Both have a
pretty decent tool set, which are only likely to get better.  JSON LD also
works quite well as a message interchange format.  The systems I write
already support both JSON and turtle, so I dont mind which, personally :)


>
> > 2. I would suggest having json ld as the only mandatory serialization
> > to be supported, but allowing other w3c RECs to be returned, such as
> > turtle
>
> +1
>
> > 3. Terms such as "email": "bbob@example.com
> > <mailto:bbob@example.com>" ... I wonder if this would benefit from
> > adding mailto: in front of it, or is that handled in the @context?
>
> It's not handled by the @context, and I don't quite know what adding
> mailto: would buy us, other than making it a URI. My concern with
> requiring mailto: at the beginning is that I don't think many developers
> would do the right thing and add it to the beginning, leading to the
> field having to be post-processed by many applications.
>

I get it.  There's a trade off with syntactic sugar, in that while it may
be easier for humans to work with, it's harder for machines.  I think in
the short term it's slightly advantageous to drop the mailto: but in the
longer term it's better to be accurate.  One of the axioms of the web is to
use a URI for anything of significance.  At the end of the day it's up to
the vocab writer to choose between literals and URIs and that's totally
fine, it's something we can work out a consensus for.


>
> > 4. I personally normally prefer to use hash URIs, rather than, the
> > 303 or describedBy patterns to distinguish objects from documents.
> > In payments it's of course important to send money to the right
> > place! :)
>
> <strong opinion> :P
>
> I personally think that 303 is a non-starter for any Linked Data
> application. Many developers don't understand the nuance and will thus
> mess it up, which will lead to ambiguity such that no developer will be
> able to depend on 303s.
>

Yes this is quite tricky.  It's the equivalent of explaining pointers to
someone learning C.  Most people dont even know that URLs are pointers on
the web, with full pointer dereferencing and even pointer arithmetic.  But
that's how http and the architecture of the www is defined, just in C
incorrect use of pointers can have unexpected consequences.  In most cases
the web is fault tolerant, but with payments, you want to be careful that
they dont go to ambiguous identities.


>
> There's nothing majorly wrong with hash URIs, except that the
> requirement of their use can be a bit confusing to most Web developers.
> For example:
>
> https://example.com/identities/melvin#person
>
> I've found that I have to explain to developers why #person is needed at
> the end of the URI when there is only one object at that URL (in the
> payments and identity use cases). That this has to be explained so often
> leads me to believe that we'll have the same problem w/ hash URIs being
> used to differentiate between the document and the object than we do
> with 303s.
>

Yes, I agree it can be a challenge to explain.  However, I've never found
it a challenge to explain to a NON technical person in 1-2 minutes.  Only
to a technical person that has pre conceived notions have I found it more
difficult.

The simple fact is that in http, URLs are not 100% opaque.  By default URLs
without a hash are a document type, and URLs with a hash are an object
type.  Now, in another scheme that need not be the case, but in http, for
better or worse, it is.  You could argue that it is something that should
not have been, but I would actually say it's a good feature of http,
because it allows data to be either embedded in a web page, or sent over a
communications protocol, and even signed.

What we often do is "auto correct" those that have made the mistake by
adding #this to the document.  Much like the way the 'this' keyword is used
in programming languages.  It's also dangerous because you are second
guessing the author.  Better that people just follow http as it is today,
imho.


>
> One solution that I've seen proposed that works with most Web developers
> is the idea that the rdf:type of the object determines what the object
> actually is. So, if you have this:
>
> <https://example.com/identities/melvin> a wi:Identity;
>
> Then clearly, the URL is an identity, not a document.
>

We have a technique for this called the "PersonalProfileDocument" ... it's
possible to do that kind of thing yes.


>
> If you need to talk about the document as well, then you can use a hash
> URI, but in many cases, you don't need to do it because you rarely ever
> need to talk about the document in the same graph store. If you do need
> to talk about the document, you should create an internal identifier for
> it and use that instead, for example:
>
> <myscheme:sha256(https://example.com/identities/melvin)> a xyz:Document;
>

There's an ni: scheme that is very useful for hashes ... e.g. ni://sha256;
which also has a well-known location at .well-known/ni/sha-256/ ... I am
starting to use to pattern a lot, especially when modelling bitcoin for the
web.

In truth sometimes you'll want a bunch of entities in a document, sometimes
it will be one to one.  That's fine the web can handle either case.


>
> The common case is that you don't need to talk about the document, so we
> should be designing for that. There are many ways to talk about the
> document, and we should be careful to not put that on the same (or
> higher) level as the object.
>

We should certainly handle the common case, but it's not terribly hard to
support awww by inclusion of hash URIs too.  I personally think using hash
URIs will give you a competitive advantage in the long run ... but I'm
completely happy with various trade offs.  In writing a standard however,
it's also important to respect the other standards on which it is built,
imho.


>
> </strong opinion>
>

Strong opinions are totally fine ... I much prefer a conversation that
talks about trade offs, and then makes choices based on the pros and cons :)


>
> -- manu
>
> --
> Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
> Founder/CEO - Digital Bazaar, Inc.
> blog: Meritora - Web payments commercial launch
> http://blog.meritora.com/launch/
>
>