W3C home > Mailing lists > Public > semantic-web@w3.org > April 2010

Re: backronym proposal: Universal Resource Linker

From: Kingsley Idehen <kidehen@openlinksw.com>
Date: Sun, 18 Apr 2010 15:51:48 -0400
Message-ID: <4BCB62D4.2050402@openlinksw.com>
To: Dan Brickley <danbri@danbri.org>
CC: Semantic Web <semantic-web@w3.org>, public-lod <public-lod@w3.org>
Dan Brickley wrote:
> On Sun, Apr 18, 2010 at 7:40 PM, Ian Davis <me@iandavis.com> wrote:
>> When talking to people who aren't semweb engineers then i use
>> URL/URI/link interchangeably. I don't think it matters because the 1%
>> that care will look it all up and get the distinction and the rest
>> will just get on and use RDF as shown.
> Yeah, I find myself slipping between the two in the same sentence
> sometimes, even written or spoken.
> I don't think it really super matters which we use, but the confusion
> is costly and pointless.


> At the Augmented Reality Dev Camp here in Amsterdam yesterday, one of
> the comments was
> http://twitter.com/garciacity/status/12339906312
>     "So what is an URI? mentioned by steven pemberton and hans
> overbeek #ardevcamp "
> This is perfectly reasonable question from an educated and technical
> audience member, and a perfectly avoidable one. I mean no disrespect
> to either of the fine speakers, or the audience member; the mess is
> not of their making. RDFa and Linked Data were presented to a mixed
> audience, some coders, some artists, game designers, augmented
> reality, mapping folk etc... a real big mix.; and I think it went over
> well, but this silly issue of URI/URL is a bug worth fixing. We should
> be able to say "URL" unapologetically, correctly and without fear of
> contradiction. It's a fine acronym; it just has the wrong expansion.
> Easily fixed, since most people (as you say) won't even bother to look
> it up.

> My suggestion is that we flip things upside down. Too often "URL"
> comes across a being a kind of double-taboo (it's the old, incorrect
> name .... and it's (to URN-advocates) the crappy, lower quality form
> of linking, prone to breakage, 404 etc). People who use "URL" often do
> it in a sort of self-deprecating way; they know they should probably
> say "URI" or perhaps "IRI"; or maybe they really mean "URI Reference"
> or is that "IRI Reference" to be really inclusive and modern? [And are
> they called URI schemes now, or IRI schemes? I truly have no idea.]

In the Linked Data realm we have:

1. Descriptor Documents that at Addresses (URLs)
2. Descriptor Document Referents (or Subjects) that are "Unambiguously 
Named" by the "Describer" using "Generic HTTP scheme URIs" .

> So let's pull URL out from the bottom of the pile, reinstate it at the
> top, and rework the acronym to remove the most troublesome part
> "Locator". 
I don't think "Locator" is a problem while we have the acronym "URL". 
When you click on a LINK and you end up with something in your Browser 
(for instance) you've used the URL to "Locate" a Document (in actuality 
the Representation of a what is commonly perceived to be a "Document").
> By flipping that to something link-centric, we re-emphasise
> the core value of the Web, and turn the conversation away from
> pointless ratholes like "names/IDs vs addresses/locations" to
> something potentially *much* more productive: different types of
> URL-based linking.

By saying that we have a well established and uniform data model for 
describing things (EAV), we can articulate that using this model, with 
Entity Names, Attribute Names, and Values, we end up with a Structured 
Description of any item/unit of observation. Then, we can also 
articulate that how we represent the EAV model is up to the preferences 
of the "Describer".

RDF and its virtues ultimately comes into play when Description Fidelity 
issues arise (which is inevitable).

OWL and its virtues ultimately come into play (ironically) when Data 
Quality, Descriptor Graph Navigability, and the actual Business of 
Linked Data come into play :-)
>  * the whole mess around 'UR*' makes it hard for even technically
> aware observers to talk clearly

Yes, so so accurate, and this is very irksome!!

>  * we don't have an actively used "top term" in the tech scene for all
> those identifying strings (URIs, URI Refs, IRIs, IRI Refs)
>  * the deprecated nature of 'URL' means we don't reward people for
> using it; we make them feel dumber instead of smarter. We say "URL?
> yeah kinda, you probably really ought to say URI but don't worry, you
> nearly got it" instead of "Yeah, URLs - universal resource linkers -
> it's all about linking; if you understand URLs you understand the core
> idea behind the Web" (and the Web of data, ... and the Web of things,
> ...)

This is how the whole thing ends up being more akin to "secret society" 
membership rather than actual science.

> There was a fuss a while back when the HTML5 spec was using "URL"
> instead of "URI"; however that was without the proposed
> reconceptualisation here. I'd hate to stir up a fuss, but I think we
> have a lot of interesting ingredients:

Well guess what? The RDFa vs Microformats imbroglio dies when you look 
at both as different ways of using HTML to construction EAV model based 
Descriptor Documents.

EAV is ultimately about peace at many levels :-)

> * the term 'URL' isn't being used in a technical sense currently - I
> consider it available for careful redeployment
> * many of us are already using it informally as an overarching
> umbrella term ('cos we know it works)
> * it has massive market-presence and is understood pretty well by the public
> * we really badly need an umbrella term that hides the URI vs IRI vs
> *RI-Ref distinction from normal humans
> * 'universal resource linker' is loose and evocative enough to do the
> job, and makes people feel smarter not dumber...
> cheers,
> Dan



Kingsley Idehen	      
President & CEO 
OpenLink Software     
Web: http://www.openlinksw.com
Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca: kidehen 
Received on Sunday, 18 April 2010 19:52:17 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 08:45:17 UTC