Relation between Hydra classes and RDF classes

Suppose one wanted to use the Hydra vocabulary to describe an API for
managing SKOS concepts and concept schemes. Each concept and each
concept scheme is a dereferenceable resource:

GET http://example.org/scheme/1

ex:scheme/1
    a skos:ConceptScheme ;
    skos:prefLabel "Ice Cream Flavors" .


GET http://example.org/concept/1

ex:concept/1
    a skos:Concept ;
    skos:prefLabel "Chocolate" ;
    skos:inScheme ex:scheme/1 .

In this example, the RDF classes used to model our data are SKOS
classes. But in all the Hydra examples I've seen so far, the Hydra
classes are *not* classes taken from standard vocabularies like SKOS,
but are defined in vocabularies specific to the API. Is this how Hydra
is intended to be used, or is it OK to use arbitrary RDF classes as
Hydra classes? In other words, is there any reason not to have
something like the following in API documentation?

skos:ConceptScheme
    a hydra:Class ;
    hydra:supportedOperation [
        a hydra:Operation ;
        hydra:method "GET" ;
        hydra:returns skos:ConceptScheme
    ], [
        a hydra:ReplaceResourceOperation ;
        hydra:method "PUT" ;
        hydra:expects skos:ConceptScheme ;
        hydra:returns skos:ConceptScheme
    ], [
       a hydra:DeleteResourceOperation ;
       hydra:method "DELETE" ;
       hydra:returns owl:Nothing
    ] ;
    hydra:supportedProperty [
       hydra:property skos:prefLabel ;
       hydra:readable true ;
       hydra:writeable true
    ], [
       hydra:property skos:altLabel ;
       hydra:readable true ;
       hydra:writeable true
    ], [
       hydra:property skos:inScheme ;
       hydra:readable true ;
       hydra:writeable true
    ] .

The only potential problem I can see here is that, by conflating
`skos:ConceptScheme` with the API class, we lose the ability to
describe other resources, which may not be under the control of our
API, as instances of `skos:ConceptScheme`, without implying that those
external resources also support the same operations and properties.

If this is *not* OK, then should we assume that 1) RDF classes for
modeling data and, 2) Hydra classes for modeling resources and their
supported operations and properties, are completely orthogonal, so
that, in this example, we need to define `ex:vocab#ConceptScheme` and
`ex:vocab#Concept` Hydra classes?

Received on Friday, 6 November 2015 21:08:54 UTC