Re: OLDM using the Hydra vocabulary for expressing property constraints

Le 18/06/2014 13:34, Markus Lanthaler a écrit :
> Yeah, it's definitely a powerful approach and worth investigating further. If you experiment with it, please post a couple of examples to this list so that other people will get an idea of how it looks like (I don't think everyone on this list is familiar with SPIN). For validation, you might also want to have a look at ShEx:
>
>  - http://www.w3.org/2013/ShEx/Primer
>  - http://www.w3.org/2013/ShEx/Definition.html
>  - https://www.w3.org/2001/sw/wiki/ShEx/RDF_serialization
>  - https://www.w3.org/2001/sw/wiki/ShEx
Ok.
I was not aware of this ongoing work, thanks! It looks like a good
option. They also talk about compilation to SPARQL queries.

> Fully agreed. Nevertheless you need to import the data you get from the Web API to into your application's object graph in some form or another. That's why I talked about a mapper. This is primarily about clients accessing an API, not servers providing it.

Mapper is the word, indeed. The evolutions we discuss strengthen the
meaning of Object Linked Data Mapper, that's a good point :)

>> As a second step, we can relax the assumption that the (main) Web API
>> controls the SPARQL endpoint and see this Web API as the client of other
>> independent (sub) Web APIs. OldMan, as an OLDM, is the module of the
>> main Web API that is in charge of CRUD operations*. This OLDM can now be
>> seen as the client of a datastore where the latter may use a different
>> representation that the one of the main Web API** and may enforce its
>> own data validation. I will propose an interface between the core of
>> OldMan and client modules for interacting with SPARQL endpoints, LDF and
>> LDP servers, Hydra Web APIs, etc. These client modules will be in charge
>> of the mapping between local and remote representations you discussed.
>> As agents, they will execute the CRUD "goals" assigned by the core part.
> OK, looks as we are more or less on the same page. Probably I separated client and server too much...
>
>
>> You mentioned  the integration of non-CRUD hydra operations, this could
>> be a third step.  Currently, the OLDM uses the Hydra description of the
>> main Web API as the schema of its local representation. If non-CRUD
>> operations should appear on Resource or Model objects, I think they
>> should be operations provided (i) by the Web APIs the OLDM is client of
>> or (ii) by a common abstraction of them. The latter abstraction would
>> reduce the coupling. If I guess right, this would turn OldMan into a
>> generic Hydra client library, isn't it?
> Right. That's what I had in mind.

Excellent! I have opened two issues for these two steps: [1] and [2].

>> However, one thing still
>> confuses me: how can we obtain nice Python methods (like [7]) from these
>> Hydra operations?
> I'm not that much of a Python programmer but you could probably use magic methods:
>   - _getattr__ to retrieve the right operation: myobject.CommentAction
>   - __call__ on that operation object to make it callable: myobject.CommentAction("hi there")
>
> Otherwise, using less magic, you could it similar to what I proposed in my last mail:
>
>>>    article.perform("LikeAction")

I am ok with the basic Python magic, I already used it in the current
version of OldMan.

Actually, I was confused about the parameters non-CRUD methods may take.
My current answer is that, similarly to the `model.create()` method,
these parameters could just be the properties of the representation that
will be sent directly (or after translation) to the Web API.


Cheers,
Benjamin

[1] https://github.com/oldm/OldMan/issues/33
[2] https://github.com/oldm/OldMan/issues/34

Received on Thursday, 19 June 2014 13:01:53 UTC