- From: Leigh Dodds <leigh.dodds@talis.com>
- Date: Wed, 19 Oct 2011 17:59:10 +0100
- To: Norman Gray <norman@astro.gla.ac.uk>
- Cc: "tom.heath@talis.com" <tom.heath@talis.com>, Yang Squared <yang.square@gmail.com>, "public-lod@w3.org" <public-lod@w3.org>
Hi, [Aside: changing the subject line so we can have a clearer discussion] On 17 October 2011 14:58, Norman Gray <norman@astro.gla.ac.uk> wrote: >... > I've done far fewer talks of this type than Tom has, but I've never found anyone having difficulty here, either. Mind you, I never talk of 'information resource' or httpRange-14. > > For what it's worth, I generally say something along the lines of "This URI, X, is the name of a galaxy. If you put that URI into your > browser, you can't get the galaxy back, can you, because the galaxy is too big to fit inside your computer. So something different has to > happen, doesn't it?" A remark about Last-Modified generally seals the deal. I've done the same, and people do quite often get it. At least for a few minutes :) I think my experience echoes Rob's more than Tom's. I've had more than one Linked Data talk/tutorial de-railed by debate and discussion of the issue when there are much more interesting aspects to explore. While I've not used the galaxy example, I have taken similar approaches. But I can also imagine saying, for example: "This URI, X, is the name of a galaxy. If you put that URI into your browser, obviously you can't get the galaxy back, can you. So when you request it, you get back a representation of it. You know, just like when you request a file from a web server you don't download the *actual* file, just a representation of it. Possibly in another format". And further, if someone asked about Last-Modified dates: "Last-Modified? Well as it turns out the Last-Modified date isn't defined to be the date that a resource last changed. It's up to the origin server to decide what it means. So for something like a galaxy, it can be the date of our last observation". My point being that web architecture already has a good explanation as to why real-world, or even digital things are passed around the internet. That's why we have the Resource and Representation abstractions in the first place. So, can we turn things on their head a little. Instead of starting out from a position that we *must* have two different resources, can we instead highlight to people the *benefits* of having different identifiers? That makes it more of a best practice discussion and one based on trade-offs: e.g. this class of software won't be able to process your data correctly, or you'll be limited in how you can publish additional data or metadata in the future. I don't think I've seen anyone approach things from that perspective, but I can't help but think it'll be more compelling. And it also has the benefits of not telling people that they're right or wrong, but just illustrate what trade-offs they are making. Is this not something we can do on this list? I suspect it'd be more useful than attempting to categorise, yet again, the problems of hash vs slash URIs. Although a canonical list of those might be useful to compile once and for all. Anyone want to start things off? As a leading question: does anyone know of any deployed semantic web software that will reject or incorrectly process data that flagrantly ignores httprange-14? Cheers, L. -- Leigh Dodds Product Lead, Kasabi Mobile: 07850 928381 http://kasabi.com http://talis.com Talis Systems Ltd 43 Temple Row Birmingham B2 5LS
Received on Wednesday, 19 October 2011 16:59:49 UTC