RE: OLDM using the Hydra vocabulary for expressing property constraints

Welcome on board Benjamin!

On 11 Jun 2014 at 12:51, Benjamin Cogrel wrote:
> I have just joined the Hydra Community Group, this is my first message
> to the list.
> I really appreciate this initiative and the good work you have already made.

Thanks


> During the last months, I have been working on an Object Linked Data
> Mapper (OLDM, another name for Object RDF Mapper) in Python:
> https://github.com/oldm/OldMan .

This looks great. It's very intuitive. Great work! One thing that isn't clear to me (by just looking at the documentation) is how you do data validation. How does OLDM know that the email address isn't valid? Is that hard-coded for FOAF?


> This project, influenced by Hydra and JSON-LD, enables developers to
> express the domain logic in RDF instead of encoding it into some Python
> code, for the benefit of Web clients. It uses some Hydra vocabulary and
> will support additional ones in the next future.

Cool!


> Currently, the "hydra:supportedProperty" is used for mapping properties
> to resource objects.
> It also supports the "hydra:readonly", "hydra:writeonly" and
> "hydra:required" properties.
> 
> I have seen that some of these terms are willing to change but this
> should not be a problem because this
> project is still very young.

Yeah, we might rename readonly/writeonly to readable/writable.


> For this first milestone, I have focused on a server-centric perspective
> and I start to think that this OLDM could be of interest for building
> Web clients. Currently, it relies on a SPARQL endpoint but I think it
> would be better to make optional to allow alternatives like LDP or LD
> fragments. Designing Web clients is rather a new topic to me so if you
> have any suggestion about this, I would be very happy to hear it.

On the client side, in a lot of cases you have entities that look different that those that the server gives you. So you probably want something to map the representation returned by the server to your local entities. You shouldn't require the client to use exactly the same entities as the server as that would introduce tight coupling. From a Hydra point of view (and Web APIs in general) you probably also want some features that allow you to invoke operations. Also, in most cases you probably can't assume that a SPARQL endpoint will be available. So you have to navigate the resources expose by the server. Hydra supports (and this will be improved) some basic querying/filtering of collections. Ruben is working on more sophisticated querying in a project he called Linked Data Fragments [1]. He's also on this list and I'm sure he's more than happy to answer any question you might have. Since this is closely related to Hydra, those discussions would be very welcome on this list btw. :-)


> Also, in the future, I would like to support the "@reverse" JSON-LD
> keyword so I would be interested about having some "reversed supported
> properties".

We talked about this already. We might introduce a reversed flag (similar to required) for supported properties to support it. This is already being tracked as ISSUE-40 [2].

I find your project extremely interesting. What are your future plans? What's still missing that you plan to add?


Please keep us posted on your progress,
Markus


[1] http://linkeddatafragments.org/
[2] https://github.com/HydraCG/Specifications/issues/40



--
Markus Lanthaler
@markuslanthaler

Received on Thursday, 12 June 2014 22:58:00 UTC