Re: query language

Pardon me for jumping here but...

I think it's important to separate runtime affordances from design/build
time descriptions. I think both are very important but server different
purposes and address different challenges.

it seems in this discussion we are wandering back and forth between ru
at runtime, i want a response that includes detailed instructions on what
is available *at this point in time for this authentication context*
including protocol details (methods, URLs, arguments, formats) and
app-level details (domain-specific names, action verbs, etc.)

at design/build time i am looking for information (preferably in
machine-readable form) that describes all the possible actions and data
elements (functions/objects/resources/structures -- whatever you like to
focus upon) along with the protocol-level details needed to properly
implement the service being described.

FWIW, i look for slightly different details depending on whether i am the
service provider (i need to know how to validate incoming data, map message
to business implementation, storage, etc.) or the service consumer (i need
to know all the possible formats i must understand, the full range of
ontologies/vocabularies i might run into, and all the possible protocols i
need to understand).

Hopefully this detour in the convo makes sense ;)

Cheers.

mamund
+1.859.757.1449
skype: mca.amundsen
http://amundsen.com/blog/
http://twitter.com/mamund
https <https://github.com/mamund>:// <https://github.com/mamund>github.com
<https://github.com/mamund>/mamund <https://github.com/mamund>
http:// <http://linkedin.com/in/mamund>linkedin.com
<http://linkedin.com/in/mamund>/in/mamund <http://linkedin.com/in/mamund>

hello ruben.

On 2014-09-10, 9:21 , Ruben Verborgh wrote:

> Here is an equivalent Hydra example:
> {
>    "@context": "http://www.w3.org/ns/hydra/context.jsonld",
>    "@type": "IriTemplate",
>    "template": "http://api.example.com/issues{?page}",
>    "mapping": [
>      {
>        "@type": "IriTemplateMapping",
>        "variable": "page",
>        "property": "http://example.com/feedpaging/page",
>      }
>    ]
> }
> This is very similar to what Link Descriptions do, right?
>

it's a part of what they do, but less. and please keep in mind that the
draft that's published is very rough and incomplete, so some of what i am
saying is just what we wanted to do with the descriptions, but has not
necessarily found its way into the draft.

what link descriptions also are supposed to do is to describe data types
and value ranges. for example, when you have a page variable, then you want
to represent the fact that it's integer, and the allowed value range. from
what i can see, hydra does not support this kind of information, which,
like you say, is going in the direction of forms (not the UI part, but the
logical part).

i guess what hydra *could* do would be (and i am using XSD here because it
conveniently exists as a simple datatype standard on the web, but sadly
defines no URIs to identify its core concepts):

{
  "@context": "http://www.w3.org/ns/hydra/context.jsonld",
  "@type": "IriTemplate",
  "template": "http://api.example.com/issues{?page}",
  "mapping": [
    {
      "@type": "IriTemplateMapping",
      "variable": "page",
      "datatype": "http://www.w3.org/TR/xmlschema-2/#integer",
      "xs:minInclusive": "1",
      "xs:maxInclusive": "42",
      "property": "http://example.com/feedpaging/page",
    }
  ]
}

cheers,

dret.

-- 
erik wilde | mailto:dret@berkeley.edu  -  tel:+1-510-2061079 |
           | UC Berkeley  -  School of Information (ISchool) |
           | http://dret.net/netdret http://twitter.com/dret |