Re: terminology/necessity of hydra:required

On Jan 28, 2014, at 1:31 PM, Ruben Verborgh <ruben.verborgh@ugent.be> wrote:

> Dear all,
> 
> hydra:required is used in two places:
> - with hydra:SupportedProperty
> - with hydra:IriTemplateMapping
> 
> What is the necessity to have this on hydra:IriTemplateMapping,
> given that URI templates already allow to specify required and optional properties?
> 

RFC6750 does not have the concept of required properties. If there’s no value for a varspec present at expansion time, it’s either not rendered in the output or it’s represented differently. It’s up to a application, such as Hydra, to define what is required and what is not. The expression is a collection of variable specifications with an optional modifier. Technically, a varspec is not required to have a value present at expansion time. See section 3.2.1: 

http://tools.ietf.org/html/rfc6570#section-3.2.1

The URI Template test suite also demonstrate how this works :

https://github.com/uri-templates/uritemplate-test

> From RFC6750:
>> Form-style query expansion, as indicated by the question-mark ("?")
>> operator in Level 3 and above templates, is useful for describing an
>> entire optional query component
> 
>> Form-style query continuation, as indicated by the ampersand ("&")
>> operator in Level 3 and above templates, is useful for describing
>> optional &name=value pairs in a template that already contains a
>> literal query component with fixed parameters.
> 
> If there is a necessity, shouldn't we split them into:
> - hydra:requiredProperty with domain hydra:SupportedProperty?
> - hydra:requiredMapping with domain hydra:IriTemplateMapping?

You kind of bring up a point I raised in another thread on this list which is do we even need IriTemplate when Operation could work for GETs as well? If you squint a little bit, this Hyrda definition:


{
  "@context": "http://www.w3.org/ns/hydra/context.jsonld",
   "@type": "IriTemplate",
  "template": "http://api.example.com/issues{?query}",
  "mappings": [
    {
      "@type": "IriTemplateMapping",
      "variable": "query",
      "property": "#SearchCriteria",
      "required": true
    }
  ]
}

Now starts to look a lot like an hydra:Operation with was hydra:method value of GET. Thus, we could express it as:

{
  "@context": "http://www.w3.org/ns/hydra/context.jsonld",
  "@id": "/issues",
  "operations": [
    {
      "@type": "ReadResourceOperation",
      "method": "GET",
      "expects" : "#SearchCriteria"
    }
  ]
}

As I stated in the other thread, I’m glossing over the fact that Hydra doesn’t (yet?) define a mechanism to take something like #SearchCriteria and send it as query string on a URL. But assuming we went that route, it’d provide consistency with other Hyrda Operation instances. It becomes a but more analogous to HTML forms whereby the same mechanism can be used for GET and POST. In Hyrda’s case, it’d also support the other HTTP Methods as well. 

> 
> This splitting argument also holds for hydra:property,
> which is used with both hydra:SupportedProperty and hydra:IriTemplateMapping.
> I wonder if it is really a good idea to have
>    _:something hydra:SupportedProperties _:supportedProperty.
>    _: supportedProperty hydra:property _:property.
> since SupportedProperty is, confusingly, _not_ a property,
> but it does _have_ a property. How about something like:
>    _:something hydra:parameter_:parameter.
>    _: parameter hydra:controls _:property.
> 
> Best,
> 
> Ruben


+-----------------------------------------------+
    Ryan J. McDonough
    http://damnhandy.com
    http://twitter.com/damnhandy

Received on Saturday, 1 February 2014 15:17:22 UTC