Saturday 9 May 2009

Cool URIs

When I design the use cases, I begin by listing the resources’ URIs for example in the Pizza Delivery use case:

URI

../Order

../Order/{Order_ID}

../Order/{Order_ID}/isOrderedBy

../Order/{Order_ID}/hasPizzas

../Order/{Order_ID}/hasStatus

../Order/{Order_ID}/hasTime


../Customer

../Customer/{Customer_ID}/

../Customer/{Customer_ID}/hasName

../Customer/{Customer_ID}/hasPhoneNo

../Customer/{Customer_ID}/has Address


../Pizza

../Pizza/{Pizza_ID}/



Months ago, I had a discussion with my supervisor about the structure of the URI, should it be like this:

http://www.example.com/Order/{Order_ID}

Or like this:

http://www.example.com /{Order_ID} without the /Order/ Prefix.

We decided that the 2nd method was better, I believe the reason was that we wanted could have URIs in the following form Subject/Predicate/Object . But I think the problem was that we thought of URIs as an ID which is not the case. We initially thought of it the URIs way:

http://www.example.com/{OrderID}/isOrderedby/{CustomerID}

But this isn’t quite correct because we are not using the whole URI for the Customer, to assert that an Order was ordered by him we need the customers’ URI not only the ID. So it should be like this:

http://www.example.com/{OrderID}/isOrderedby/http://www.example.com/{CustomerID}

The reason I am going back to that is when I started implementing, I discovered that I need something in the URI to indicate what type of resource we are dealing with is it a Pizza, Customer or an Order? This indicator could be either something like /Order/{OrderID} or having a prefix to the ID like having all order ids starting with the characters “OID”.
Having a classifying URI is a requirement if I wanted to use existing REST frameworks. But even if I wanted to implement everything from scratch, how would my framework know where to forward an incoming request? For example if customer wanted to check the status of an Order with ID 12345 he would submit GET to

http://www.example.com/12345/

How would my framework know that this is an Order, not a Customer or a Pizza? Having an automatically generated stub for each dynamically created resource is not an option, so there must be a way to indicate which kind of resource this is. Maybe having an indicator in the URI is not bad.

I wanted to know the standard way to assign URIs, so I checked the W3C. In the document about Cool URIs for the Semantic Web, they used URIs in the following form

http://www.example.com/people/alice

So to see if this is applied, I checked RKBexplorer, to see how they have been doing things. I checked for equivalent URIs -using their CRS- for Ian Millard a person that I’m sure is in the system. And these came up

1. http://citeseer.rkbexplorer.com/id/resource-CSP211403-1e189c7f65e747386b40ae1031a26e27
2. http://data.semanticweb.org/person/ian-millard
3. http://dblp.rkbexplorer.com/id/people-5c3b0c986bef5fa4e181c5830d56326b-9118ee1bfc54e3cb07408669fc2f7c48
4. http://eprints.rkbexplorer.com/id/ecs-soton/person-04860
5. http://id.ecs.soton.ac.uk/person/4860
6. http://southampton.rkbexplorer.com/id/person-04860
7. http://wiki.rkbexplorer.com/id/ian_millard

I omitted the duplicates that had the same domain name because they used the same naming scheme. By checking the URIs we can see that it is a standard procedure to have an indicator in the URI to show what kind of resource it is.
There is something to watch out for however, if I want to adhere to Cool URIs for the Semantic Web, and that is the distinction between URIs for informational resources and non-informational resources. For more on that check
http://www.w3.org/TR/2007/WD-cooluris-20071217/

No comments:

Post a Comment