- From: Ruben Verborgh <ruben.verborgh@ugent.be>
- Date: Sat, 15 Feb 2014 19:39:59 +0000
- To: Thomas Hoppe <thomas.hoppe@n-fuse.de>
- Cc: public-hydra@w3.org
>> 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.
>> 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.
So this is why I would call them Parameters;
that introduces a distinct concept instead of something vague like a proxy.
Example: the movie object has a parameter
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.
Best,
Ruben
Received on Saturday, 15 February 2014 19:40:34 UTC