[Specifications] Way for API to announce any extensions they use in addition to Hydra Core (#221)

tpluscode has just created a new issue for https://github.com/HydraCG/Specifications:

== Way for API to announce any extensions they use in addition to Hydra Core ==
Introduce hydra vocabulary profiles or levels, i.e. level 0 and 1 where level 1 would be a default current hydra version and level 0 would be an alternative that does not imply a hydra:Resource is de-referencable (or event RDF based). This could also enable hydra for future profiles/levels using external schema vocabularies like SCHAL, OWL and non-rdf based ones.
---

The third point however I find rather orthogonal. I'm not sure the "profiles" have anything to do with dereferencability of the API descriptions. More about the requirements from the client. I would see this as an open-ended set of "feature-packs" that a server may implement in addition to core. Here are some ideas:

1. Hydra Core
   * Only the base terms to put an API together
2. Standard Profile
   * hydra:Class
2. SHACL profile
   * Shapes for `expects`/`returns`
   * maybe also `supportedClass`
3. JSON Schema profile
   * like SHACL, uses a different vehicle to describe requests and responses
4. IANA Media types profile
   * Uses IANA-registered media types. for example the snippet below might denote an operation where PNG and JPG are allowed to be uploaded

    ```
    <> hydra:expects 
        <https://www.iana.org/assignments/media-types/image/png> ,
        <https://www.iana.org/assignments/media-types/image/jpeg> ,
    ```
5. Multi-part profile
   * Something we discussed in #199 where an operation is described as expediting a `multipart/form-data` body.
   * Individual parts could then be individually describe using the other profiles. For example to have one part image (IANA profile) and the other a plain RDF resource (Standard profile)

Each profile would be free to define its specific processing rules. 

The required changes would be to:

1. Add an optional property on `ApiDocumentation` to assert which profiles a server uses
2. Relax some `rdfs:range` statements of extension points
2. Move the "Standard Profile" to a separate spec document. Would probably keep

So as effect a server might announce itself as

```turtle
<> a hydra:ApiDocumentation ;
  // SHACL might potential be maintained by Hydra CG
  hydra:profile <http://www.w3.org/ns/hydra/profile#SHACL> ;
  // a vendor-specific profile which somehow bridges Open API
  hydra:profile <http://example.com/hydra-profile#OpenAPI>
```

_Originally posted by @tpluscode in https://github.com/HydraCG/Specifications/issues/216#issuecomment-634486520_

Please view or discuss this issue at https://github.com/HydraCG/Specifications/issues/221 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Tuesday, 8 December 2020 20:03:37 UTC