Re: More Feedback and Questions

On 10/11/2013 06:37 PM, Markus Lanthaler wrote:
> 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.
Remove it or leave it :)
>
>> 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?
Yes
>
>> 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.
Yes, the fact that the resource is a collection and not a class lead me 
to ask this question.
>
>
>> 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" },
>      ...
>    ]
> ]
That's clear but as I wanted to prevent listing them all and instead
reference to a collection of resources but if you say this would break
the semantics then there is no alternative than enumerating them all.
>
>> 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 18:17:32 UTC