Re: Repeating IriTemplate parameters

Am 10.11.2015 um 17:29 schrieb Dietrich Schulten:
>
>
> 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.
>
OK, starts to make more sense.

But coming back to "property", what should that actually tell the 
client? Should the client assert "ok, that mapping variable corresponds 
to foaf:name, I know that, it's the name of a thing and has a range of 
rdfs:Literal, so I can directly use that for the template variable". But 
what if "property": "dct:publisher"? Then the client can assert "Ok, 
dct:publisher has range dct:Agent, so this could basically be anything, 
and I have no idea how to translate a dct:Agent object into a plain 
string, let's just use the Agent's @id then and hope for the best..?"

When you say it lacks a property for allowed values, how should that 
look like? For Literal-like properties, couldn't you do that:

"@context": [
   "http://www.w3.org/ns/hydra/core",
   {
     "owl": "http://www.w3.org/2002/07/owl#",
     "DataRange": "owl:DataRange",
     "oneOf": {"@id": "owl:oneOf", "@container": "@list"}
   }
],
...

"mappings": [{
   "type": "IriTemplateMapping",
   "variable": "var",
   "property": {
     "@id": "vocab:myliteral",
     "range": {
       "@type": "DataRange",
       "oneOf": ["first", "second"]
     }
   }
}]

But maybe I'm mixing up concepts here, since this only works for 
rdfs:Literal, and even then I would like to assign more meaning to each 
of the possible oneOf strings.

> 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?
>
Well, forget foaf:name, let's think about someone creating an API and he 
somehow needs multiple values and he wants the clients to recognize the 
specific multi-valued variable somehow. So, he might say, ok let's name 
the property myvocab:listOfPeopleIds which has a range of rdfs:List and 
then clients that recognize that property will know that they should put 
the rdf list of people IDs into the given template variable. But again, 
maybe I overthink this way too far. Maybe the role of the property is 
not as important as I thought it is, and it may not be about 
transforming RDF graphs into plain strings, but rather about associating 
the variable to a known concept, which in the end would mean that the 
client always needs custom logic for constructing the variable values 
for each mapping/property.

Some clarifications on the whole concept would be very welcome.

> 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.
>
Ok, fair enough.

Cheers
Maik