W3C home > Mailing lists > Public > public-hydra@w3.org > November 2015

Re: Relation between Hydra classes and RDF classes

From: Karol Szczepański <karol.szczepanski@gmail.com>
Date: Sat, 7 Nov 2015 12:31:00 +0100
Message-ID: <5C0C2B24FDBA40E58279EAACCA564C55@Alien>
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.


Received on Saturday, 7 November 2015 11:31:29 UTC

This archive was generated by hypermail 2.3.1 : Saturday, 7 November 2015 11:31:29 UTC