Creating JsonLd + Hydra based Generic Client API in java. Is there any projects exist for reference?

Question

I am creating Client API in Java using :
+ Apache Jena FrameWork
+ Hydra(for Hypermedia driven)
+ my private vocab similar to Markus Lanther Event-API Vocab instead of schema.org(for Ontology/Vocabulary part)

Section 1 :
After looking this Markus Lanther EventDemo repo and hydra-java.I found that they are creating classes for each hydra:Class that can break client in future .For example :
A Person class (Person.java)

public class Person
{
     String name;
}; 

But in future requirement name is also a class eg:

public class Name
{
    String firstName;
    String LastName;
};

So to fulfill this requirement I have to update Person class like this:

public class Person
{
   Name name;
};

Question 1:
Is my understanding correct or not of this Section? If yes then what is the way to deal with this part ?

Section 2:
To avoid above problem I created a GenericResource class(GenericResource.java)

public class GenericResource
{
   private Model model;
   public void addProperty(String propertyName,Object propertyValue)
   {
      propertyName = "myvocab:"+propertyName;
      //Because he will pass propertyName only eg: "name" and I will map it to "myvocab:name"
      //Some logic to add propertyName and propertyValue to model
   }
   public GenericResource retriveProperty(String propertyName)
   {
      propertyName = "myvocab:"+propertyName;
      //Some logic to query and retrieve propertyName data from this Object add it to new GenericResource Object and return
   }

   public GenericResouce performAction(String actionName,String postData)
   {
       //Some logic to make http call give response in return
   }
}

But again I stuck in lots of problem :
Problem 1:
It is not necessary that every propertyName is mapped to myvocab:propertyName.
Some may be mapped to some other vocab eg: hydra:propertyName, schema:propertyName, rdfs:propertyName, newVocab:propertyName, etc.

Problem 2:
How to validate whether this propertyName belongs to this class ?
Suggestion:
Put type field/variable in GenericResource class.And then check supportedProperty in vocab corresponding to that class.
To more clarity assume above Person class which is also defined in vocab and having supportedProperty : [name,age,etc] .
So my GenericResource have type "Person" and at time of addProperty or some other operation , I will query through vocab for that property is in supportedProperty list or in supportedOperation list in case of performAction().
Is it correct way ? Any other suggestion will be most welcomed?

Answer 1

Question 1: Is my understanding correct or not of this Section? If yes then what is the way to deal with this part ?

Yes, that seems to be correct. Just because hydra-java decided to creates classes doesn't mean you have to do the same in your implementation though. I would rather write a mapper and annotate an internal class that can then stay stable (you need to update the mapping instead). Your GenericResource approach also looks good btw.

Problem 1: It is not necessary that every propertyName is mapped to myvocab:propertyName. Some may be mapped to some other vocab eg: hydra:propertyName, schema:propertyName, rdfs:propertyName, newVocab:propertyName, etc.

Why don't you store and access the properties with full URLs, i.e., including the vocab? You can of course implement some convenience methods to simplify the work with your vocab.

Problem 2: How to validate whether this propertyName belongs to this class

Suggestion: Put type field/variable in GenericResource class

JSON-LD's @type in node objects (not in @value objects) corresponds to rdf:type. So simply add it as every other property.

And then check supportedProperty in vocab corresponding to that class.

Please keep in mind that supportedProperty only tells you which properties are known to be supported. It doesn't tell you which aren't. In other words, it is valid to have properties other than the ones listed as supportedProperty on an object/resource.

Answer 2

Ad Q1: For the flexibility you want, the client has to be prepared for semantic and structural changes.

In HTML that is possible. The server can change the structure of an html form in the way outlined by you, by having a firstName and lastName field rather than just a name field. The client does not break, rather it adjusts its UI, following the new semantics. The trick is that the UI is generated, not fixed.

A client which tries to unmarshal the incoming message into a fixed representation, such as a Java bean, is out of luck, and I do not think there is any solution how you could deserialize into a Java bean and survive a change like yours.

If you do not try to deserialize, but stick to reading and processing the incoming message into a more flexible representation, then you can achieve the kind of evolvability you're after. The client must be able to handle the flexible representation accordingly. It could generate UIs rather than binding data to fixed markup, which means, it makes no assumptions about the semantics and structure of the data. If the client absolutely has to know what a data element means, then the server cannot change the related semantics, it can only add new items with the new semantics while keeping the old ones around.

If there were a way how a server could hand out a new structure with a code-on-demand adapter for existing clients, then the server would gain a lot of evolvability. But I am not aware of any such solutions yet.

Ad Q2: If your goal is to read an incoming json-ld response into a Jena Model on the client side, please see https://jena.apache.org/documentation/io/rdf-input.html

Model model = ModelFactory.createDefaultModel() ;
String base = null;
model.read(inputStream, base, "JSON-LD");

Thus your client will not break in the sense that it cannot read the incoming response. I think that is what your GenericResource achieves, too. But you could use Jena directly on the client side. Basically, you would avoid unmarshalling into a fixed type.