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

>> 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? And isn't that one of the
key philosophies of RDF - this web extentability?

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

Best regards

2013/7/5 Markus Lanthaler <markus.lanthaler@gmx.net>:
> 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 Thursday, 11 July 2013 10:10:42 UTC