MP> oslc_avail:memberOf TF> What would you think about introducing both directions,
(relatively recent) Core linking guidance discourages it. As soon as you have 2 copies, they can get out of sync and other ugly consequences arise. See my reply in thread 1. TF> But to be honest this "but this is not necessarily the case" is one thing I don't get about OSLC. I mean wouldn't it be nice as someone who implements a client for the Avail Spec, to be able to trust that the resource behind this link will be a specific type? It's called the Open World assumption, from W3C Linked Data (i.e. OSLC did not come up with or name it AFAIK). It's the way the Web works - client makes a GET request, it gets a response, but there is no guarantee that it understands the format of any response body ... even if its GET said Accept: application/rdf+xml and it got a 200 response, it has to look at the response's content type to know IF it got RDF/XML (and the server is allowed to send literally anything, so it might not be). Robust clients have to care about that and code for it. Non-robust clients can make assumptions and skip the extra code, and those assumptions can be wrong. All fine. The consequences are that robust clients are more complicated, interoperability is not "guaranteed" by spec compliance (although in truth, is it ever *really* guaranteed if you're talking about specs with anything other that MUSTs/MUST NOTs??), and that new/improved "things" can be freely deployed. If you're brilliant and come up with HTML5, you can serve it. If (as a server) you care about wide interop with existing clients, then you might serve it only in certain cases based on requests from the client. If (as a server) you're the hot new app with zero existing clients to worry about, you can serve HTML5 only. You choose, not the spec authors. None of this *prevents* you (as a client) from saying that you'll only function with servers that DO adhere to the assumptions rendered explicit in the specs. Nor does it prevent servers (or server authors as a group, in some vocabulary OSLC or other) from exposing a signal to clients explicitly SAYING that you meet all those assumptions, in order to give "clients with assumptions" an easy way to figure out if they want to play with your implementation or not. The net reason for putting the burden on clients to deal with anything is future extensibility. RDF itself is pretty extensible, so there might be a reasonable-sounding argument that if you're using RDF (which OSLC 2.0 assumes in Most but not All cases ... look at compact-xml) then you can just multi-type and you're done. That imposes a burden on the servers however, that not all server owners like. Best Regards, John Voice US 845-435-9470 BluePages Cloud and Smarter Infrastructure OSLC Lead
