- From: Michael Smethurst <michael.smethurst@bbc.co.uk>
- Date: Thu, 20 Oct 2011 14:38:18 +0100
- To: Kingsley Idehen <kidehen@openlinksw.com>, <public-lod@w3.org>
- Message-ID: <CAC5E2DA.2951F%michael.smethurst@bbc.co.uk>
Yes, like I say, I think you agreed Nothing to be ashamed of :--Z On 20/10/2011 12:21, "Kingsley Idehen" <kidehen@openlinksw.com> wrote: > On 10/20/11 2:38 AM, Michael Smethurst wrote: >> RE: Explaining the benefits of http-range14 (was Re: [HTTP-range-14] >> Hyperthing: Semantic Web URI Validator (303, 301, 302, 307 and hash URIs) ) >> >> Hello! >> >> Don't want to sound hopelessly naive but for one second (until the >> nomenclature wars reignited) I did see a small chink of agreement there. >> >> Paraphrasing I think Leigh was saying the resource / representation split >> was already quite an abstraction and enough for most people in most >> circumstances. If we need more abstraction (nirs) on top of that we have to >> justify why / what they add >> >> Paraphrasing Kingsley I think he was saying that he doesn't really see the >> need for the nir so long as he sees name / address separation in best >> computer science fashion >> >> > > Yes. > > >> >> >> >> Harking back to the earlier thread I think we've conflated httprange-14 / >> non-information resources / 303s with connect negotiation. Some of us even >> call the 303 bit conneg. Which it isn't... >> >> > > Correct. > > >> >> >> >> Getting back to http / rest and reintroducing the *generic* information >> resource urblah conneging to concrete (for some defn of concrete) information >> representation urblah (missing in dbpedia and lots of other published linked >> data) gives Kingsley everything he wants. (I think) >> >> I'm suggesting that Kingsley's "name" is not the nir uri because whether >> something can or can't be sent down the wires doesn't concern him. So: >> >> name = generic information resource urblah >> >> > You assign names to data objects. A data object is an encapsulation of data > that can be simple of complex. In all cases data objects are accessible via > addresses. In all cases, you access a data object via act of de-reference > (irrespective of levels of indirection). > >> >> >> address = specific representation url (exposed in content location headers >> and rel="alternate" < forgot that bit earlier) >> >> > address (a URL) = how you get at the data, basically, data object access is > the prime function. That isn't necessarily the case if you use a URL as a > generic name i.e., one doesn't assume data object access, you can only assume > data object identification. > > The intuition challenge here is that URLs are being perceived as being > indistinguishable from URIs at both the functional and conceptual levels. A > URL being a kind of URI implies they are related but not identical. Thus, > using URLs as data object names is quite *unintuitive* but extremely > *ingenious*, especially in the context of the World Wide Web. > >> >> >> >> If we could even agree on that then the question of whether / when we also >> need the nir / 303 could at least continue without bickering over labels. >> Although with no more guarantee of reaching any kind of conclusion :-) >> >> > > Once we cross the conceptual hurdle re. URLs and URIs, the matter will die > IMHO. > > As I said in prior posts, this matter re. URI and URLs is occurring due to a > Syntactic focus. These very same Syntax focused issues mire general > discussions about directed graphs e.g., how you represent them and/or > serialize them across the wire. > > >> >> >> >> I could of course be wrong :-/ >> >> > > We'll get there esp. now that we have quite concrete points of focus re. > these debates. > > Kingsley > >> >> >> >> As you were.... >> >> michael >> >> >> >> >> -----Original Message----- >> From: public-lod-request@w3.org on behalf of Kingsley Idehen >> Sent: Wed 10/19/2011 6:44 PM >> To: public-lod@w3.org >> Subject: Re: Explaining the benefits of http-range14 (was Re: >> [HTTP-range-14] Hyperthing: Semantic Web URI Validator (303, 301, 302, 307 >> and hash URIs) ) >> >> 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<norman@astro.gla.ac.uk> >>> <mailto: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. >> >> 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 URIs >> 2. 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. >> >>> > 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? >> 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. >> >> >>> > Cheers, >>> > >>> > L. >>> > >> >> >> -- >> >> Regards, >> >> Kingsley Idehen >> President& CEO >> OpenLink Software >> Web: http://www.openlinksw.com >> Weblog: http://www.openlinksw.com/blog/~kidehen >> <http://www.openlinksw.com/blog/%7Ekidehen> >> Twitter/Identi.ca: kidehen >> >> >> >> >> >> >> >> >> >> >> >> http://www.bbc.co.uk >> This e-mail (and any attachments) is confidential and may contain personal >> views which are not the views of the BBC unless specifically stated. >> If you have received it in error, please delete it from your system. >> Do not use, copy or disclose the information in any way nor act in reliance >> on it and notify the sender immediately. >> Please note that the BBC monitors e-mails sent or received. >> Further communication will signify your consent to this. > > > http://www.bbc.co.uk/ This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this.
Received on Thursday, 20 October 2011 13:38:24 UTC