- From: Markus Lanthaler <markus.lanthaler@gmx.net>
- Date: Fri, 11 Oct 2013 18:37:35 +0200
- To: <public-hydra@w3.org>
On Friday, October 11, 2013 12:20 PM, Thomas Hoppe wrote: > here is some more feedback and questions: Much appreciated! > 1.) I have been working with the spec now for a while and I > first I could not really use the figure "The Hydra core vocabulary" > in a sensible manner but after having understood the concepts it > is very useful as a shore reference. I'm not too happy with it either but couldn't come up with a better illustration so far. Maybe someone has an idea how to improve this. > 2.) In the SPEC the "supportedClasses" property defines a range > "hydra:Class". I wounder whether it is sensible to set a classes > resource like this: > "supportedProperties": "https://api.ex.com/classes/" I assume you meant supportedClasses in both cases, right? > which would dereference to a collection like this: > > { > "@context": "http://purl.org/hydra/core/context.jsonld", > "@id": "https://api.ex.com/classes/", > "@type": "Collection", > "members": [ > { > "@id": "person" > }, > { > "@id": "user" > }, > ... > ] > } > > A hydra collection is also a hydra:Class according to the spec (although not > explicitly stated in the figure), so syntactically this should be correct > but what about the semantics? It is valid but doesn't represent the information you really want to express. You are introducing another layer of indirection and there's no way to distinguish what is meant without additional information. Furthermore, in the example above api.ex.com/classes is not a class but an instance of type Collection. > The reason for doing this is that I would like > to have the supported classes being proper API resources as well. You mean resources with their own URLs? You can of course do that. Just link to them accordingly: { ... "supportedClasses": [ { "@id": "/classes/Person" }, { "@id": "/classes/User" }, ... ] ] > 3.) I really don't get the point about the "entrypoint" property. What is > the semantics behind it? So far I consider it useless as it does not > contribute to the URI resolution (which was the only thing I could think of) > -- everything required for this is already specified here [1] I think. I will respond to this in a minute in the other thread. -- Markus Lanthaler @markuslanthaler
Received on Friday, 11 October 2013 16:38:10 UTC