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

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...

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
address = specific representation url (exposed in content location headers and rel="alternate" < forgot that bit earlier)

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 :-)

I could of course be wrong :-/

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>  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
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.