- Aren’t URNs much more elegant than those brittle HTTP URIs?
- Why is everyone yapping about 303 redirects?
- Hash vs. slash?
- What’s the deal with content negotiation and the Semantic Web?
- Shouldn’t we use blank nodes anyway?
There’s a lot of confusion around URIs on the Semantic Web. You have to do quite a bit of reading and trial-and-error to arrive at effective solutions. Leo, Max and I wrote Cool URIs for the Semantic Web (Leo’s announcement) to take some of the pain out of this process.
A couple of random companion posts from my archives:
- Debugging Semantic Web sites with cURL
- Content negotiation with hash URIs (long)
- Fixing ambiguous concept URIs
- Game theory, convention, and coordination
And, always worth a link:
Hi,
Quite interesting about this big problems around the designation of things with the URL. One of the biggest problem yet to be add to these questions is the disambiguation between words used as “proper noun” or as “common nouns”, that is the difference between “(Michael) Rich” and “(the) rich”.
I have on my own started to articulate my view on these problems.
On the representation space selection, one possible solution is to put back the “.” operator in the url syntax for the english text representation “as”.
With this, from an url x you can select for example :
GET x.text => get x “as text” that is one of the “names” of something.
GET x.image => get x “as image” that is one the “photo” FEATURING x.
For proper vs. common, my idea is to prefix a word with the “+” operator for a proper noun, and with the “#” operator for a common noun.
Thus, from a Root / :
/+rich will represent the guy that is called Rich (if many, the returned is a 300 Choice)
/#rich will represent “a rich” and the returned will be a prototype of a rich thing (that is the owl:class element).
/+rich/ will represent “the Richs” that is all the things that are called “Rich”
/+#rich/ will represent “the rich” that is all things that are rich.
i would just ignore this, but it says ‘take the pain’ out of cool URIs, and i couldn’t disagree more. it adds pain – first, youve ignored the most common and useful way to use them – autogenerate them from the dc:title-esque field, and use the same URI regardless of the data returned (via data-embedding, or a commonly accepted URL extension like .xml, .rss, rdf, etc), and append to a date . wordpress, drupal, and the w3 website all do this by default.
second, you introduce confusion and complexity. whats this 303 stuff? using 2 URIs for the same person, /person/alice and /data/alice? or wait, /people/alice, which doesnt make sense, since alice isnt a people, now theres an extra URI in the mess and one of them is leaking the implementation (who wants /data/ in all their URIs?) and the tools now have to keep track of which is which and handle provenance and equality – |don’t be ambiguous| you said it! . if youre using content negotiation, or even a query string or URI format-appendage, you don’t need to do any redirect and involve additional URIs..
the third annoyance, is that you are suggesting using hash uris. imagine what happens when someone requests /data when your app gets even minorly big.. or are you also suggesting changing how every browser on earth works to send the hash and the stuff after it to the server in a GET request?
i meant 2 extra URIs..
no thanks on your solution. i always get annoyed when browsing around the rdf web that theres often an extra click involved since people used the above tricks to add some indirection for the sake of some kind of semantic hairsplitting like “alices homepage must not be alice, lets make another URI up for the actual alice then require people to tweak out their apaches. oh and while we’re at it lets think up a different URI for all the formats and not use the conventions that already exist..”
@Julien, I’d say that the URI itself (the string of characters) is the wrong place to do the kind of disambiguation you describe. In web architecture, there’s the principle of URI opacity, which says you should not use the URI string itself to make guesses about what the URI identifies. You have to actually look at what comes back when you resolve the URI. That’s where the disambiguation should happen.
@C, I will assume that you come from a strong web and REST background. Then maybe you are quite right to ignore all of this—it doesn’t solve any problem that occurs in the traditional Web or REST. That’s not what we are talking about, and we didn’t bother to include what any web developer should know anyway.
We deal with problems that occur when you start making RDF statements about URIs that have been allocated by other people, and then want still other people to be able to understand the statements. In such an environment, the “no semantic hairsplitting†approach quickly hits a brick wall.
@C:
You didn’t actually bother to read more than the headlines, did you?
No.
No one is yapping about this. No one really cares about 30x redirects.
Who cares?
Who cares? Conneg is generally a waste of time, as evidenced by the amazing lack of it’s use in … well … reality.
No. You should do useful stuff.
You know, stuff with utility besides semantic web wankery.Hi Richard,
I think the URI Opacity is actually THE problem of REST today and I have seen people on Restwiki trying to challenge this hypothesis.
The URL you show are not meaningless at all as you embed the Proper Noun of someone in it, you interprete the domain name as an authority, etc., etc.
When you say that it is up to what you got to tell the meaning, this just move the step further as if the Response is an URL, the computer will need something to understand it.
REST says that everyting must be an URL, I think that every URL might refer to a thing.
As REST makes the transition from the unusable term “Resource” to the meaningful “Noun”, I think we should develop mecanisms to translate natural languages Noun in URL i.e a way to say “Richard’s last blog article” in a URL in order to be able to PUT at it, GET at it and POST it to categories.
If you use “opacity” at the url level, that is machine code, and you will need another programming system at the user level adding at least one layer of redundancy. With proper rules to map main natural language constructs on URL operators (+, -, ., :, @, /, #), URL+HTTP could move the “L” from “Locator” to “Language” and propose an Uniform Language to manipulate symbolic expressions at web scale.
Extracting “proper”, “common”, “plural”, “adpositional” or “verbal” constructs from the words we use to build our URLs will restrict the degees of freedom that hackers use when naming their resources, making it easy for HUMAN to bookmark something BUT near impossible for COMPUTER to use it.
Pingback: my weblog » Best practices des URIs dans le SW.