RE: Introduction and some questions

Hi Peb,

and welcome on the list :-)


On Monday, September 15, 2014 6:23 PM, peb aryan wrote:
> My name is Peb, I am a student at Vienna UT. I have been interested by
> Hydra for some times but only recently decided to read the draft spec
> with more attention. I am playing with python codes using rdflib and
> rdflib-jsonld in order to write my own console as a way to try to
> understand hydra
> (https://gist.github.com/pebbie/3a6b2b10c71ba796dca2).

Cool, please keep us posted on your progress and let me know when it is ready to be included in the list of tools/libraries/etc. on hydra-cg.com


> for starter, I would like to ask some questions. 
> 
> 1. I believe the root class of Hydra are Resource and Operation to
> denote nouns and verbs. Since the expected/returned representation
> input/output need to be specified and it may not be a location but a
> graph then we cannot use Resource class directly but creating Class as
> a subclassOf Resource. in the draft it is also mentioned that
> hydra:Class is a dereferenceable Resource. conceptually, this becomes
> a bit weird for me. when an instance of hydra:Class is passed as input
> (in expects), it doesn't have to be a dereferenceable resource, right?

hydra:Resource is the class of dereferenceable resources. hydra:Class is the class of classes whose instances are dereferenceable resources as well. I don't know how familiar you are with RDF(S) but it is basically the same as rdfs:Resource and rdfs:Class but dereferenceable.

hydra:expects basically defines a template to fill out when you invoke an operation. It allows the server to tell the client what it expects. This information is conveyed by specifying the type (class) of the desired data:

    "@type": "Operation",
    "expects": "vocab:Person"

If you send an instance of a Person that is identified by a IRI it is indeed expected that the IRI is dereferenceable, i.e., it is actually a URL. But obviously you can omit the identifier and send a blank node as well. That's what the HydraConsole does for example.

Does this clarify it?



> 2. about statusCodes and returns. I believe the returns property is
> only valid if the statusCodes is some value (e.g. 200). how to
> describe, for example if the returned code is 201 then the result is a
> URI (not a triple)?

We discussed this and decided to [1] to rename "statusCodes" to "possibleStatus" and "StatusCodeDescription" to "Status". This allows you to describe multiple possible outcomes. Perhaps we should also move hydra:returns from hydra.Operation to the new hydra:Status.

Thoughts?



> 3. why is hydra:Resource having hydra:operation property while
> hydra:Class having hydra:supportedOperation property. both predicates
> are associating two class in a subClassOf relationship (hydra:Class
> and hydra:Resource) with the same meaning to hydra:Operation. why not
> set the supportedOperation property to Resource (and by RDFS reasoning
> it also becomes valid to assign that property to hydra:Class)?

The hydra:operation property is used to associate operations to resources whereas hydra:supportedOperation is used to bind them to classes (which means they apply to all instances of that class):

    /my-resource hydra:operation [ an operation ]

    vocab:MyClass hydra:supportedOperation [ another operation ]

    /my-instance rdf:type vocab:MyClass

This means that you can invoke [ an operation ] by sending the request to /my-resource while you can invoke [ another operation ] by sending the HTTP request to /my-instance (and not vocab:MyClass).



> 4. would it be better if IriTemplate is defined as Datatype and set
> the domain of template property and mapping property to TemplatedLink?

TemplatedLink is a subclass of rdf:Property, the range of a TemplatedLik is an IriTemplate which not only consists of the template itself but also of the mappings from URL template variables to properties.


> a literal pointed by template property is interpreted as a special
> kind of string literal (a IriTemplate)

We might define a datatype for RFC6570 URL templates [2] but this doesn't change the fact that we need more information about a IriTemplate than the template itself (the mappings are crucial).


> 5. How to define variable dependency in a templated link? which is if
> a variable 'a' is set then variable 'b' becomes required.

This is currently not possible. Do you have a concrete use case that requires this?


> 6. by restricting the hypermedia object as a subclassof hydra:Class,
> then ApiDocumentation, Collection and PagedCollection become
> predefined classes (subClassOf hydra:Class).

Not sure I follow, they are already subclasses of hydra:Class.


> supportedClass, title,
> description, and entrypoint is a SupportedProperty for
> ApiDocumentation Class. member and totalItems is a SupportedProperty
> for Collection. a PagedCollection is adding additional control
> properties (firstPage, prevPage, nextPage, lastPage) and ItemsPerPage
> and perhaps totalPages property.

Hmm... what are you trying to say with this?


> if hydra:Class is the base class of hypermedia object, then to
> interpret if a URL is a part of hydra spec or not can be done without
> setting the Link header but by dereferencing the type of the nodes.

hydra:Class exists to make it possible to declare that instances are dereferenceable (thus links). This is orthogonal to the other aspects of Hydra such as hydra:ApiDocumentation


> hopefully, when the type of the subjects are dereferenced, they point
> to the graph which contains the definition that the class name as a
> subclassof hydraClass (and maybe the rest of ApiDocumentation in the
> case of vocab:EntryPoint in http://www.markus-lanthaler.com/hydra/api-
> demo/).

I tried that design in the beginning but it is way too limiting. It basically becomes impossible to reuse existing vocabularies if you design it that way.


> I have been trying to skim the archive but overwhelmed by the
> discussions so please pardon if some topics mentioned in my post are
> already discussed.

Yeah, luckily we are a quite active community :-) Just ask if you have questions, it also helps us to understand what needs to be clarified etc. So no need to apologize.


Cheers,
Markus


[1] https://github.com/HydraCG/Specifications/issues/27#issuecomment-50558851
[2] https://github.com/HydraCG/Specifications/issues/17


--
Markus Lanthaler
@markuslanthaler

Received on Tuesday, 16 September 2014 19:46:39 UTC