RE: Using Hydra for Data Model Genration and Validation

Hi Simon,

Welcome to the list. Comments inline.


On Tuesday, October 07, 2014 10:55 AM, Simon Heimler wrote:
> I've discovered this project a few days ago and found it very
> interesting, since its somewhat similar to a project I'm doing right
> now ... just more oriented into API modeling and not data model
> development.
> 
> To sum it up shortly: I was using JSON Schema (I've extended it to be
> object oriented) to develop a data model for Semantic MediaWiki. The
> JSON Schema Model is used to auto generate the data model, forms,
> validation and documentation. This worked for me just fine. The
> Semantic URI's, Attributes etc. are created through Semantic
> MediaWiki. If a Triplestore is attached I can query the datasets
> entered via SPARQL, otherwise via the MediaWiki API.
> 
> If you want to take a closer look, here's a presentation:
> http://fannon.de/p/mobo-intro/#/
> 
> In fact, I've thought about using OWL or JSON-LD first, but discarded
> this approach because of some problems, which I would like to discuss
> here. Some of this might be very controversial.
> 
> • It seems to me that it is hard to do "hard validation" and define
> "hard facts", mainly due to the open world assumption behind the semantic
> web philosophy. 

That depends on what you are trying to achieve. You can of course limit your validation to a document and "close the world" by doing so. But obviously your validation results would just be true for that document.


> • Since I want to generate Forms I want to clearly define how data
> should be entered and have hard restrictions that can work real-time
> on the front-end. (Reasoning is too slow for that)

I don't see a problem with that. We don't support any validation constraints apart from readable/writeable/required at the moment but I see no reason for not extending that in the future if people find it useful.


> • For model development one of the main features that really saved me
> a lot of work is object-oriented inheritance. This is a very easy and
> well understood concept and enables the reuse of already existing parts
> while always maintaining the ability to overwrite the results. Is
> something like that possible with JSON-LD too?

Yes, with RDFS (a simple, standardized vocabulary) you can define that a class is a subclass of another class. You can do the same with properties as they are first class citizens (they aren't in most programming languages).


> • I really like to have the most basic technology as the foundation.
> So I'm using the basic JSON file format and on top of that JSON Schema.
> My problem with the OWL was that it was already a complex system (and
> worldview!) to begin with and to add some basic features like hard
> validation you had to add yet another complex system on top of that - 
> just to achive simple things like form generation!

Yep. Hydra puts a strong focus on simplicity (but that's of course a subjective measure). The HydraConsole already leverages Hydra to dynamically render forms. If we would add more constraints to Hydra, the HydraConsole could support more client-side validation.


> • In order to make this project as user friendly as possible to new 
> people it is VERY important to have a low entry barrier. JSON Schema
> is simple enough to learn and understand in a few hours. No need to dive
> into the (rather complex) Semantic Web Theory and Practice.
> But it looks to me that Hydra adresses a few ob those objections. 

Great to hear that.


> I really love the vision behind the Semantic Web and would like to
> leverage the tools behind it. JSON-LD seems to be a good step into
> making this more easy. The biggest advantage may be that it is W3C
> Standardized and I'm using technology which can potentially have a
> very large toolset and support through the community.
> 
> So I'm thinking about if it would work to use JSON-LD / Hydra / ??? to
> make my project (or the bigger idea behind it) work.

I'm quite sure it would... but as said above, we would need to define more constraints to be able describe things such as allowed string lengths etc. If you could compile such a list (probably the easiest way to do that is to file an issue on GitHub [1]) we would have something concrete to discuss.


Cheers,
Markus


[1] https://github.com/HydraCG/Specifications/issues


--
Markus Lanthaler
@markuslanthaler

Received on Monday, 13 October 2014 15:44:46 UTC