Skip to content

Data Pages

I don’t like the linked data API, but not because it’s a bad design, but because you end up with scary confusing HTML webpages which people end up on by accident and have no cue as to what to do next.

It’s my strong opinion that when producing a system that will mass produce HTML pages with raw data dumps in, you will alienate people who will arrive there by mistake from search engines.

Currently we don’t have a viewer for individual payments, so you can see how our data site defaults to show a raw data object:

“This page shows raw data about this resource. We have not yet had the time to build a pretty viewer for this type of item. Don’t worry if it seems a bit arcane — you are looking under the hood of our service into the data inside! You can download this data in the following formats: rdf, ttl, json, xml.”

I think just telling people that this page isn’t the droids they are looking for will help them move along without distress, and should be considered good practice.

ps. The Linked Data API does one thing I have a real issue with, it can only be configured to follow “forward” relationships from a resource. So you can show a person and their name & phonebumber and follow the link to their address and follow the link from their to their city. What you can’t do is follow an inverse link like “foaf:member” which links from a group to a person, not a person to a group. It could easily be fixed by a tiny tweak where you define an inverse relationship for the property and give that a label, and the system will look for both it and its reverse. This is much cleaner (and semantic) than having people create inverse triples for every membership in their database to appease the whims of the linked data API. I know I should join the community, and argue for it there, but I don’t have time. Sorry.

Posted in Best Practice, RDF.

3 Responses

Stay in touch with the conversation, subscribe to the RSS feed for comments on this post.

  1. John Goodwin says

    “you define an inverse relationship for the property and give that a label, and the system will look for both it and its reverse” – that would be nice. Ditto for transitive relationships and also super properties…and then potentially more complex OWL axioms.

  2. Jeni Tennison says


    I’d strongly encourage you to provide tailored web pages for the HTML views of each endpoint rather than use the generic example.

    The HTML view that I created for the linked data API is a demonstration of what you can do. It suits what we needed to create for (with very little time and a huge variety of data) and is therefore fairly generic.

    What I suggest is that you replace the XSLT that creates that HTML to give a view that is less scary and more tailored to the particular data that you want to present. You can create a different view for each endpoint, tailored to emphasise particular fields and hide others: whatever you want. The XML isn’t hard to process (it’s not RDF/XML).


Some HTML is OK

or, reply to this post via trackback.