Dynamic grammar and nested REST webservices

Poster Content
nk4um User
Posts: 168
November 8, 2013 09:47


The difficulty I see about the dynamic grammar is that the meaning of "A/B", in the resource identifier, can have three different possible meanings :

  1. "B is an instance of concept A";
  2. "B is a concept which is a part of instance A";
  3. "A is a concept, B is a concept, and B is a kind of A".

Since the URI can have an arbitrary length, it's quite hard to think of a grammar that would recognize a valid URI.

And when we do recognize a valid URI and "A/B" is at the end of the resource identifier, we still have to return different representations :

  • case 1 : return the representation of instance B;
  • case 2 and 3 : return all concepts refining concept B, or (and?) all instances of concept B (that is, return a "folder" view).

Is this possible to write a recursive regex? Or is that not necessary?

Like · Post Reply
nk4um User
Posts: 168
October 25, 2013 13:48

Hi Peter,

Before answering your questions, I think I should clarify where this idea came from. As you probably remember, I'm involved in a project with 4 universities and 3 high schools. I had to make several months of work to "tune" the initial goals of the project with the context.

During this phase I extensively used mind maps and concept maps (the difference is that a mind map is a tree, and a concept map is a graph). Both are convenient tools to graphically organize informations and make them evolve on the long term.

So I iteratively built a concept map whose goal was to "state the obvious" (for example, that "university -:isA-> organisation" or that "teacher -:worksFor-> university"). It was important to show which concepts and which relationships were of interest for my project.

Concept map of my project

So far, so good. I had built a concept map representing an ontology, and I wanted to build REST webservices in the form of clean URIs.

How can we construct a tree (i.e. clean URIs) from a graph?

The most generic answer is the one chosen by Neo4J :

  • /nodes
  • /relationships

but it doesn't say much about the domain.

So I looked at the way I had organized my concept map and realized that "isA" relationships ("est" in french) are a very common way to classify concepts in a hierarchical way. Then I thought about the way I could specify sub-concepts and "isPartOf" ("estUnePartieDe") relationships could be used for that matter, allowing to create cool URIs like :

/organisation/établissement/{Rennes 1}/service/{CIRM}

Note : the {} are here to show actual instances inside the collections.

If we can access the "/service/{CIRM}" from inside {Rennes 1}, that is because "service -:isPartOf-> établissement" (if we physically remove a university, then we would remove its services too, so it makes sense).

To sum up, using "isA" and "isPartOf" can be good to construct nested web-services. Relationships which are neither "isA", neither "isPartOf", could be dealt with using standard links inside the ressources (if the representation is XML, we could use XLinks).

To answer your questions (or try to), I think that, for such a tool, a possible input format could be OWL2, as it is a W3C specification and is exactly built for describing ontologies. There is a RDF syntax and a specific OWL namespaced syntax. The Protégé tool can help with the creation of a OWL2 ontology (though it's not an impressive tool by today's standards). Just for information, I've put on my website an example OWL file using XML and RDF syntaxes. I believe the XML syntax is easier to transform.

I hope this gives you some answers. Obviously this can be much improved, the main idea is that the NetKernel developer could build its REST endpoints without wondering too much about how to build them.



Like · Post Reply
nk4um Moderator
Posts: 901
October 25, 2013 10:40

Hi Grégoire,

Sorry for the asynchronous participation in this thread.

I think it is a good idea. From the point of view of actually implementing this, it is technically a pretty trivial thing to do - just a transform of a declarative specification to either an NK mapper config (or for advanced situations a dynamically generated space declaration).

The question I put back to you and the community is - what is the best format for the declarative REST description? In the past we've looked at JSR-311 - but this is a very nasty low-level way of working and we're certainly looking for a higher order approach (binding to objects is wrong in so many ways).

Alternatively I've thought we could take something like an apiary REST API specification and dynamically generate the resource interfaces from that?

Ideally we could use something that was standard (or as a minimum: widely adopted) - if there isn't such a thing then we need to discuss what the form of the description should be.

As I say - this is technically a no-brainer - we can implement this dozens of ways with essentially no code - the open question is what is the "best description" of the services you want?

