Re: terminology/necessity of hydra:required

On Feb 9, 2014, at 6:22 AM, Markus Lanthaler <markus.lanthaler@gmx.net> wrote:

> On Thursday, February 06, 2014 7:53 PM, Ruben Verborgh wrote:
>>>> Yes and no. in the first you have the confusion that a
>>>> SupportedProperty is not a Property;
>>>> the hydra:SupportedProperty is the blank node; the hydra:property is
>>>> foaf:name.
>>> 
>>> There have been discussions (mainly with Sam) to relax this
>>> restriction so that you can also directly point to a property
>>> instead of going through the indirection of SupportedProperty.
>> 
>> Mmm, the "also" bothers me there.
>> Because then, the range of hydra:supportedProperty
>> would be the union of rdf:Property and hydra:SupportedProperty.
>> and hydra:SupportedProperty would still not be property nor
>> rdf:Property.
> 
> Initially, I wasn't a big fan of that either but Sam convinced me that in a
> lot of cases it helps to drastically simplify the required markup. If you
> don't need to make any further statements about your supportedProperties,
> you just enumerate them directly:
> 
>   foaf:Person hydra:supportedProperty
>       foaf:givenName ,
>       foaf:familyName .
> 
> If you need to describe them, you add a SupportedProperty construct in
> between
> 
>   foaf:Person hydra:supportedProperty
>       foaf:givenName,
>       [ hydra:property foaf:familyName ;
>         hydra:required true ] .

I'm trying to reconcile the need for hydra:required if we also use OWL for cardinality and other purposes. Couldn't you just as easily (for some value of easily) add a restriction for foaf:familyName when used with foaf:Person within the context of the API? For example,

foaf:Person rdfs:subClassOf owl:Restriction [ owl:onProperty foaf:familyName; owl:cardinality "1"^^xsd:unsignedInteger ] .

This certainly makes the presence of familyName required, although it also has the effect of making it required on all subclasses of foaf:Person I believe. Other properties may use owl:minCardinality instead, but that wouldn't make much sense for a family name.

Gregg

>> Either have the indirection or don't. but not both.
> 
> It makes processing of the data slightly more difficult but has the
> advantage that you can avoid SupportedProperty in a lot of case. Do you see
> other disadvantages of allowing both?
> 
> 
>>> . and at the same time you would introduce hydra:optionalParameter?
>> 
>> or not. Just hydra:parameter and hydra:required true/false.
> 
> So effectively you would just propose to rename supportedProperty to
> parameter?
> 
> 
>>> I'm still not convinced of this terminology. "Class" and "parameter"
>>> do not really match IMO.
>> 
>> Fair enough. But a SupportedProperty that's not a property doesn't seem
>> optimal either.
> 
> Hm... would PropertyDescription or something similar be better in your
> opinion?
> 
> 
>> Alternatives needed?
> 
> That would certainly help
> 
> 
> --
> Markus Lanthaler
> @markuslanthaler
> 
>

Received on Monday, 10 February 2014 21:06:18 UTC