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

>>> The problem is that it doesn't scale. We already have "required",
>>> "readonly", "writeonly" and people will likely want to extend it with
>>> cardinality etc.
>> 
>> No no, it scales as good as "required", "readonly", "writeonly".
>> You'd need an equal number of properties; they would just have a different domain;
>> i.e., hydra:Class, not hydra:PropertyRestriction.
> 
> You lost me; why wouldn't cardinality (or simply "multiplicity") not have a domain of hydra:PropertyRestriction?

Markus said that "_:class hydra:xxxxxxProperty _:prop" doesn't scale.
I say that it doesn't scale differently than
"_:class hydra:propertyRestriction [ hydra:property _:prop; hydra:xxxxxx true ]".

But I was to quick in saying that;
this only applies to boolean properties but not others.

With "different domain", I thus meant that
hydra:xxxxxxProperty would have hydra:Class,
and hydra:xxxxxx would have hydra:PropertyRestriction as domain.

> So sooner or later we will need a "proxy" anyway. In this
>>> case, I find it better to anticipate it from the beginning as extensions
>>> requiring it are very likely to happen.
>> 
>> I'm still in favor of sticking a name to such a proxy;
>> but if we have difficulties to find a name that doesn't contain "property",
>> I'm afraid it will always remain tricky.
> 
> Could you illustrate this?

“A class can have a supportedProperty that is a SupportedProperty
but not a Real property, but it has a property property that points to the Real property.”

“Property restriction” is fine in that sense.
But does it convey the notion that a certain property can be used?

Best,

Ruben

Received on Monday, 10 March 2014 20:35:15 UTC