Predicate Based Services is a great service on a number of different levels. It provides a much needed piece of Semantic Web infrastructure and it achieves that through a simple clean interface and API. You don’t even need to know anything about RDF to get value from the service. In short it’s one of those nice web services that do one thing and do it really well.

I use the service as a frequent example in my talks and training sessions on Linked Data. For example, while it’s useful to review techniques for linking together datasets, in practice you can achieve a lot by simply doing a series of look-ups against I’ve had some happy experiences of discovering connections between datasets without having to do any manual linking.

More than a few times recently I’ve been thinking that it would be useful to repeat what Hugh Glaser and Ian Millard achieved with, but for a number of other common RDF predicates.

In my opinion there are a small number of general predicates that will act as the backbone for the web of data. At the head of the predicate long tail we’ll find properties like: owl:sameAs, but also useful properties like dc:subject, foaf:knows and foaf:primaryTopic.

The topic based predicates (dc:subject, foaf:primaryTopic, foaf:topic, et al) are particularly useful for discovering documents and material that relate to a specific resource. An index of these would be extremely useful for inter-linking between content from different news and media organisations for example. I’d envisage that “” might index a range of different topic related predicates and expose some useful discovery tools, relations and equivalencies. Dan Brickley has a nice diagram that shows how these different predicates inter-relate.

“topicOf” is currently top of my list of these predicate based services. But the same approach would work in other contexts. For example a service that indexed foaf:knows would be useful for social networking applications. But I think that this area is already well-served by existing services already. But what about:

  • “” — find reviews about a specific resource. I believe Tom Heath has thought about doing something like with for Revyu
  • “” — find pictures of a specific resource (foaf:depiction), e.g. person, place or thing (and reliably, not like the Flickr Wrapper)
  • “”> — find documents, photos, or other resources that were made by a particular person (dc:creator, foaf:maker)

I can think of all sorts of useful purposes for these services. I also think that they could offer additional ways of engaging with the broader developer community and getting them to buy into the Linked Data vision.

Anyone want to have a crack at implementing some of these?

7 thoughts on “Predicate Based Services

  1. Thanks for the thought-provoking post, Leigh!

    My mind immediately turned to niche predicate- based services for publishing, media production and broadcast analytics (i.e. television ratings) domains. One facet of this would be a range of specializations on “madeBy,” such as “shotBy,” “editedBy,” etc.

    I could also specialized services for certain scientific niches, esp. scientific workflow, genomics and pharma.

    An interesting evolution of these services would be the management of user “profiles” that would contextualize the lookups for users, in essence filtering the range of the results. One example that I think has actually been used before is restricting the range to certain CC licences.

    Interesting idea!

  2. Ed,

    Yes I think thats one useful way of looking at it. And I agree that Google is already essentially offering a service around vanilla hyperlinks.

    I think that one of the interesting things about this approach is that its fairly unique to the Linked Data world. There are lots of existing web services and applications that specialise in aggregating data about specific types of things (Photos, Blog Posts, Books) but very few that focus on relations. Thats mainly because without RDF & Linked Data those relations are not explicit.

    Google does a good job at sifting out potentially relevant links and relations, but we can do potentially do better. We may not be as comprehensive in all cases, but I think there’s a reasonable trade-off there for some applications.

    Subj3ct seems to me more about trying to organize data around common URIs. I guess its similar in intent to, but doesn’t quite fit my notion of the “topicOf” service.

  3. Thanks for the nice words Leigh.

    Good stuff.

    Sorry I haven’t implemented yet 🙂

    I think one of the really good variants of this would be narrow and broader, in the widest possible sense. So I am narrower than my family, but my nose is narrower than me. snafu is broader than fubar, etc..Clearly geographic stuff is relevant.

    If you don’t get hung up on types, and just treat as a discovery mechanism, then it would give lots of leverage.

  4. Do you know the SeeAlso linkserver API? Given an identifier (as URI or as something like skos:prefLabel which can be mapped to its URI) you get a list of related resource. If you query for an identifier of resource $S you can get a list of ($O,$L) tuples with (in Turtle syntax)

    $S $P $O . $O rdfs:label $L .

    The predicate $P (let it be owl:sameAs or what you need) depends on the particular SeeAlso service but you can also put it in the “description” field of a SeeAlso response.

    The practical use case for SeeAlso is to provide links related to a given resource to show them in a library catalog. Instead of and similar services which are made for nerds that love RDF-triples, a SeeAlso service is made for normal web users first – they get a list of labeled (!) links and computers second.

    You can get a Perl implementation at CPAN and a PHP preview implementation included in phpBeacon (BEACON is a SeeAlso dump format that I work on at the moment). But you should also be able to hack the SeeAlso API in an hour or two its really simple.

    A citedBy-service based on ISBN numbers in the German Wikipedia is available at – it already supports RDF.

Comments are closed.