- From: Markus Lanthaler <markus.lanthaler@gmx.net>
- Date: Tue, 21 Apr 2015 22:30:27 +0200
- To: <public-hydra@w3.org>
On 19 Apr 2015 at 01:04, Erik Wilde wrote: > hello markus. > > On 2015-04-18 04:06, Markus Lanthaler wrote: >> On 17 Apr 2015 at 00:48, Erik Wilde wrote: >>> no, it doesn't. hardcoding media types into link relations is an >>> anti-pattern that we should avoid. >> I thought I was clear about this but apparently not clear enough. I'm *not* advocating to > hardcode the media type in the link relation. It is completely fine to use conneg to negotiate > between, e.g., JSON-LD and Turtle (as I explained above) > > i always get tripped ub by the semweb community's special use of media > types, so i should have been more specific. when i say "media type" i am > talking about one that meaningfully exposes the represented data, not > just the metamodel it is represented in. so it should be something where > hydra, hydra++, or non-RDF API decription media types can be > meaningfully labeled. the link relation type should not make any > assumptions about the model type (i.e., hydra or something else) that's > linked to. Fair enough. >>> it's as if HTML had <PNGimg/> and >>> <GIFimg/> and <JPEGimg/> elements, and every time somebody somewhere >>> came up with a new image format, there would be new links. >> Would you also advocate to use conneg to negotiate between HTML, plain text, > OpenDocument, Microsoft Word, ...? > > sure. if you want to implement it that way, why not. you could also have > different URIs, if you prefer, but most importantly, you would not have > link relations for all those media types. > > i'd have link relations saying "here's human-readable documentation", > and then media types that at runtime would determine how the > documentation is represented. that way, you don't need HTMLdocumentation > and plaindocumentation and ODFdocumentation and WordDocumentation link > relation. that's something that would be bad practice. > > come to think of it, maybe we should whip up an I-D for these two > relations: human-readable and machine-readable documentation. both > aren't yet registered, and would be nice to have in many APIs. and i > would strongly advocate for making those media-type independent. Following your train of thought why two and not a single one? Shouldn't the media type define whether it is machine-readable or not? -- Markus Lanthaler @markuslanthaler
Received on Tuesday, 21 April 2015 20:30:56 UTC