On 10/19/11 12:59 PM, Leigh Dodds wrote:
Hi,[Aside: changing the subject line so we can have a clearer discussion] On 17 October 2011 14:58, Norman Gray<[email protected]> 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.
This is the biggest problem.
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.
Yes, but to whom are you presenting that anecdote?There are many profiles of end-users, power users, and developers that already understand that digital objects represent things (any observation subject).
Ending up with a debate that leads to convincing an audience about the non materialization of a galaxy in their browser is part of the problem (IMHO).
I don't every recall explaining the a record in a customer table != manifestation of the customer in a given DBMS, for instance. Arriving at this juncture re. Linked Data is quite prevalent, and that's why I take the position that the narrative is broken.
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.
Yes, but the architecture can end up getting lost in problematic narrative comprised of problematic anecdotes, as per my earlier comments.
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?
But you don't have two different resources. Please correct me if I am reading you inaccurately here, but are you saying that:
http://dbpedia.org/resource/Linked Data and http://dbpedia.org/page/Linked Data == two different resources?
I see: 1. 2 URIs2. a generic URI (serving as a Name) and a purpose specific URI called a URL that serves as a data access address -- still two identifiers albeit split by function .
I assume you see the same or something different?
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.
Crossing the bridge re. #1 & 2 above, should lead us to a place where slash and hash URIs are simply about publisher oriented implementation details re. Linked Data deployment.
Without transformation heuristics how will they work? We do a lot of transformations because we approach things skeptically, but I really don't think that's the norm.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.
-- Regards, Kingsley Idehen President& CEO OpenLink Software Web: http://www.openlinksw.com Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca: kidehen
smime.p7s
Description: S/MIME Cryptographic Signature
