Comments on "Designing URI Sets for the UK Public Sector"

One of my action items from the F2F was to comment on the URI patterns
and functionality described in the "Designing URI Sets for the UK Public
Sector" document:

 

http://www.cabinetoffice.gov.uk/media/308995/public_sector_uri.pdf

 

Rather than starting with principles, most of which we agree on anyway,
maybe I should just compare and contrast URI examples and justify the
differences as needed.

 

URI Type

Their example

Suggested alternative

(Real world) Identifier

http://education.data.gov.uk/id/school/78

http://education.data.gov.uk/school/78

(Generic) Document

http://education.data.gov.uk/doc/school/78

http://education.data.gov.uk/school/78/

(Web Document) Representation

http://education.data.gov.uk/doc/school/78/doc.rdf

http://education.data.gov.uk/school/78/doc.rdf

Definition of the scheme concept

http://education.data.gov.ui/def/school

http://education.data.gov.ui/ontology/education/#School

List of scheme identifiers

http://education.data.gov.uk/doc/school

http://education.data.gov.uk/school/

Set

http://education.data.gov.ui/set/school

http://education.data.gov.uk/school

 

Because the resources aren't scattered over different top-level path
segments, hackability is inherently improved. 

 

Also note that their URI pattern recognition for "(Web Document)
Representation" depends on the trailing path segment starting with the
letters "doc.". This is a serious limitation, IMO, caused by their
willingness to stack concept/reference pairs in their URI. This
limitation could be avoided by coining a formulaic or opaque token for
the individual instead. (Roads and junctions have a nasty habit of
changing "names" over time, so maybe opaque tokens would be better in
these cases.)

 

Their stacked (Real world) Identifier:
http://education.data.gov.uk/id/road/M5/junction/24

Formulaic alternative: http://education.data.gov.uk/junction/M5-24 

 

There is another downside to carelessly stacking concept/reference pairs
in the URI. Doing it this way creates a tight-coupling between the
classes that could be problematic as the domain model is adapted to new
use cases. That thing you thought was an object property may eventually
prove to be a class with more complex cardinalities. HTTP can help by
changing the resource behavior to 300 (Multiple Choices), but why take
the risk?

 

There is some slight-of-hand in my "List of scheme identifiers"
alternative that I should explain. This is a class-level generic
resource that should be content-negotiable to a variety of media-types
like HTML (including mobile), RDF, JSON, RSS, Atom Feeds, etc. There is
also a need to support class-level operation APIs like SRU, OAI-PMH,
etc. These need their own URIs, just like the instance-level "(Web
Document) representations" do in the table above. This can be resolved
by reserving a path segment tokens (justified in modeling terms as a
"class" in the meta-model).

 

http://education.data.gov.uk/class/school/about.html 

http://education.data.gov.uk/class/school/mobile.html 

http://education.data.gov.uk/class/school/list.html 

http://education.data.gov.uk/class/school/list.rdf 

http://education.data.gov.uk/class/school/feed.atom 

http://education.data.gov.uk/class/school/oai-pmh 

etc.

 

Last, CRUD operations fit easily into this model. For example, if
someone wants to POST a new school, they should be able to treat the
next-to-last URI as an AtomPub "collection URI"
<http://tools.ietf.org/html/rfc5023#section-5.3>:

 

http://education.data.gov.uk/school/

 

The (Generic) Document can be used as the AtomPub "Member" URI for
updating <http://tools.ietf.org/html/rfc5023#section-5.4.2> and deleting
<http://tools.ietf.org/html/rfc5023#section-5.4.3>: 

 

http://education.data.gov.uk/school/78/  

 

 (I have some quibbles about education.data.gov.uk as a domain name, but
that can wait. I also think it would be good to formalize the "URI type"
names. I think they could be better.)

 

Jeff

 

---

Jeffrey A. Young
Software Architect
OCLC Research, Mail Code 410
OCLC Online Computer Library Center, Inc.
6565 Kilgour Place
Dublin, OH 43017-3395
www.oclc.org <http://www.oclc.org> 

Voice: 614-764-4342
Voice: 800-848-5878, ext. 4342
Fax: 614-718-7477
Email: jyoung@oclc.org <mailto:jyoung@oclc.org>