Dear Patrick and all,
Am 27.09.2011 um 00:47 schrieb Patrick Logan: > >> The distinction is impractical, especially if you compare it >> with the simplicity of the alternative JSON-based Open Graph >> representation. > > That may be a matter of one's experience and what one wishes to > do with the result. I say it as someone who has considerably more experience in Semantic Web technologies than in JSON and all the emerging NoSQL databases. > >> - I ask for http://graph.facebook.com/sebastian.schaffert and I get >> http://graph.facebook.com/561666514# >> - I ask for http://graph.facebook.com/561666514 and I get >> http://graph.facebook.com/561666514# >> - I ask for http://graph.facebook.com/561666514# and I get 404. > > Curious. I do not get a 404 for that last one. Because the browser (according to the standard) removes the trailing "#". But if you send a GET request manually (telnet etc) and including the # you will get a 404. > Anyway, the URL in each case is asking for data. If that data > happens to be a graph that contains the URI > http://graph.facebook.com/561666514# so what? I am not > understanding why you are disappointed in that. I am disappointed because I asked for data about http://graph.facebook.com/561666514 and got back data about http://graph.facebook.com/561666514# - this is my main concern. Maybe I should ask for http://graph.facebook.com/561666514# in the first place and manually remove the trailing "#" like a browser does. But I prefer a predictable, well-defined, and universal (over all LD services) behaviour. > >> I have no simple generic way of deciding how what I requested >> relates to what I get back. Of course I could do it >> specifically for the FB Linked Data service, but then it would >> not work for other LD services. > > At this stage of the web, humans are still involved to help find > and establish effective conventions and standards. This service > was announced with a human-readable description. Hopefully as the > service is used, and other similar services, then they will > become even more useful in combination. > > My sense is that will take some time, so you work with what you > have now and go forward. You are of course right. But we also have to take into account that we are trying to demonstrate a hypothesis, namely that Semantic Web technologies are better in helping us solve interoperability and data exchange problems. For this, it has to work better than what exists. > >> Maybe I misunderstood the interoperability vision of Linked >> Data. But if I have to follow different service descriptions >> for different services, I can also stick with RESTful services >> and JSON. The whole point of Linked Data for me would be to be >> more independent from the different service descriptions and be >> able to follow a standardised, well-defined procedure for >> getting data. > > REST is a description of useful ways to transfer data. > > JSON is a description of a simple format for transferring data. > > Linked Data is neither of those. But those can be used to provide > linked data. > > I am not sure what argument you are trying to make by saying "I > can stick with REST and JSON" because you can provide and use > linked data with or without REST and JSON. Ok, let me be a bit more precise: I can stick with REST, JSON, and human readable service descriptions for each service that define for me how to call the REST webservice and how the JSON (or whatever) data that comes back will look like. But Linked Data could do better: there could be a uniform way of accessing the data and a unified contract about what comes back. Greetings, Sebastian -- | Dr. Sebastian Schaffert sebastian.schaff...@salzburgresearch.at | Salzburg Research Forschungsgesellschaft http://www.salzburgresearch.at | Head of Knowledge and Media Technologies Group +43 662 2288 423 | Jakob-Haringer Strasse 5/II | A-5020 Salzburg
