URI templates with vars

[Mikel Egaña Aranguren]

Hi;

The configuration I'm using for my Elda experiments is based on a describeViewer:

spec:describe a api:ItemEndpoint

    ; api:uriTemplate     "/id/medio-ambiente/calidad-del-aire/elemento/{medicion}"

    ; rdfs:comment        "A generic item endpoint API for asking about a specific thing by 'uri'."

    ; api:itemTemplate    "http://opendata.euskadi.eus/id/medio-ambiente/calidad-del-aire/elemento/{medicion}"

    ; api:viewer          api:describeViewer

    ; api:defaultViewer   api:describeViewer

    .

that works fine, mapping the URI template to the item template through the {medicion} variable at the end of the path, resulting in the following mapping, for example:

http://localhost:8080/elda-common/id/medio-ambiente/calidad-del-aire/elemento/CO-2017-01-02

http://opendata.euskadi.eus/id/medio-ambiente/calidad-del-aire/elemento/CO-2017-01-02

However, even if I the URIs of my data follow a known pattern, such pattern includes vars within the path of the URI and there are lots of combinations, so I would need a more general mechanism to map URIs, a mechanism capable of including vars in the path of the URI:

spec:describe a api:ItemEndpoint

    ; api:uriTemplate     "/id/{sector}/{dominio}/{clase}/{identificador}"

    ; rdfs:comment        "A generic item endpoint API for asking about a specific thing by 'uri'."

    ; api:itemTemplate    "http://opendata.euskadi.eus/id/{sector}/{dominio}/{clase}/{identificador}"

    ; api:viewer          api:describeViewer

    ; api:defaultViewer   api:describeViewer

    .

