RE: Let's get started - question to hydra:supportedProperties

On Thursday, July 04, 2013 11:59 PM, Matthias Lehmann wrote:
> Hello,
>
> my name is Matthias Lehmann, I work at a German Start-Up which is
> working on a search product.
> Right now, we want to give our current API a overhaul to make it
> RESTful (it is a JSON-RPC-REST-Hybrid, right now). Researching
> existing Hypertext solutions, I came across Hydra, which seems to
> address that topic. Since we are thinking about making use of
> Linked-Data/JSON-LD in other aspects of our software, too, Hydra looks
> like a good fit.
> 
> I am just a "normal" developer, mainly coding in Python. Being a
> professional developer for just about eight years now, I have not
> authored any RFC nor am I writing on a Ph.D ;-)  But maybe that
> pragmatic, down-in-the-trenches worldview can be of some use here,
> too.

Definitely. Writing specs or PhD's is far more boring than writing code :-)
If Hydra doesn't help developers to get their job done than we failed. So
your input is much appreciated. Welcome on board!


> I am using RDF/OWL, Semantic Data, JSON-LD etc. to some degree
> already, but I am still making myself familiar with all these
> concepts. So most of what I say comes from the viewpoint of somebody
> coming "from outside".
>
> So, let's start with one of these stupid questions:
> 
> There is the  hydra:SupportedProperties class, which is the range of
> hydra:supportedProperties and the domain of hydra:property, which
> again has rdfs:Property as its range. What I don't understand: why is
> that additional nesting necessary?
> 
> It looks like
> 
> {
>  "@id": "my:Foo",
>  "supportedProperties": [
>   {
>     "property": {
>        "@id": "my:prop",
>        "label": "Super Duper"
>   }
>   "readonly": true
>   ]
> }
> 
> Why can't it just be like:
> 
> {
>   "supportedProperties": [
>   {
>     "@id": "my:prop",
>     "label": "Super Duper"
>     "readonly": true
>   }
>   ]
> }
> 
> 
> To answer my question myself: I guess it is to allow to say: when
> my:prop is property of a my:Foo then it is read-only, but there might
> be other uses, when it is not read-only.

Exactly. Hydra emphasizes reuse of concepts. Thus, in a lot of cases you
wouldn't define that property yourself but re-use, e.g., something from
schema.org. Since you don't have control over their definitions you would
have to create a "local" redefinition but that becomes problematic when you
integrate data.


> But hydra:supportedOperations
> (at least in the demo-api) is a property of the rdfs:Property and not
> of the hydra:SupportedProperty like hydra:readonly. Isn't that
> inconsistent?

That's a good question. As you say, supportedOperations is a property of
hydra:Class, hydra:Link and hydra:TemplatedLink which means you "can't"
associate an operation to a property you don't own - but the same is true
for classes. This may sound like an arbitrary decision but the rationale was
that things like required/readonly/writeonly for a property may vary
*within* a single API whereas supportedOperations should stay the same as it
is effectively a property of the target (i.e., the value of the property)
and not the property:

{
  "@id": "/post",
  "comments": "/post/comments/"
}

If comments has a number of supportedOperations then that really means that
"/post/comments/" supports those operations (see hydra:Resource ->
operations). If we would allow supportedOperations as part of a
SupportedProperty then we would have to evaluate all classes of "/post" and
their supportedOperations to find that out.

So summarized I would say that Hydra is consistent in this regard but there
might be use cases where it would be beneficial to allow that. This would
however cause a lot of complexity and thus I favor the simpler approach
which is to simply create a specialization of the property
(rdfs:subPropertyOf).

Does that make sense?


> Another thought: If I want to use that information for form creation,
> I would like to have control over the label (and maybe even comment),
> but the label of the property might come from an extern ontology.
> Would it be feasible, to have a hydra:label that a form creation
> library could give precedence over rdfs:label?

Sure, that would make a lot of sense. Have you seen hydra:title and
hydra:description? Those are the two properties I created exactly for such
use cases. I didn't use them in any of the examples yet and the API console
doesn't support the scenario you describe either but that's definitely
something worth implementing and documenting. Thanks.

I've moved the specification to a GitHub organization and added an issue for
this. You can find it here:
  https://github.com/HydraCG/Specifications/issues/1


> Otherwise, if I have to subClass the properties of the extern ontology
> to enforce my customizations anyways, than this extra nesting might as
> well be unnecessary.

There's always a trade-off. My assumption is that associating operations to
external properties won't be needed that often whereas setting things like
required is a quite common requirement. Thoughts?


--
Markus Lanthaler
@markuslanthaler

Received on Friday, 5 July 2013 14:28:30 UTC