Re: OLDM using the Hydra vocabulary for expressing property constraints

Le 13/06/2014 00:57, Markus Lanthaler a écrit :
> Welcome on board Benjamin!
Thank you Markus
> 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?
>
Happy to hear that! Yes, you guess right, for the email address, we have
a specific Python validator in Python that is registered for the
foaf:mbox and schema:email properties. But the email address is just a
special case and this practise should be avoided for regular properties.
Currently, it checks:
  - the XSD datatypes declared in the JSON-LD context,
  - the container (set, list and language maps) when appropriate,
  - the hydra:required, hydra:writeonly and hydra:readonly properties.
This is clearly not enough to provide an alternative to what common ORMs
do, so I have opened an issue for supporting new vocabularies [3].
I will first give a try a SPIN-based data quality constraint ontology: [4] .
>> 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. :-)
Yes, I agree, on the client side we cannot always assume that (i) a
SPARQL endpoint is available, (ii) the server will make no validation
and (iii) accept our local representation. I will propose an interface
to abstract the use of a SPARQL endpoint. For me, implementations of
this interface (e.g. LD Fragments or Hydra clients) should in charge of
mapping the client and server representations. What do you think?
>
>> 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].
Ok, I will give a try to the hydra:reverseOf property and see if it
breaks my current design ;-)
>
> I find your project extremely interesting. What are your future plans? What's still missing that you plan to add?
Great, I hope it will be useful :)
In addition to the points I mentioned, I have started a CRUDController
[5] that manipulates resources having the same base IRI. This controller
may be extended to
implement the collection pattern.
>
> Please keep us posted on your progress,
> Markus
With pleasure.

Benjamin
>
> [1] http://linkeddatafragments.org/
> [2] https://github.com/HydraCG/Specifications/issues/40
>
>
>
> --
> Markus Lanthaler
> @markuslanthaler
>
>
[3] https://github.com/oldm/OldMan/issues/9
[4] http://semwebquality.org/ontologies/dq-constraints
[5] http://oldman.readthedocs.org/en/latest/oldman.rest.html

Received on Friday, 13 June 2014 20:53:11 UTC