By utilizing the built-in Lucene full-text search index in OWLIM (indexing instance string literals and labels), the Stuff API combines full text search terms with Class types on Stuff entities. We can then provide a flexible search API that provides RDF or OpenSearch Suggestions JSON responses via content-negotiation. Using the OpenSearch Suggestions format lets us quickly build out rich and extremely functional type-ahead lookups into the CMS and Semantic annotation UIs that can be filtered on any Stuff subclass - "Find me People instances containing the word 'Rooney'".

What about rNews and Schema.org ? A semantic publishing architecture based on full-blown RDF and the SNaP ontologies is by no means mutually exclusive with rNews, schema.org micro data or any other schemas for that matter (in fact the SNaP ontologies already inherit from many common public domain ontologies). In this case rNews metadata can be added to documents post publication (downstream) either via mapping to SNaP or via transformation. We have identifed join points between SNaP and rNews to ensure this can happen.

This technology allows the Press Association to accurately semantically annotate news assets (stories and images) with linked data concepts (locations, people, organisations etc), so PA can provide APIs for their consumers based on rich semantic and geospatial aggregations. These semantic APIs let us provide answers to consumer questions such as "Give me all the articles about Shale Gas Fracking within 30km of Blackpool", or "Give me all the articles about The Arab Spring, that mention Barrack Obama and Bashar Assad". Through relationships in the linked data concepts, we can provide more complex answers such as "Give me all the images of living, newsworthy people, born in Liverpool who are involved in politics".

The RDF/ Ontology model is pervasive throughout the technical stack - with traditional relational database, the model is typical contained at the bottom of the stack, here though the ontology design is holistically fundamental to the overall architected solution. Thus the design paradigm has shifted from concealment of a backend (relational) model entirely, to complete exposure of the model all the way through the technical stack, and all the way to your consumers.

One of they key requirements for the semantic annotation service was that we wanted it to be client driven and thus self learning. We did not want it to be fundamentally rules-based which would require indefinite ongoing maintenance of knowledge rules to ensure the F1 scores would remain high (> 90%) within the ever-changing context of news. To meet this requirement, outside of simple JAPE grammars to match dictionary terms in the text, the key entity disambiguation and text analysis processes in the semantic annotation pipeline are based around (1) ontological proximity and (2) statistical models

Ontological proximity disambiguates entities in the text by looking at relationships between entities that have been matched in the gazetteers. Entities that have a close ontological relationship are deemed to be more likely to be correct. For example, if analysis of a given document identifies both David Cameron (Prime minister) and David Cameron (football player/ manager) and also Samantha Cameron, then David Cameron (Prime minister) will be disambiguated due to the close ontological relationship with his wife. This is a powerful tool, and is where the value of the pns:notablyAssociatedProperty becomes apparent. By building (binding) the software that performs disambiguation by ontological proximity only to this relationship we gain powerful disambiguation, while retaining the ability to extend our ontology (and join to other cohesive public domain ontologies) without breaking the semantic annotation code.