Re: What is the correct media-type for a Hydra specification?

hello dietrich.

On 2015-04-19 01:59, Dietrich Schulten wrote:
>> On 2015-04-18 11:03, Dietrich Schulten wrote:
>> thanks, that's exactly the point i am trying to make. if the media type
>> only signals the metamodel (and maybe the serialization of it, but
>> that's a different issue), but the represented domain model is hidden
>> from the uniform interface, you lose the ability to talk about it.
>> that's unfortunate, and the main reason why REST asks for resources to
>> be self-describing. and that means in terms of domain models in the
>> uniform interface, so that interactions can be built around exposing
>> those, and acting on them.
> Although, we need to consider well what it means to say
>
> Accept: application/ld+json; profile="<a hydra identifier>".
>
> Clearly this should not preclude usage of other vocabularies. If the
> profile identifier is the hydra prefix, it would be easy to mistake the
> profile as an expectation to use that vocab and not use others. I want
> to say: use hydra constructs for interaction and collection
> descriptions, for everything else do what you want.

that's fine, and actually exactly the idea of profiles. if you ask for a 
web page with embedded vCard (using a profile identifier when requesting 
HTML), then there is nothing preventing that page from using other 
profiles as well. in fact, there is no way you can ask for *only* vCard.

to me, that's the beauty of profiles. it allows to communicate 
expectations withing the scope of a media type, without disallowing a 
generic (or alternative-profile) view of that media type. that of course 
only works as long as multiple profiles are not incompatible with each 
other, but i would assume that this is the exception more than the norm.

> I found that schema.org just recently designed their own all-purpose
> ordered collection type (http://schema.org/ItemList). And they have
> schema:potentialAction, which is designed quite differently from
> hydra:operation. That is exactly the sort of thing I would like to make
> negotiable: do I want hydra:operation or schema:potentialAction or LDP
> OPTIONS to describe interactions, and do I want hydra:Collection or
> schema:ItemList or ldp:DirectContainer/BasicContainer/IndirectContainer
> for containers?

that sounds like a good use case to explore profiles. you could also 
imagine that a server is embedding all of them at once (if that's 
something that's possible), but that should be up to the server, and 
maybe generally speaking, that's rather noisy and redundant and 
something that can be easily avoided if the uniform interface has a way 
to communicate information about those alternatives.

> If so, which profile value would express that collections and
> interactions should be expressed in terms of hydra?
> Maybe "http://www.w3.org/ns/hydra/core#Resource"?

that really is just a matter of definition. personally, i would be in 
favor of non-fragment URIs, but that's just me being a minimalist. it is 
whatever the spec says. in the end, it's just a name, and the only thing 
that matters that it is well-defined by the spec, so that people don't 
start using different URIs.

cheers,

dret.

erik wilde | mailto:dret@berkeley.edu  -  tel:+1-510-2061079 |
            | UC Berkeley  -  School of Information (ISchool) |
            | http://dret.net/netdret http://twitter.com/dret |

Received on Sunday, 19 April 2015 15:33:13 UTC