- From: Karol Szczepański <karol.szczepanski@gmail.com>
- Date: Sat, 7 Nov 2015 12:31:00 +0100
- To: "Ryan Shaw" <ryanshaw@unc.edu>, "Hydra" <public-hydra@w3.org>
Hi Ryan I think your example is correct - you can raise your skos:ConceptScheme to hydra:Class. My understanding of hydra:Class is that it and instances of that type can be safely dereferenced as a resource, which might not be so obvious with rdfs:Class or owl:Class. That's why hydra:Class is a subclass of hydra:Resource and rdfs:Class simultanously. >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. I think thats how Hydra should work - eveyrhing denoted with that vocabulary should tell the client on some extra possibilities, thus if other resources are not hydra decorated the client can only imply what RDF allows it, i.e. it can try to dereference a resource starting with http://, but there is a high chance that it's pointless (i.e. due to linked data paradigm is not implemented by a given host). With hydra client should be confident that dereferencing it should be possible and the API will do the rest. Best Karol
Received on Saturday, 7 November 2015 11:31:29 UTC