This doesn't work, and it shouldn't, since according to the documentation, URI templates only hold vars in the last segment of the path (http://epimorphics.github.io/elda/current/cribsheet.html):

any endpoint

api:uriTemplate

"/path/with/{var}"

This endpoint is invoked when the URI path matches the template. The variable var is bound to the last segment of the path.

Is there an alternative mechanism to achieve the same result? 

Thanks

Regards

[Stuart Williams]

That's an example, not a universal restriction. You can have variables in other path segments.

However, take care. Think of each of those {varname} segments being replaced with a .* regex. It is very easy to write multiple pattern with different variable names and not spot that they capture the same URI. You need enough 'hard' coding in the templates so as to ensure that a given inbound URI matches as given template. BTW most specific match wins.

Is there an alternative mechanism to achieve the same result? 

Thanks

Regards

HTH

Stuart

--
You received this message because you are subscribed to the Google Groups "linked-data-api-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linked-data-api-d...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

-- 
Epimorphics Ltd                        www.epimorphics.com 
Court Lodge, 105 High Street, Portishead, Bristol BS20 6PT
Tel: 01275 399069

Epimorphics Ltd. is a limited company registered in England (number 7016688)
Registered address: Court Lodge, 105 High Street, Portishead, Bristol BS20 6PT, UK

[Mikel Egaña Aranguren]

In that case, why would my config fail? I'm using the same mapping that works with only mapping the last segment, but it doesn't work if the variables are used in the inner part of the URI:

    ; api:uriTemplate     "/id/{sector}/{dominio}/{clase}/{identificador}"

    ; api:itemTemplate    "http://opendata.euskadi.eus/id/{sector}/{dominio}/{clase}/{identificador}"

However, take care. Think of each of those {varname} segments being replaced with a .* regex. It is very easy to write multiple pattern with different variable names and not spot that they capture the same URI. You need enough 'hard' coding in the templates so as to ensure that a given inbound URI matches as given template. BTW most specific match wins.

Thanks

Regards

 

Is there an alternative mechanism to achieve the same result? 

Thanks

Regards

HTH

Stuart

--
You received this message because you are subscribed to the Google Groups "linked-data-api-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to linked-data-api-discuss+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Stuart Williams]

I don't know!

However, it is the case that you can have multiple variable segments in a uriTemplate and and itemTemplate. Indeed with elda (though not all LDA implementations) you can have multiple variables within a single segment provided there is enough hard text to give an unambigous partition of the segment eg:
".../{prefix}-{suffix}/..." ie. the '-' anchors which parts the are captured by {prefix} and {suffix}.

 

I'm using the same mapping that works with only mapping the last segment, but it doesn't work if the variables are used in the inner part of the URI:

    ; api:uriTemplate     "/id/{sector}/{dominio}/{clase}/{identificador}"

    ; api:itemTemplate    "http://opendata.euskadi.eus/id/{sector}/{dominio}/{clase}/{identificador}"

Possible problems arise if any of your variable names match any of your configured shortnames. I don't recall the details of why that can lead to problems - but its best not to mix them in my experience. Chris may be able to remind me/us.

 

However, take care. Think of each of those {varname} segments being replaced with a .* regex. It is very easy to write multiple pattern with different variable names and not spot that they capture the same URI. You need enough 'hard' coding in the templates so as to ensure that a given inbound URI matches as given template. BTW most specific match wins.

Thanks

Regards

 

Stuart

[Mikel Egaña Aranguren]

It does work with the following config:

spec:describe a api:ItemEndpoint

; rdfs:label  "GET Resource" 

; rdfs:comment        "A generic item endpoint API for asking about a specific thing by 'uri'."

; api:uriTemplate     "/id/{sector}/{dominio}/{clase}/{identificador}"

; api:variable [api:name "uriITEM"; api:value "http://opendata.euskadi.eus/id/{sector}/{dominio}/{clase}/{identificador}"]

; api:selector [

   api:select """

select distinct ?item where{

?item ?p ?o .

FILTER (?item = IRI(?uriITEM)) .

}

""" ;

] ;

.

Thanks

Regards

 

 

However, take care. Think of each of those {varname} segments being replaced with a .* regex. It is very easy to write multiple pattern with different variable names and not spot that they capture the same URI. You need enough 'hard' coding in the templates so as to ensure that a given inbound URI matches as given template. BTW most specific match wins.

Thanks

Regards

 

Stuart

-- 
Epimorphics Ltd                        www.epimorphics.com 
Court Lodge, 105 High Street, Portishead, Bristol BS20 6PT
Tel: 01275 399069

Epimorphics Ltd. is a limited company registered in England (number 7016688)
Registered address: Court Lodge, 105 High Street, Portishead, Bristol BS20 6PT, UK

--

Mikel Egaña Aranguren, Ph.D.

https://mikel-egana-aranguren.github.io

[Stuart Williams]

I guess that's good, but nevertheless it should work more simply with an `api:itemTemplate` as you initially used.

Beware of  `api:select` I don't think it plays nice with other selector. `api:where` is often better. wrt to the body of the query, rather than FILTER it can be more efficient with SPARQL 1.1 to use VALUEs

    select ?item where {
       values ?item { IRI(?uriITEM) }

      ?item ?p ?o .
    }

I trust that you can see that this query is not very interesting since elda substitutes ?urlITEM for its value, so the answer to the query is written directly into the question - so there's really no point in the whole round-trip query execution for the ELDA's select query. This really is what `api:itemTemplate` is for.

As to why that didn't seem to work for you... I'd need a better description of what 'not working' means - and ideally some capture of any logging that you can get from elda (not the response page, but the log stream). You can also use 'log4j.properties' to turn on more detailed logging which may also reveal more of what isn't working. And if that doesn't crack it... firing up in a debugger is an option since you've managed to build it locally.

 

 

 

However, take care. Think of each of those {varname} segments being replaced with a .* regex. It is very easy to write multiple pattern with different variable names and not spot that they capture the same URI. You need enough 'hard' coding in the templates so as to ensure that a given inbound URI matches as given template. BTW most specific match wins.

Thanks

Regards

 

Stuart

-- 
Epimorphics Ltd                        www.epimorphics.com 
Court Lodge, 105 High Street, Portishead, Bristol BS20 6PT
Tel: 01275 399069

Epimorphics Ltd. is a limited company registered in England (number 7016688)
Registered address: Court Lodge, 105 High Street, Portishead, Bristol BS20 6PT, UK

--

Mikel Egaña Aranguren, Ph.D.

https://mikel-egana-aranguren.github.io

BR

[chris dollin]

On 9 May 2017 at 18:48, Stuart Williams <s...@epimorphics.com> wrote:

Beware of  `api:select` I don't think it plays nice with other selector.

If you specify an api:select (or equivalently _select=) then it's the

/complete/ query and other selectors are ignored (or cause an

error).

The only processing that's done on that query is replacing

variables ?whatever with their value if they have one, eg

from pattern-matching in the URI or from api variables.

 Chris

--

Chris "allusive" Dollin