RE: Reconsidering template mappings

On 17 Jul 2014 at 11:46, Tomasz Pluskiewicz wrote:
> On Thu, Jul 17, 2014 at 10:32 AM, Ruben Verborgh wrote:
>> On 16 Jul 2014 at 21:25, Tomasz Pluskiewicz wrote:
>>>  But what does it mean that it maps a variable to a
>>> property? Andreas wrote on GitHub "My view: The IRI of the foaf:maker
>>> is the value which should be passed.". So there is a property
>>> foaf:maker and it's value will be passed as the parameter. But
>>> property of what subject?
>> 
>> We had a long discussion about exactly that in the context of #30:

Right. I think this question can't be answered in general but depends on what you use the IriTemplate for. Thus, we need to look at specific usages of IRI templates and define the semantics for those cases. ISSUE-45 [1], e.g., does this for filtering collections. The semantics are defined for the proposed property hydra:filter.


>>>> The thing here is that the subject of the triple is not defined yet.
>>>> 
>>>> Basically, we have the choice between:
>>>> a) the subjects are the elements of the collection ("Actor")
>>>> b) the subjects are "related" to the elements of the collection ("Movie starring actor")
>>>> Clearly, a) is most strictly defined;
>>>> and b) is so loosely defined that we basically cannot infer anything.
>> 
>> — http://lists.w3.org/Archives/Public/public-hydra/2014Feb/0120.html

Exactly, this lead to ISSUE-45.


> I'm sorry if I'm digging out a closed topic here, but I'd like to
> understand your understanding of the template mappings.

This is not a closed topic. We are just trying to tackle the problem step by step.


> As an API publisher I would probably want the above query to mean
> "give me actors which are male". In SPARQL fo instance the relevant
> pattern would be "?actor :gender {gender}", where {gender} is the
> value supplied by the client. In such POV the property is already
> defined (:gender) and the client supplies _values_ to search for.
> Hence my suggestion that mapping should map to types and somehow give
> the client ways to select them.

I'm including your earlier example here to show why I'm not convinced about using types:

>>> {
>>>   "template": "http://api.example.com/issues{?author,topic,maxAge}",
>>>   "mappings": [
>>>     {
>>>       "variable": "author",
>>>       "type": "foaf:Agent"
>>>     },
>>>     {
>>>       "variable": "topic",
>>>       "type": "hydra:FreetextQuery"
>>>     },
>>>     {
>>>       "variable": "maxAge",
>>>       "type": "xsd:gDay"
>>>     }
>>>   ]
>>> }
>>> 
>>> This way it is clear that topic is any string, maxAge is a duration
>>> declared in days and author is an IRI of a foaf:Agent

How could a client possible figure out that xsd:gDay is used to specify the agent's age? It could also be the time since its first kiss. Just replace all variables with meaningless tokens such as "dlskj" and you'll see that it becomes impossible to understand what the template is about.


> Also I got the impression that there is the assumption that templated
> links would only be given in context of a related representation.
> Let's consider once again a templated link to search for issues
> created by a given user. Such a templated link could be attached to
> the representation of an entry point. It is also how the UI is
> commonly build. The dashboard gives the user various ways to directly
> execute common actions.
> 
> {
>   "template": "/issues{?author}",
>   "mappings": [
>     {
>       "variable": "author",
>       "property": "ex:author"
>     }
>   ]
> }
> 
> Because the representation is an entrypoint, there is nowhere to look
> for the ex:author property. Similarily a representation of must not
> always include this property. Would this link be inaccessible in that
> case, because the client is unable to choose a value for the template
> parameter?

Why not do it as follows:

  {
    "@id": "/"
    "collection": {
      "@id": "/issues"  ,
      "manages": {
        "property": "rdf:type",
        "object": "Issue"
      },
      "filter": {
        "template": "/issues{?author}",
        "mappings": [
          {
            "variable": "author",
            "property": "ex:author"
          }
        ]
      }
    }
  }

This would give the client all information it needs IMO.


[1] https://github.com/HydraCG/Specifications/issues/45


--
Markus Lanthaler
@markuslanthaler

Received on Monday, 21 July 2014 18:50:28 UTC