Use W3C HTTP RDF vocabulary

[asbjornu]

Since there's a HTTP vocabulary for RDF, wouldn't it be wise for Hydra to use it rather than define its own hydra:method and such? I know it's just a working draft, but perhaps Hydra's reliance on it may help nudge it in the right direction?

[tpluscode]

Yup, I've just recently mentioned http vocab under @elf-pavlik's comment in #2.

[elf-pavlik]

I think hydra JSON @context could simply map

{
  "@context": {
    "http": "http://www.w3.org/2011/http#",
    "method": "http:methodName"
  }
}

Whoever works directly with Turtle would will know how to use prefixes and terms from different namespaces.

@asbjornu which other terms from HTTP vocabulary for RDF do you find useful for Hydra?

[asbjornu]

@elf-pavlik, I haven't had a thorough look at it yet, so I'm not sure. But for every term that exists in the HTTP vocabulary, we should rather use that in Hydra than define our own. Whether we use the terms directly referencing the HTTP vocabulary or whether we remap them as you suggest is not that important to me. Either would work fine, I think.

[lanthaler]

We discussed this before.. see e.g. Ruben's mail here: https://lists.w3.org/Archives/Public/public-hydra/2014Jun/0022.html

In my opinion reusing a vocabulary only makes sense if it being (widely) used elsewhere. I haven't seen any usage of the HTTP vocabulary so far and it isn't being maintained anymore. I would thus strongly prefer to keep the control of such a crucial aspect of Hydra within our group.

Btw. you certainly don't want to map the vocab to the http prefix :-)

[tpluscode]

The question is always what's to gain. Upon closer inspection I don't think that HTTP vocab, in it's current form, is actually as useful as I too have initially imagined

[asbjornu]

I agree that the W3C spec in its current form isn't all that useful. But since it's just a draft, can't we attempt to nudge it in a direction that will benefit both Hydra and the web community as a whole?

Having a single, authoritative vocabulary for HTTP would be great and benefit much more than Hydra, and that single authoritative vocabulary shouldn't be Hydra itself, imho.

[elf-pavlik]

At some point I looked at HTTP vocabulary for RDF trying to find a way to describe HTTP redirects and manage them with REST API. I didn't find clear way to do that but I may pick up on this possibility at some point. AFAIK servers usually don't provide API to set HTTP Headers and satus code which resource will respond with. I'll try to see how url shorteners which allow to change where short url redirects to expose it via API.

[tpluscode]

AFAIK servers usually don't provide API to set HTTP Headers and status code

Not that they couldn't. It is something tha the HTTP API could be used for. But it seems very strict in its semantics.

[lanthaler]

I agree that the W3C spec in its current form isn't all that useful. But since it's just a draft, can't we attempt to nudge it in a direction that will benefit both Hydra and the web community as a whole?

Sure, but I guess it's more effective to design a vocab and test it with real-world implementations/use cases within our group instead of trying to revive an effort that died in 2011. We can always split out these things from Hydra into a separate vocab later if we think it's a valuable thing to do.

[asbjornu]

While I agree that we can and should flesh out Hydra's requirements and test them in the real world before moving the HTTP terms to its own vocabulary, I think the friction involved in doing this after Hydra has reached 1.0 REC status is so huge that it's probably not worth it.

With enough implementations, moving to an external vocabulary would amount to a lot of friction as well, but as long as we do it before we reach Recommendation status, it's at least to expect that things change, but after 1.0 REC, we would have to wait for 2.0 REC to do anything about this. Perhaps that's the right course to take -- I don't know. But I would like to attempt making the move before 1.0, if possible.

[alien-mcl]

It seems that using unmaintained vocabulary that would in addition tightly couple hydra to a specific protocol is not a good idea. Hydra is meant to be protocol-agnostic, thus I don't see any option of using such vocabularies in the spec.