Daniel@0: # P2R
Daniel@0: 
Daniel@0: A set of modules allowing you to export
Daniel@0: prolog predicates as RDF just by declaring
Daniel@0: mappings, and access them through a SPARQL 
Daniel@0: end-point.
Daniel@0: 
Daniel@0: Yves Raimond (c) 2007
Daniel@0: Centre for Digital Music, Queen Mary, 
Daniel@0: University of London
Daniel@0: 
Daniel@0: Samer Abdallah (c) 2010, 2014
Daniel@0: Department of Computer Science, UCL
Daniel@0: 
Daniel@0: ## Installation & running
Daniel@0: 
Daniel@0:  1. Get ClioPatria from here:
Daniel@0:  http://cliopatria.swi-prolog.org/home
Daniel@0:  and set it up as per instructions.
Daniel@0: 
Daniel@0:  2. Copy or link this p2r directory into the cpacks directory of
Daniel@0:  your working ClioPatria server.
Daniel@0: 
Daniel@0:  3. Register the cpack by doing  (at the Prolog prompt)
Daniel@0: 
Daniel@0: 		?- cpack_configure(p2r).
Daniel@0: 
Daniel@0:  4. In your code, do
Daniel@0: 
Daniel@0: 		:- use_module(entailment(p2r)).
Daniel@0: 
Daniel@0:     Register any prefixes you need with rdf_register_prefix/2, declare any
Daniel@0:     macros with uripattern:def(_,_), and write your mapping rules.
Daniel@0: 
Daniel@0:  5. Use the triples:
Daniel@0: 
Daniel@0:     a) Select p2r\_entailment on ClioPatria's SPARQL/SeRQL page...
Daniel@0: 
Daniel@0:     b) ...or call p2r\_entailment:rdf/3 directly (not recommended)
Daniel@0: 
Daniel@0:     c) ...or dump all the p2r\_entailment:rdf/3 triples into the main rdf database, using, eg
Daniel@0: 
Daniel@0: 			forall(p2r_entailment:rdf(A,B,C), rdf_assert(A,B,C,p2r)).
Daniel@0: 
Daniel@0: 	  Asserting the triples into a named graph (p2r) makes it easy
Daniel@0: 	  to delete them all and re-import when things change.
Daniel@0: 
Daniel@0: 
Daniel@0: ## Pattern language
Daniel@0: 
Daniel@0: Resources URIs and literals are expressed using a pattern language.
Daniel@0: See the README in the lib directory.
Daniel@0: 
Daniel@0: ## Example mappings
Daniel@0: 
Daniel@0: Suppose you have a predicate widget/3 which holds a database of
Daniel@0: widget identifiers, names, and weights, and another predicate 
Daniel@0: connectable/2 which describes which widgets can be connected
Daniel@0: to each other. Suppose also that the widgets are kept in a cabinet
Daniel@0: with pidgeon holes arranged in a matrix, and that the location of
Daniel@0: each widget is given by the predicate widget\_location/3.
Daniel@0: We could expose this as RDF using the following mappings:
Daniel@0: 
Daniel@0: 	:- rdf_register_prefix(eg,'http://www.example.org/').
Daniel@0: 	uripattern:def(loc(X,Y),num(X)/num(Y)).
Daniel@0: 
Daniel@0: 	rdf(eg:widgets/enc(ID), rdf:type, eg:schema/'Widget') <== widget(ID,_,_).
Daniel@0: 
Daniel@0: 	widget(ID,Name,Weight) ==>
Daniel@0: 		rdf(eg:widget/enc(ID), rdf:label, literal(Name)),
Daniel@0: 		rdf(eg:widget/enc(ID), eg:weight, literal(type(xsd:double,Weight)).
Daniel@0: 
Daniel@0: 	rdf(eg:widget/enc(ID1), eg:connectsTo, eg:widget/enc(ID2) <= connectable(ID1,ID2).
Daniel@0: 
Daniel@0: 	rdf(eg:widget/enc(ID), eg:location, eg:storage/loc(X,Y)) <= 
Daniel@0: 		widget_location(ID,X,Y).
Daniel@0: 
Daniel@0: Note that URI patterns MUST be written into the rdf/3 terms in the head
Daniel@0: of the rule (ie, the consequent part of the implication, rather than the
Daniel@0: antecedent, no matter which way round the rule is written, using <== or ==>).
Daniel@0: Otherwise, it is your responsibilty to construct or analyse any URIs. Of course,
Daniel@0: you can use the uripattern module to help you do this.