Re: terminology/necessity of hydra:required

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

It does simplify.
…but is simplification the most important goal here?
It gets the model really messy and inexact.
Is the trade-off worth it?

This should be discussed in more detail.
I can think of a dozen things that could simplify;
but not without loosing semantics.
It's the wrong quality attribute here.

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


Here's a concrete problem:

 foaf:Person hydra:supportedProperty
      foaf:givenName ,
      <http:/example.org/xyz>.

Now what should I do?
Should I look up <http:/example.org/xyz>
and see whether it is an rdf:Property or a hydra:SupportedProperty?
Or should I assume it is an rdf:Property? Or a hydra:SupportedProperty?

You seem to silently assume that people will either give
a URI that is an rdf:Property or a blank node that is a SupportedProperty.
That assumption is incorrect and leads to unclear modeling.

This is messy. I don't like it at all.

Best,

Ruben

Received on Monday, 10 February 2014 10:31:21 UTC