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

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.

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

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?

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.

So much for now.

Best regards

Matthisa

Received on Friday, 5 July 2013 08:31:07 UTC