W3C home > Mailing lists > Public > public-webpayments@w3.org > March 2013

Re: PaySwarm Alpha 6 Released

From: Kingsley Idehen <kidehen@openlinksw.com>
Date: Mon, 04 Mar 2013 08:50:04 -0500
Message-ID: <5134A68C.7050809@openlinksw.com>
To: public-webpayments@w3.org
On 3/3/13 9:31 AM, Manu Sporny wrote:
> On 03/03/2013 09:02 AM, Melvin Carvalho wrote:
>> >1. I presume hash based currencies will be supported, I use the
>> >'facebook' style ofhttps://w3id.org/currencies/USD#  
>> ><https://w3id.org/currencies/USD>  (note the trailing hash) this is
>> >to distinguish the document from the currency and also future proof
>> >allowing extra subjects to reside in that document.
> Yes, hashes in currencies are just fine. So, this is perfectly valid:
>
> http://example.org/myapp#credits
>
> PaySwarm treats the identifier opaquely, but expects Currency Mint
> endpoint information to exist at the currency URL (such as where do I go
> to get new units of this currency).
>
> As far as distinguishing the Document from the currency, we're delving
> into HTTP Range-14 territory, but we never really liked the solution
> proposed by the TAG for that. Our interpretation of URLs on the Web can
> be summarized like this:
>
> You don't know if a URL is for a document or a resource of another
> nature (like a currency) until you dereference the URL. Once you get a
> representation, check the representation to find out the "rdf:type".
> This avoids all the crazy 30x redirection that HTTP Range 14 requires
> and is a fairly straight-forward way of figuring out what a resource on
> the Web is. One could go a step further and do one of two things:
>
> 1. If a resource doesn't have an rdf:type on the Web, you can assume
>     it's a document, or
> 2. If a resource doesn't have an rdf:type on the Web, you can't
>     assume anything about its type other than by inference.
>
> ... leaning more toward the latter than the former.
>
Manu,

Redirection isn't crazy, its an option.

Choosing to be a smarter RDF based Linked Data client is an option too. 
What you outline is one of the options that's always been artificially 
nascent i.e., An RDF consumer should be able to use RDF model 
comprehension to disambiguate the HTTP URIs of a retrieved descriptor 
(description) document entity and other entities described by said 
document.

Here are the options:

1. implicit disambiguation via hash based HTTP URI -- easy to deploy but 
cloaks other problems and doesn't use RDF model comprehension to drive 
entity identity disambiguation
2. explicit disambiguation via HTTP redirection -- harder to deploy and 
doesn't use RDF model comprehension to drive entity identity disambiguation
3. explicit disambiguation driven by RDF model comprehension -- works 
fine, but many fear that RDF reflux sufferers won't accept the 
requirement for RDF model comprehension (esp. when they assumed RDF/XML 
== RDF).

#3 is the best solution, it takes the distracting issue of hash vs 
hashless URIs off the table.

The HttpRange-14 permathread is such because of the mangled interests 
and knowledge of the imbroglio's participants :-)


-- 

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






Received on Monday, 4 March 2013 13:50:31 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:07:22 UTC