- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Mon, 04 Mar 2013 08:50:04 -0500
- To: public-webpayments@w3.org
- Message-ID: <5134A68C.7050809@openlinksw.com>
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
Attachments
- application/pkcs7-signature attachment: S/MIME Cryptographic Signature
Received on Monday, 4 March 2013 13:50:31 UTC