CRM API

Posted by Gerald de Jong on 31/5/2014 

I'm wondering if the SIG has some kind of CRM API available so that software can easily retrieve the model and its component parts individually. What I'm thinking of is a REST interface which makes it easy to build CRM browser software in Javascript, exposing scope notes and any other materials (video fragments of Stephen Stead?). 

If people are eventually able to build mappings from their data models to the CRM using the X3ML Mapping Engine (https://github.com/delving/x3ml), maybe a link back to the collection registration system could be enabled. The local data model fields in the registration system could be associated with the CRM elements to which they are mapped, and relevant scope notes displayed. 

All for the increased visibility and ease of integration, to encourage dissemination, of course. 

We could also publish a kind of CRM "Widget" in Javascript which consumed such an API, and could be dropped on any web page. 
 

Posted by Simon Spero 1/6/2014

>On Sat, May 31, 2014 at 12:29 PM, Gerald de Jong wrote: 
>I'm wondering if the SIG has some kind of CRM API available so that software can easily retrieve the model and its component parts individually. What I'm thinking of is a REST interface which makes it easy to build CRM browser software in Javascript, exposing scope notes and any other materials (video fragments of Stephen Stead?).

The output of X3ML is generally RDF, right? 

If the data are exposed via a SPARQL endpoint, then that will provide a REST-ish API. 

GET /sparql/?query=<sparql query> HTTP/1.1 

Host: <hostname> 
Accept: application/sparql-results+json 

You can also use POST for longer queries (hence the "-ish") 

see: 

SPARQL 1.1 Protocol Recommendation: 
http://www.w3.org/TR/sparql11-protocol/ 

SPARQL 1.1 JSON Results Format: 
http://www.w3.org/TR/sparql11-results-json/ 

SPARQL 1.1 Query Language: 
http://www.w3.org/TR/sparql11-query/ 

Posted by Gerald de Jong 1/6/2014 

I think we could probably provide a more straightforward REST (rather than -ish) interface which does its work using SPARQL but hides the complexity from the app/widget developer. Maybe a handful of parametrized SPARQL queries behind the scenes would be enough. 
 

Posted by Barry Norton 2/6/2014 

Well, Linked Data is RESTful insofar as resources are resolvable (GETtable) and interlinked, cf.: 

$ curl -LH "Accept:text/html" http://collection.britishmuseum.org/id/object/EOC3130&nbsp;
$ curl -LH "Accept:text/turtle" http://collection.britishmuseum.org/id/object/EOC3130&nbsp;
$ curl -LH "Accept:application/json" http://collection.britishmuseum.org/id/object/EOC3130&nbsp;

Unfortunately the latter is not yet JSON-LD at the BM, which would be my preference if you want to use JSON alongside CRM descriptions. 

We mirror the structure and descriptions of (currently Erlangen-identified) CRM terms, allowing: 

$ curl -LH "Accept:application/json" http://collection.britishmuseum.org/resource/ecrm/E22_Man-Made_Object&n…;

{ 

"http://erlangen-crm.org/current/E22_Man-Made_Object" : { 

"http://www.w3.org/2000/01/rdf-schema#subClassOf" : [ { 

"value" : "http://erlangen-crm.org/current/E19_Physical_Object", 

"type" : "uri" 

}, { 

"value" : "http://erlangen-crm.org/current/E24_Physical_Man-Made_Thing", 

"type" : "uri" 

} ], 

"http://www.w3.org/1999/02/22-rdf-syntax-ns#type" : [ { 

"value" : "http://www.w3.org/2002/07/owl#Class", 

"type" : "uri" 

} ], 

"http://www.w3.org/2000/01/rdf-schema#comment" : [ { 

"value" : "Scope note:\nThis class comprises physical objects purposely created by human activity.\nNo assumptions are made as to the extent of modification required to justify regarding an object as man-made. For example, an inscribed piece of rock or a preserved butterfly are both regarded as instances of E22 Man-Made Object.\n\nExamples:\n- Mallard (the World's fastest steam engine)\n- the Portland Vase\n- the Coliseum", 

"type" : "literal" 

} ] 

} 

} 



I'd like to see content-negotiable, JSON-LD supporting individual terms of the CRM at the canonical URLs, and I'd be happy to help. 

Posted by Vladimir 10/6/2014

>Unfortunately the latter is not yet JSON-LD at the BM, which would be my preference

Agreed. 
We have an outstanding task to add JSON-LD output to OWLIM (Sesame actually). It's quite likely we'll do it within 6 months as part of the Multisensor project. 

Simon and Barry are right: use basic sem web principles: 

resource URLs with content negotiation, and SPARQL when you need it. 

Gerald> easily retrieve the model and its component parts individually 

Our ResearchSpace experience shows it's not worth making custom JS domain models on top of CRM (e.g. one for painting, another for archaeological find). 
Just use CRM. But how to display CRM data in the best possible is highly non-trivial, e.g. seehttps://confluence.ontotext.com/display/ResearchSpace/Data+Display+Discussion 
https://confluence.ontotext.com/display/ResearchSpace/BM+RForms+Mockup 

It's worth having specially defined Result Fields (key fields), e.g. see: 
https://confluence.ontotext.com/display/ResearchSpace/Search+Result+Fields 

Cheers! V 

PS: I never knew that http://collection.britishmuseum.org/id/object/EOC3130 "Hoa Hakananai'a" consists of thes:x11794 "Coral" in addition to stone and basalt. 
Learn something new every day