Making CRS RESTful

In the last post I discussed the CRS or Consistent Reference Service, in some places called the Coreference Resolution Service. I this post I will discuss how to make it RESTful and what are the advantages of making it RESTful:
-Mapping the service offers a uniform interface to it.
-It facilitates exchanging information amongst different CRSs.
-Defining a protocol, for example: if CRSs exist that have the same canonical URI, they can negotiate to merge URIs and eliminate one of them.

I applied the mapping method, that defines resources and provides an interface

URI	Method	Description
/CRSBundle	GET	Gets the class {ontology}
	PUT	N/A
	POST	Creates a new bundle and assigns it a URI
	DELETE	N/A
/CRSBundle/{BundleID}	GET	Gets the bundle description
	PUT	Adds the URI to the bundle
	POST	N/A
	DELETE	Deletes the bundle
/CRSBundle/{BundleID}/ hasCanonical/	GET	Gets the canonical URI
	PUT	Adds or replaces the canonical URI
	POST	N/A
	DELETE	N/A
/CRSBundle/{BundleID}/ hasCanonical/{URI}	GET	Gets the URI
	PUT	N/A
	POST	N/A
	DELETE	Removes the canonical URI
/CRSBundle/{BundleID}/ hasEquivalent/	GET	Gets all equivalents
	PUT	Adds a URI to the bundle
	POST	N/A
	DELETE	Deletes all URI equivalents
/CRSBundle/{BundleID}/ hasEquivalent/{URI}	GET	Gets an equivalent URI
	PUT	N/A
	POST	N/A
	DELETE	Deletes the URI from the bundle
/{Any URI}/CRSBundle/	GET	Gets the bundles that this URI is related to
	PUT	N/A
	POST	Creates an new bundle
	DELETE	Deletes this URI from the bundles
/{Any URI}/CRSBundle/{BundleID}	GET	Gets the bundle
	PUT	N/A
	POST	N/A
	DELETE	Deletes this URI from the bundle
/CRSBundle/All	GET	Gets all the bundles on this service
	PUT	N/A
	POST	N/A
	DELETE	Deletes all the bundles

Discussing the mapping with my supervisor Dr. David Millard, he was interested in the semantics of the resulting URIs.

1-/CRSBundle/{BundleID}
{BundleID} is a place holder for a bundle identifier. So it is a resource, it should exist on the server as a resource. There is no need for the /CRSBundle/ before it.

2-{BundleID}/hasEquivalent/{URI}

This gives a URI to an instance of a relationship; it introduces the possibility of making statements about the relationship. Reification?

Some questions arise here:

1-What is the potential of having Reification, from what I know it improves expressiveness, but breaks the logic.

2-How are the URIs constructed with respect to the type of relationship or property. Does it matter whether they are inverse, transitive, symmetric …?

We are starting to dig deeper, but are we going to find something?

RKBExplorer and CRS Consistent Reference Service

I will describe the CRS, and then in the next post I’ll describe how we can apply the previous Semantic RESTful approach.

The (CRS) Consistent Reference Service, It is part of the RKBExplorer.

An example of the service is here http://dblp.rkbexplorer.com/crs/

CRS provides a method to manage multiple identities on the Semantic Web. The method recognizes the distributed and diverse nature of the Web.

CRS aims to connect these identities to each other, in such a way that it conveys that they relate to the same “non-informational“ resource, yet preserves the distinctiveness of each identity. The difference might mean a different role, or a different context.

It introduces the concept of bundles. Each bundle contains equivalent URIs for it, one of these URIs is chosen to be the canonical URI. The CRS bundle has a URI.

A URI might be in several bundles.

To illustrate the idea