W3C home > Mailing lists > Public > public-awwsw@w3.org > January 2011

Re: [Fwd: Reversing HTTP Range 14 and SemWeb Cool URIs decision]

From: Jonathan Rees <jar@creativecommons.org>
Date: Thu, 20 Jan 2011 17:00:53 -0500
Message-ID: <AANLkTimt_=JsEPby8SkA8JAYUFzGR=a5FWDs+6auyMmX@mail.gmail.com>
To: nathan@webr3.org
Cc: AWWSW TF <public-awwsw@w3.org>
This is at least the third time the suggestion to change the
convention has come up in recent months. There's clearly a disconnect
of some kind.

The issue is interoperability. If different agents interpret a URI in
incompatible ways, confusion will result. The httpRange-14 rule nudges
the community to interpret certain URIs in a particular way, removing
choice in the interest of consistency.

One answer to the engineers is: If you're doing this in the privacy of
your own world, it doesn't matter whether you use a 200 or 303 or 627
or # or ?. But for the semantic web you're advised to use # (or 303)
because that's the way the semantic web is designed. If you write RDF
that uses a 200-responding URI in some creative way, someone else
(e.g. an agent that either doesn't read, or doesn't believe, or
doesn't know how to process the content) could use the URI to refer to
the web page, and friction will result.

I sort of understand why people think 303 is hard (but I have to take
it on faith since with the software I use it's easy). I really don't
understand why people think using # is a burden. (I understand Alan
R's objections to #, but they're of a very different nature.)

As I've recently said to Ed Summers, if someone really thinks that
changing the convention is possible and necessary, they ought to go
through process, and talk to the groups responsible for the technology
that they are enjoying: the TAG, SWIG, SWCG, etc. Whinging about this
on some semantic web list undermines the idea of standards. Otherwise
- just deal with it.

Complaining that httpRange-14 has never gone rec track (to receive
review) is absolutely legitimate - but no one has come to the TAG and
asked for it to. I've never heard anyone question the legitimacy of
the decision, only the wisdom of it.

Anyhow... sorry, we shouldn't take up the debate on this list - we're
all fatigued by it. I think AWWSW's job might be:
1. how would you refer to a web page, defensively, if you didn't know
how the receiving agent was going to interpret 200-yielding URIs
(httpRange-14 vs. whatever)?  (using terms from the awwsw vocabulary,
I would presume.)
2. is there any practical reason to choose the httpRange-14 rule over
some other rule? (I believe there is - e.g. it gives an easy way to
write metadata and metadata is good.)
3. advise the TAG on PR or other followup regarding the httpRange-14 rule


On Sun, Jan 16, 2011 at 6:18 PM, Nathan <nathan@webr3.org> wrote:
> fwd: A real world use case from Manu Sporny in reply to my earlier mail:
> -------- Original Message --------
> Subject: Reversing HTTP Range 14 and SemWeb Cool URIs decision
> Date: Sun, 16 Jan 2011 18:06:29 -0500
> From: Manu Sporny <msporny@digitalbazaar.com>
> To: Nathan Rixham <nathan@webr3.org>
> Hi all,
> Just wanted to follow up Nathan's post with a few more points. I pinged
> him about this very issue yesterday because I wanted to see if he had
> come to the same conclusion that we had after a number of years of
> dealing with the repercussions of the HTTP Range 14 decision and the
> solution offered by the Cool URIs for the Semantic Web[1] document.
> In general, I agree with Nathan's argumentation. The concepts outlined
> in [1] do make sense in many cases, but when implemented in a business
> environment, they lead to conceptual and engineering overhead that our
> developers are just not willing to accept. The Cool URIs for the
> Semantic Web document is needlessly restrictive. I'll explain the reason
> below.
> Here is some background on why this matters to our company, in particular:
> We are working on a world standard for Universal Web Payment that we
> hope to send through the W3C or IETF process at some point, it's called
> PaySwarm and you can find out more about it here:
> http://payswarm.com/
> PaySwarm is a decentralized payment system with multiple transaction
> processors (effectively, banks) that are capable of executing commercial
> transactions (think buying and selling digital goods, like webapp stores
> or access to blog content/entertainment). These transaction processors
> create legally enforce-able digital contracts between people and
> transfer money between financial accounts. A demonstration of the
> purchasing process can be found here:
> http://digitalbazaar.com/2010/09/12/payswarm-api/
> The end result of a purchase between a website operator and a customer
> is a Contract. The Contract contains a number of digital signatures,
> Assets (a description of what was purchased), a License, financial
> accounts, the asset provider, the purchaser and a number of other
> "things" that are all identified via URIs.
> We want these URIs to be very long lived - 10, 20 or even 50+ years.
> We are using HTML+RDFa to express semantics via the pages and JSON-LD[2]
> for the messaging between all the distributed parts of the system.
> You can see an example of what a financial transfer looks like in this
> system here (skip down to the Example):
> http://purl.org/commerce#transfer
> In other words, we have completely bought into the benefits that the
> Semantic Web can offer and we are building a decentralized financial
> system that takes advantage of those benefits.
> This brings us to the end of Nathan's postal code example:
> Nathan Rixham wrote:
>> I don't see a problem with any of the above, neither does anybody in
>> this scenario afaict - can you see a problem?
>> Now, this example isn't constrained technically, and nothing breaks -
>> however it does break current web arch rules because:
>>  - it doesn't use the 303 pattern
>>  - it fails to make any distinction between IR and NIR
>>  - it fails to make any distinction between primary and secondary
>>    resources
>>  - it names the same concept in one case as an IR, and in another as
>>    an NIR, although they're both the same thing
>>  - the cool uris, change (they're uncool)
> Currently, our identifiers for long-lived resources look like this:
> https://mybank.example.com/deposits/7f7f62ab53cc623cd28#deposit
> https://mybank.example.com/accounts/3879279824#account
> https://payswarm.example.com/people/john-doe#public-key-5
> However, when these identifiers were presented to our development team,
> the first question that arose was:
> "Why do we need to have #deposit at the end of the deposit URL? The same
> for account? We've designed the system to be RESTful, why are we
> duplicating information in the URL?"
> That is, instead of this:
> https://mybank.example.com/deposits/7f7f62ab53cc623cd28#deposit
> Why not this?
> https://mybank.example.com/deposits/7f7f62ab53cc623cd28
> We are designing the system to return an HTML+RDFa representation of the
> resource above when a browser hits the resource. It will contain both
> human-readable information and semantic data that is specific to the
> deposit. We are not talking about a concept that doesn't exist on the
> web. The concept only exists on the web and it's at the URL listed above.
> Our engineers see no reason to perform a 303 re-direct and maintain 3
> URLs (identifier, HTML, and RDF) for each identified resource in our
> system. That is, implementing the solution doesn't seem to prevent any
> nasty technical issues from arising, except perhaps in reasoning agents
> that assume certain things about what's at the end of a URL (it's not
> always a document). Why the implementation burden when there isn't a
> clear technical benefit?
> We don't need to re-hash all of the HTTP Range 14 discussions, nor any
> of the many e-mails and blog posts discussing the topic at length. We've
> read many of those documents and don't see why Semantic Web applications
> can't be implemented with non-hash, non-303 URLs if they are designed
> properly. That is to say that hash URLs and 303 results are reasonable
> mechanisms for semantic web identification, but so is a clean URL that
> returns HTML+RDFa, like:
> https://mybank.example.com/deposits/7f7f62ab53cc623cd28
> More to the point:
>>  - it doesn't use the 303 pattern
> The 303 pattern is very difficult for non-experts to implement correctly
> and many budgets do not allow for separate RDF documents and separate
> HTML documents. Our developers groan every time this solution is brought
> up, and for good reason. I can't find a good argument for why our
> company should spend the money to manage a URL space that is 3x as big
> for no clear technical benefit.
>>  - it fails to make any distinction between IR and NIR
> I continue to fail to see the relevant technical reason for the
> distinction. I understand the argumentation, but it is but one world
> view, and is largely philosophical. If one takes the position that
> "There is no such thing as a non-information resource on the Semantic
> Web", does a technical issue arise? It's all information and information
> is contextual, right?
>>  - it fails to make any distinction between primary and secondary
>>    resources
> In this particular case, it doesn't matter and largely simplifies the
> concepts put forth on the semantic web. This was a big point of
> contention among our developers - understanding that #fragment
> identifiers referred to one thing in a graphical browser (the @id
> attribute) and another thing in a semantic web application was a painful
> jump for them to make. It's not that they didn't get it - they just
> thought it was an awful hack and goes against the concepts of REST that
> they use when developing our systems. That is:
> You can't do this via HTTP 1.1:
> DELETE http://example.org/foo#bar
> and hope to only delete the information identified by #bar... you will
> most likely delete the entire foo resource instead. Contrast that with this:
> DELETE http://example.org/people/bob/public-keys/1
> You could delete just the information about key 1 using HTTP semantics
> above... it's much cleaner.
>>  - it names the same concept in one case as an IR, and in another as
>>    an NIR, although they're both the same thing
> Again, I hold that we shouldn't be making a distinction between an IR
> and a NIR when choosing semantic web identifiers. While there may be
> good uses for NIR (I honestly don't know of any), I don't think that the
> semantic web should use them as a part of its core architecture. If you
> use an identifier on the semantic web, it should be an IR, redirect to
> an IR (an alias, but only if the IR moved), or not exist at all.
>>  - the cool uris, change (they're uncool)
> Yes, we do all want Cool URIs, but there are cases where it is
> impossible to keep the URIs around forever. As we are all painfully
> aware of these days, banks fail - and merge. Just because my account is:
> http://blue-bank.example.com/accounts/28394723984
> today, doesn't mean that the website will exist tomorrow. Or that after
> the merge, it won't be:
> http://red-bank.example.com/accounts/afd-akop
> with a semantic web re-direct/alias from the first to the second. So,
> while we all want URIs that don't change - they will, and more often
> than we'd like.
> For financial systems like PaySwarm, especially because it will become
> an open standard, it is important that we have a clear solution on how
> to deal with these issues.
> My fear is that if we continue pushing [1] and the HTTP Range 14
> decision that developers will likely continue to view the Semantic Web
> as an over-engineered solution to a problem that they rarely care
> about... and I wouldn't blame them if they were to do that. We can't
> change developer workflow as drastically as the SemWeb Cool URIs
> proposes - especially when it is unnecessary to do so.
> Thoughts?
> -- manu
> [1] http://www.w3.org/TR/cooluris/
> [2] http://json-ld.org/
> --
> Manu Sporny (skype: msporny, twitter: manusporny)
> President/CEO - Digital Bazaar, Inc.
> blog: Linked Data in JSON
> http://digitalbazaar.com/2010/10/30/json-ld/
Received on Thursday, 20 January 2011 22:01:24 UTC

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