RE: OLDM using the Hydra vocabulary for expressing property constraints

On 13 Jun 2014 at 22:52, Benjamin Cogrel wrote:
> Le 13/06/2014 00:57, Markus Lanthaler a écrit :
>> 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] .

Do you intend to share this information with the client or will this just be used on the server side? In the latter case, I'm wondering whether it wouldn't be simpler to just create a mapping property-validator directly in code when you instantiate the ResourceManager or Model!?


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

The absence of SPARQL is one thing. The other thing I was talking about are entity representations themselves. A client might already have a Python class representing a person. When it retrieves the representation of a foaf:Person from the server, it somehow has to map the data it got to that class. Obviously that mapping has to be bidirectional.


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

Please share your insights on this as it will help us with the design of Hydra.


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

Why did you decide to not expose those methods directly on your models? You could also generalize this by evaluating the available Hydra operations. This would then allow you to do things like

   article.perform("LikeAction")

You should perhaps also use a term like "fragment-less IRI" or "hash-less IRI" instead of "base IRI" as the "base IRI" can have a fragment as well.


Keep up the good work,
Markus


 
>> [1] http://linkeddatafragments.org/
>> [2] https://github.com/HydraCG/Specifications/issues/40
> [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


--
Markus Lanthaler
@markuslanthaler

Received on Saturday, 14 June 2014 20:46:38 UTC