Re: Define/change the range of "supportedProperties" (ISSUE-37)

On 02/15/2014 08:39 PM, Ruben Verborgh wrote:
>>> I do agree with this statement;
>>> I probably did misunderstand "classes" then above;
>> So this point is valid I think. If we make it "mandatory" then
>> we force API providers to re-enumerate properties — I don't like this.
> I don't see how this makes things mandatory?
> Where is the explicit enumeration?
> I think this concern is orthogonal to the decision.

I think you introduced the term "mandatory", that's why I put it in quotes.
My concern is that if I define a hydra:class, I have to explicitly 
enumerate all
properties that must/ can be provided to create such a resource.
This is good because it aids for the HTML form replacement we
discussed in another thread but I wouldn't make this "mandatory".

>>> Because a SupportedProperty is not a Property.
>>> That's confusing.
>> Ok, you mean it's rather a proxy than the property itself?
> Yes, it needs to be better defined than just a proxy;
> a better name can help really.
> The confusion is reflected in the (incorrect) description:
>      {
>        "@id": "hydra:SupportedProperty",
>        "@type": "hydra:Class",
>        "comment": "A property known to be supported by a Hydra class.",
>        "label": "Supported Property",
>        "status": "stable"
>      },
> That's not right: a SupportedProperty is _not_ a property.
>
> A “SupportedProperty" associates an "rdf:Property"
> with characteristics that are valid for a certain Hydra class.

Ok, from a technical standpoint which involves the RDF I agree with
you, you "associate" the property with the class, that's a very concise 
description.
 From an API consumer perspective however these associations become 
properties of the operation
he performs... that's at least what I understood.

> So this is why I would call them Parameters;

Without thinking about it: I don't like it because this reminds me of a 
function call and
as we are network transparent: RPC and we all know that this is the tabu 
word in the REST world.

> that introduces a distinct concept instead of something vague like a proxy.
>
> Example: the movie object has a parameter

Hmm, objects cannot have parameters in my IT vocabulary.

> that corresponds to the property "foaf:maker",
> but it is read-only.
>
> Try replacing "parameter" by "supported property"
> to see the example gets more confusing.
> A SupportedProperty looks like a semi-concept to me;
> it's not a property but almost a property.
> A parameter is not a property, but it can link to a property.

Again, I got your point but I can think of no better
term than xxxxproperty (considering proxy, surrogate, parameter).

Thomas

Received on Tuesday, 18 February 2014 23:38:55 UTC