I have had some offline discussions about my Read Write RDF Hypermedia proposal (please let me know if you’d like to be named), and there are some things that I’d like to elaborate on.
There is clearly a need to contrast my proposal with other technologies out there, and make it clearer where this makes sense.
Initially, I developed this with the ideal of making the RDF control statements look somewhat like natural language sentences, that is, if you as a client is authorized to delete a resource description, the RDF should tell you that in terms that are likely understood by someone who has never seen RDF before. Developers might just look at what they get from a server and start to work with it. After discussing it, I think it might have another advantage: It seems to me that we will have a lot of different protocols on different levels in the stack, and that this protocol heterogeneity could be addressed in part by moving controls into the body of the message. Lets discuss that first.
Protocol Heterogeneity
HTTP has served us well, and will continue to do so. Nevertheless, it seems to me that with “Internet of Things” (IoT), we will develop a “last mile” problem, in which we cannot or do not want to control what application layer protocol to use. I haven’t done a lot of work in this space, but it seems very diverse. Obviously, if you can use a Wifi protocol, HTTP will available to you. I did some work with an Arduino (which is a microcontroller with very little RAM), where I found that the best choice to interact with it for my application to add an Ethernet shield and use HTTP. In other cases, it probably wouldn’t be. Some protocols are maintaining layered model, and some, like Zigbee, has gained an IP layer. Others, like DASH7, touches every layer in the OSI stack. In the latter case, it is mostly easy to map HTTP methods into operations on DASH7 devices, but the point here is that there is a whole zoo of protocols, some of which would need a mapping, some of which have an IP layer, but where you do not want to be tied to an application protocol for some reason. That is not to say that HTTP will not be the application protocol used on the open Web, but that there are endpoints that should be free to choose their protocol for interacting with their internals.
If the semantics of control operations sits in HTTP the translation may become unnecessarily complex, and so feel restrictive to implementors. That’s one of the reasons I would prefer to have controls in the message body.
But it also implies that the controls should be as precise as possible. For example, I proposed
</test/08/data> hm:canBe hm:mergedInto .and not that we encode POST as an operation. POST is not precise enough, but we should define the in vocabulary that for the HTTP protocol, hm:mergedInto would be implemented with a POST.
Finally, it should be noted that such controls should be defined for protocols that use very different operations. I have for example proposed similar controls for video:
<rtsp://camhost1.orienteering.org/stream> a dcmit:MovingImage ; hm:can hm:play, hm:pause, hm:stop .
I also proposed more detailed more application-specific controls, like
<rtsp://camhost2.orienteering.org/stream> a dcmit:MovingImage ; hm:canBe hma:votedFor ; rev:hasReview </user/foo/vote/1>, </user/bar/vote/56> .
where the definition of hma:votedFor might be a fairly complex, possibly defined in terms of other controls, I haven’t thought that far yet.
Contrasting With Other Efforts
There are several other vocabularies and protocols that are in the same space. None, as far as I know, take the same starting point: That controls should look and feel like natural language sentences. I think that is the most important point, that is the key enabler of making “View Source” development feasible for newcomers.
There are, however, in-band hypermedia controls to define allowed operations in RDF in the Hydra specification. However, Hydra doesn’t read like natural sentences, its appeal is more towards those who already know RDF. Moreover, it isn’t inclined to define precise controls, like hm:mergedInto, it allows you to formulate which operations to do, and then hydra:method is explicitly a HTTP method. As argued above, this may create a gap on the last mile, as the semantics becomes unclear further down the stack and it would require more work mapping between various protocols.
Then, there’s the Web Access Control (WAC) spec. On the surface, my proposal seems like a replacement for that, but that’s not intended, to the contrary, I see these as complimentary. In fact, when I first started my implementation, the first thing I did was to use the predecessor of this spec as well as WebID+TLS to create the authentication and authorization framework. I later removed that code to focus on the hypermedia aspects, but I still think WAC is the right way to specify the authorization rules. The WAC should be exposed so that clients that prefer to gain an instant overview of the application they are interacting with, but I think that many users will find it much easier to understand a nearly-natural language sentence that tells them exactly what they can do to the resource they are presently interacting with.
I guess I should have taken the complimentary perspective with Linked Data Platform as well. So far, I’ve been of the opinion that LDP should be superseded by hypermedia. My main point of criticism has been that LDP doesn’t have the right primitives, i.e. LDP’s primitives need to be understood in terms of HTTP, but that means a newcomer has to have incentives to read up. I think they need to have the “hey, I can do this”-experience first. The message and tools have to provide that. Then comes the argument from above that the emergent IoT-induced protocol heterogeneity problem could require us to formulate controls in message bodies.
That said, it is also pretty clear that my hypermedia proposal could be formulated to only add some RDF to resource descriptions, and thereby augment rather than replace LDP. So, I hereby apologize for my attacks on LDP, lets go complimentary.
Is the Controls Resource Needed?
In my first post, I argued that in the case where we expose a resource for reads for unauthenticated clients, but require authentication and authorization for writes, we need a separate resource to challenge the client. I admit that this is suboptimal, but I don’t see a lot of good alternatives. One alternative that was proposed to me is to add hypermedia controls to the response to an unauthenticated client as it is not the controls that require auth* but the right to use them. I feel that would be more confusing, as even an authenticated user may not be authorized to use certain controls, and so, a client may authenticate and then see certain controls disappear because they are not authorized to use them.
At this point, I think that implementation experience is needed to find the best approach, and importantly, study how inexperienced but enthusiastic implementors interact with resources.