Re: Web Identity draft spec released

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?

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

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

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.

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.

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;

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.

</strong opinion>

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

Received on Monday, 25 November 2013 15:55:28 UTC