Fwd: Using Hydra for Data Model Genration and Validation

Hi Markus!


> 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.


Yes, but this would be completely sufficient for the creation and
validation of forms. The idea would be to have hard validation prevent
the users from entering crude mistakes that can easily be avoided,
even on the front-end side. After that could still be an open world
system that can do further reasoning. But if the validation and form
is rather rigid, a lot of problems wouldn't even enter.

> 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.


That sounds interesting! but Its not my intention to "bloat" Hydra
with additional features to allow form and validation - escept this
makes sense anyway. Sometimes its a better solution to have modular
"extensions" that can be used if required?

> 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).


Correct me if I'm wrong on that.. but isn't the RDFS Class and
Property system in some aspects very different from "usual" object
orientation? But I guess if it is used only for inheritance and not
for reasoning this makes not much difference?

> 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.


> Yes, validation could make sense there. What do you think about making suggests about which input types / widgets to use? Maybe this is a bad idea since this can heavily depend on the client implementation. But if used for own purposes (like your HydraConsole) it would be useful for auto generation if this could be somehow added on top. Of course this is nothing that could be standardized.


Maybe the HTML5 Input Types are a good place to start?
http://www.w3schools.com/html/html5_form_input_types.asp
I also like the ability to just define a Regular Expression if the
standardized types do not suffice. This is of course not semantic, but
it is sufficient for validation purposes.

Regards,
Simon


2014-10-13 17:44 GMT+02:00 Markus Lanthaler <markus.lanthaler@gmx.net>:
>
> 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 Tuesday, 14 October 2014 10:45:50 UTC