Re: A modest attempt to re-open ISSUE-20

On 3/14/13 4:08 PM, Pierre-Antoine Champin wrote:
> Kingsley,
>
> I realise my proposals with bnodes was not clear:
> it was obvious for me that the bnodes are only used in the POSTed graph.
> Once the LDP server receives it, it will coin a URI for the new resource,
> and replace the bnode with that URI,
> and store *that* new graph.
>
> So the bnodes will never be exposed outside the POST query.
> I agree that bnodes are, in most cases, a pain in the arm.

Yes, an they are a pain to implement properly modulo RDF comprehension 
which still remains mercurial.

>
>
> Regarding hash-URIs, I reallt don't get your argument.
Okay, I'll try to be clearer.

> These problems (DNS ownership, etc.) are supposed to be solved for the 
> LDP server,
> which is the one coining the URI (see above).

Any solution that alienates hash based HTTP URIs ultimately introduces a 
combination of the items it outlined. At the very least, the LDP server 
implementer is forced to deal with URI disambiguation via 303 
redirection. I already see these problems creeping into the existing LDP 
demos where entities are being denoted with hashless URIs which simply 
papers over the inevitably confusion re. URI referent ambiguity (aka. 
HttpRange-14).
> After that, the client is free to PUT more triples in the new resource
> including triples with hash-URIs based on the resource's URI
> (now that the client knows that URI).

Yes, but "after that" is subject to the implementer dealing with URI 
referent ambiguity matters which most will not want to do. This is why 
any Linked Data oriented spec needs to veer away from mandating or 
presuming a style of HTTP URI for entity denotation. The only safe axiom 
is that URIs can denote any kind of entity while URLs denote Web and 
Internet medium specific entities.

Kingsley
>
>   pa
>
>
>
> On Thu, Mar 14, 2013 at 8:53 PM, Kingsley Idehen 
> <kidehen@openlinksw.com <mailto:kidehen@openlinksw.com>> wrote:
>
>     On 3/14/13 2:50 PM, Pierre-Antoine Champin wrote:
>
>
>         I guess I still prefer my alternative, as blank nodes are
>         really that: variables. They exist precisely to denote a
>         resource whose URI we don't know. I agree that it does not
>         allow me to create hash-URI, which is a shame.
>
>     Yes, but the "shame" costs are "deceptively high" and inherently
>     exponential due to the following user burdens:
>
>     1. requiring domain name ownership
>     2. requiring DNS server access with associated privileges
>     3. requiring Web server access with associated privileges
>     4. requiring URI re-write rules for handling Linked Data
>     Name->Address redirection -- when a URI denotes an entity that you
>     can't associate with any Web or Internet content-type .
>
>     Hash based HTTP URIs and the use of "<>" in Turtle based graph
>     expressions eradicate all the headaches above. We should never
>     encourage solutions that discourage or adversely affect the
>     ability to exploit hash based HTTP URIs. We always have to look to
>     a Web where Linked Data resource management patterns are no
>     different to what we do everyday on our local machines, when
>     working with files. Overlooking this reality always gets us into
>     trouble due to inevitable real-world implementation complexity and
>     conceptual incomprehension.
>
>     Blank nodes can never be at the front door. Their utility is
>     something that only manifests way after the RDF is properly
>     understood. Look at what blank nodes did to FOAF prior to TimBL's
>     request for everyone to get a Personal URI. Same thing re. Linked
>     Data meme, in all cases, the fundamental goal is/was to leverage
>     the "deceptively simple" architecture baked into the Web.
>
>     Links:
>
>     1. http://dig.csail.mit.edu/breadcrumbs/node/71 -- Personal URIs
>     and FOAF
>     2. http://www.w3.org/DesignIssues/LinkedData.html -- Linked Data
>     meme.
>
>
>
>     -- 
>
>     Regards,
>
>     Kingsley Idehen
>     Founder & CEO
>     OpenLink Software
>     Company Web: http://www.openlinksw.com
>     Personal Weblog: http://www.openlinksw.com/blog/~kidehen
>     <http://www.openlinksw.com/blog/%7Ekidehen>
>     Twitter/Identi.ca handle: @kidehen
>     Google+ Profile: https://plus.google.com/112399767740508618350/about
>     LinkedIn Profile: http://www.linkedin.com/in/kidehen
>
>
>
>
>
>


-- 

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