Re: Repeating IriTemplate parameters

Am 10.11.2015 17:30 schrieb Maik Riechert <m.riechert@reading.ac.uk>:
>
>
>
> On 10/11/2015 14:35, Tomasz Pluskiewicz wrote: 
> > November 10 2015 2:42 PM, "Maik Riechert" <m.riechert@reading.ac.uk> wrote: 
> >> On 10/11/2015 13:26, Dietrich Schulten wrote: 
> >> 
> >>>> I don't see multi-valued parameters in the spec right now. 
> >>>> Others, do we have something for that? 
> >>>> 
> >>> We do, since we refer to RFC 6570 for the IriTemplate syntax. 
> >>> 
> >>> The UriTemplates RFC 6570 has a * modifier for this: 
> >>> http://tools.ietf.org/html/rfc6570#page-16 
> >> I know the RFC but I'm not sure how hydra's IriTemplateMapping works in 
> >> that case. The client doesn't inspect the template string, it just uses 
> >> it, so it doesn't know about * modifiers in the template. That means the 
> >> client has to know that a given variable is supposed to be a list or a 
> >> map of values. Where does that information go? Is that inside the 
> >> "property"? How would the "range" look like then? 
> >> 
> > I think the client would actually have inspect the template. The template mapping is there to translate URI part and query param names to URIs. It shouldn't do more IMO. 
> So, hypothetically, if a template mapping has "property": "foaf:name" 
> and the variable is included in the template as {?name*}. Does that then 
> either mean: a) multiple "foaf:name"'s should be put into the name 
> variable, 

zero or more foaf:name values may be put into the uritemplate expansion, if the variable is optional. If the mapping says it is required, then one or more. 

I see your issue, though. You want to express an expected value and cardinalities somehow. There is no decision yet what a compliant client should support for this purpose. 

A possible solution might be to use http://schema.org/PropertyValueSpecification or SHACL to describe expected values. For the former, that could look like this:

.. Context defines schema: prefix.. 
"mapping": [ 
  { 
    "@type": [
      "IriTemplateMapping", 
      "schema:PropertyValueSpecification"
      ], 
    "variable": "q", 
    "property": "foaf:name", 
    "required": true, 
    "schema:multipleValues" : true
  } 
]

It lacks a property for allowed values, though. 

We haven't really looked at SHACL yet. I am not sure if any of its mechanisms to connect shapes and instances can be applied to hydra. Holger Knublauch has made a proposal for hydra:Class though, and that might work with IriTemplateMapping, too. SHACL is still quite volatile, sh:allowedValue was renamed to sh:in just recently.

or b) "foaf:name" itself as a single entity becomes a 
> composite value somehow?  

In which way would it become a composite value? 

If a) is true, then how would you describe the 
> collection of foaf:name's as such? For example, just including a comment 
> like "all foaf:name's are connected by an OR in that filter operation". 

Query parameters are no query language, and I think most members agree that we should again rely on 3rd party solutions rather than inventing our own.

We have no formal way to say what the server is going to do with the list. OK Ruben has proposed hydra:filter which could say something about OR conditions.

Cheers, 

Dietrich