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

On Thursday, July 11, 2013 12:10 PM, Matthias Lehmann wrote:
> >> 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.
> 
> I didn't understand that. Why can't I associate an operation to a
> property I don't own - isn't that exactly what is happening,
> since hydra:supportedOperations is subject of the property from an
> external ontology given by hydra:property?

supportedOperations is a property of the property itself:

  {
    "@id": "#someProperty",
    "@type": "hydra:Link",
    "supportedOperations": [ ... ]
  }

it is not a property of a SupportedProperty, so currently the following
wouldn't be supported:

  {
    "@type": "hydra:SupportedProperty",
    "property": "#someProperty",
    "supportedOperations": ... not supported at the moment ...
  }

I can see how this might not be ideal but haven't found a design yet that
completely satisfied me. At the moment, I would just create a need property
which is a rdfs:subPropertyOf the property I would like to associate
operations to. Obviously adds complexity on the client as it would need to
evaluate those subPropertyOf relations.

So maybe it would indeed make sense to relax that restriction and allow
supportedOperations on a SupportedProperty and require the client to
evaluate them as well. This would mean that if you look at a specific
property of an entity, you would have to look up all class definitions of an
entity, look for the property in supportedProperties and see if it has some
supportedOperations.

Would you suggest to, in turn, disallow to associate operations directly on
properties?


> And isn't that one of the
> key philosophies of RDF - this web extentability?

I put the "can't" in quotes in my response because you technically can (of
course) but I believe you shouldn't. Since everything uses global
identifiers, i.e., data integration is extremely simple... and you should
keep that in mind when creating data. If you associate operations to someone
else's property and other people did the same, you would end up having a
plethora of operations associated to that property if you would integrate
your data with theirs - even though only the entities using that property
would support only a subset of all those (merged) operations.


> > 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.
> 
> OK, I had to think about that quite a bit to I understand - because I
> had to make myself aware of the underlying sematic data-model.
> 
> As I stated before, I am not very deep into all that RDF/semantic
> thinking - I have some understanding of it, but it is not (yet) my
> natural way of thinking. I am a developer, I think in classes with
> attributes and list- and tree-structures. And that is probably, how
> most developers think. I guess, when Hydra should gain more adoption,
> it is probably important to find ways to somewhat "hide" that semantic
> stuff. But I have to use it more, before I can say more.

Right, and that's the thing I'm most concerned with. The most difficult
thing will be to make it as simple as possible. I think Hydra as it
currently stands supports most use cases but it is still more complex than
it could be. Let's see if we can reduce that complexity.

The problem is indeed, as you state, that the underlying models are quite
different. I once thought about allowing to associate operations only to
classes and rely on rdf:range or something similar to "attach" operations
indirectly to properties. I concluded that that would be even more difficult
to grasp for the average web developer.

Maybe including some rules like

  ?prop supportedOperations ?op
  ?entity ?prop ?target
  => ?target operations ?op

would help to clarify what's going on? Maybe it would also confuse people
even more; dunno.


--
Markus Lanthaler
@markuslanthaler

Received on Thursday, 11 July 2013 12:31:22 UTC