- From: László Lajos Jánszky <laszlo.janszky@gmail.com>
- Date: Sat, 11 Oct 2014 01:00:59 +0200
- To: Markus Lanthaler <markus.lanthaler@gmx.net>
- Cc: "public-hydra@w3.org" <public-hydra@w3.org>
> </Class> hydra:supportedOperation <OpA> . > </Class> hydra:operation <OpB> . > > </res> rdf:type </Class> . > </res> hydra:operation <OpC> . > > > With this information, a server tells a client that the resource </Class> supports OpB but *not* OpA. </res> supports OpA (because it is an instance of /Class) and OpC. This is very similar to how javascript works. In js terms, hydra:operation is for setting property on the actual object and hydra:supportedOperation is for setting property on the prototype of a constructor (which in js is an object as well). > hydra:Link allows you to express that a property should be interpreted as a link instead of just an ordinary RDF property. In other words, if you encounter something like:... Am I right, that (in JSON-LD terms) @type: "@id" describes that we are talking about an IRI, and @type: "hydra:Link" describes that we are talking about a dereferencable IRI? > Does this clarify it? Yes, most of it. I found it in your dissertation too. Nice work btw! :-) I think the vocab description here: http://www.hydra-cg.com/spec/latest/core/ should contain this in more detail. Btw. it is easier for me to read the RDF syntax you just used. By JSON-LD for me it is a constant source of confusion that I am not sure at first sight whether we are talking about a context (vocab) document or a request/response which uses that context. It would be much easier to understand these concepts if at least one example would describe a class defined in an application specific vocab along with an instance of it contained by a response message. I guess the specification is incomplete, because the vocab is not stable yet, but I believe it would be much easier to contribute if the actual specification draft were always up to date and more detailed.
Received on Friday, 10 October 2014 23:01:26 UTC