Do you have something specific in mind? Can you provide a worked example that covers the minimum features? Do you have a preferred description?

Generally speaking I think this is a very good idea - as ever I'm torn between preserving the universal solution and smoothly providing a simple to use domain-specific tool. Hopefully we can strike a balance to provide a tool that implements a pattern on the universal foundations (I'm not staying on the fence - just trying to get a good engineering balance ;-)



Like · Post Reply
nk4um User
Posts: 168
October 25, 2013 09:40


I would really like to read what you think about the above idea. If that's not good, please tell me why, I'm looking for opinions, even negative ones would help.

Cheers, Grégoire

Like · Post Reply
nk4um User
Posts: 168
October 23, 2013 10:00

Hi Peter, hi Randy,

I believe that NetKernel should provide a tool to construct REST endpoints based on a description of the domain concepts (just like nCode is about the "Compose" step). I believe it would flatten the learning curve for newcomers, because writing a valid "module.xml" is a tedious task.

And because REST is about standardized operations (CRUD) on resources, this new tool would solve a very common use case : create a well thought-out, long-lived information back-end with a clean naming scheme and standardized interface.

Tom Geudens has written a CRUD server that could perhaps be used to build a prototype of this tool.

The general idea, on the long term, would be to provide programmers with a kind of AtomPub webservices constructor.

Cheers, Grégoire

Like · Post Reply
nk4um User
Posts: 13
October 22, 2013 19:12

Hi - We are thinking the same thoughts. I'm in the process of looking at various alternative "web" frameworks in order to understand the current thinking about a grammar to describe this layer. (e.g. TypeSafe's Play framework)

As Peter has mentioned - those are the two ways to go. However, it would be nice to have a language that was designed to describe this boundary which then generated one of these two alternatives.

If you are interested in discussing such a grammar / language, let me know and we can discuss.


Like · Post Reply
nk4um Moderator
Posts: 901
October 22, 2013 18:47Certainly. Dynamic Mapper or Dynamic Space. Your choice.

Hi Gregoire - the very short answer is, certainly you can most definitely create REST endpoints of this complexity driven from a resource (or resources).

There are two ways to do this.

  1. As you indicated, you can generate the mapper config as a resource - just point the mapper <config> to a dynamically generated resource that creates the endpoints from another resource.
  2. You can now use the space runtime - to dynamically generate an arbitrarily complex space. The space itself would be derived from complex resource (or resources).

I'll see if I can dig out a suitable example tomorrow and post it for you.


Like · Post Reply
nk4um User
Posts: 168
October 22, 2013 16:28Dynamic grammar and nested REST webservices


About one year ago, Tony wrote a blog post about dynamic grammars. The idea was to allow NetKernel to create REST endpoints based on some dynamic source. As quoted, "Peter Rodgers made the suggestion of just using the mapper overlay with a dynamic configuration resource". Great.

My idea would be to use an ontology containing a hierarchy of "isA" and "isPartOf" relationships to automatically create nested REST endpoints (with collections and informations ressources).

Let's imagine the following ontology :

 Road vehicle -:isA-> Vehicle
 Car -:isA-> Road vehicle
 Gearbox -:isPartOf-> Car
 myAlfa147 -:instanceOf-> Car
 myAlfa147Gearbox -:instanceOf -> Gearbox

The resulting REST endpoints could be :

   /road vehicle               // road vehicle isA vehicle
     /car                      // car isA road vehicle
       /myAlfa147              // myAlfa147 instanceOf car
         /gearbox              // gearbox isPartOf car
           /myAlfa147Gearbox   // myAlfaGearbox instanceOf Gearbox

To sum up :

  • "isA" relationships would allow refining of concepts (like above "vehicle / road vehicle / car");
  • "isPartOf" relationships would allow instances to have sub-concepts (like "gearbox isPartOf car", if we destroy the car, we destroy the gearbox, so it makes sense to nest).

Question : is it possible to make a "configuration resource" for allowing such complex dynamic endpoints?

Cheers, Grégoire

Like · Post Reply