related to the
Let's take the constraints of the REST architectural style as figured out here:
Resource Identification is clearly address in point 1 (URIs) and 2 (HTTP URIs) of the Linked Data principles as defined by timbl. However, the explicit suggestion of the use of HTTP URIs is against the REST feature of a uniform generic interface between components ("A REST API should not be dependent on any single communication protocol", see here). Identification is separated from interaction.
Is the common, layered Semantic Web technology stack a implementation of a Uniform Interface re. REST principles? Or is it only HTTP as communication protocol? And what does "The same small set of operations applies to everything" then mean? Do I have to enable an processing of every operation on every (information) resource? Or does this mean, that I only have to provide a uniform behaviour of processing of operations on (information) resource, e.g., if a specific operation is not possible or allow on a specific resource, then the component has to communicate this in a uniform way?
This is in accord with my last statement.
Side note: I know, there is some progress in providing media type specification as resources with a URI. However, as far as I know, their resource URIs lack of a good machine-processable, dereferencable specification description, e.g., the lack of a machine-processable HTML specification that enables a machine agent to know that "the anchor elements with an href attribute create a hypertext link that, when selected, invokes a retrieval request (GET)" (this issue is derived from community statement and is not really verified, however, I currently would agree with it ;) ; please correct me, if this assertion is wrong). All in all, an agent must be able to automatically learn the processing model of a previously unknown media type, if wanted (analogues the HTTP Upgrade header field). I know, that there is some progress (discussion) in the TAG community re. a better introduction of new media types.
Self-Describing Messages are enforced for machine processing by using as basis the common knowledge representation languages of the Semantic Web (i.e. RDF Model, RDF Schema, OWL, RIF) and all knowledge representation languages (incl. further Semantic Web ontologies) are referenced in this 'message'. This is somehow generalized in the third Linked Data principls as defined by timbl ("provide useful information, using the standards").
The forth Linked Data principle as defined by timbl ("Include links to other URIs
") is somehow related to Hypermedia Driven Application State of the REST principles. This principle can again be powered for better machine processing by using the common knowledge representation languages of the Semantic Web as basis. However, I'm a bit unclear how the links drive my application state. Nevertheless, I guess that the application state would change when navigating to a resource by dereferencing a link (HTTP URI).
Stateless Interaction is not really covered by the Linked Data principles as defined by timbl, or? Albeit, when realizing "state as a resource" (cf. here), I can use again the common knowledge representation languages of the Semantic Web as basis for describing states and using HTTP URIs to make these resources also accessible.
Would you agree with (parts of) my interpretation?
Source, where this topic is also discussed somehow:
Two points for you to consider:
answered 24 Jan '11, 16:03
Rob Vesse ♦
Concerning read-only - for Linked Data currently found in the wild, yes, this is the case, but people are working on solutions for a write-enabled Linked Data Web. Rob already mentioned SPARQL as one of the key components, for the big picture see Realizing a write-enabled Web of Data. In fact, we're now launching the WebID Incubator Group at W3C, another pivotal piece in the overall puzzle re a full-fledged write-enabled Web of Linked Data.
answered 25 Jan '11, 09:02
Here is another approach, which differs from the mainstream REST vs RDF interpretation.
What if we have a domain model, relying on RDF, split it into domain objects and expose subset of triples, describing each object via REST interface? And allow writing /updating triples back via REST interface ? And also allowing to generate new triples, by launching calculations, that create new REST resources and new triples.
And consider using SPARQL on the client side of REST :) The implementation of the server side is not restricted to be a SPARQL endpoint, or even implemented as triple storage. It just needs to offer RDF serialization of resources, instead/or in addition to XML, microformats and HTML.
Then we can use conventional technologies for implementing read/write REST services, but expose objects via their RDF representation, and link to the big LOD cloud, when necessary. If the LOD cloud finds its useful at certain point, it is trivial to retrieve the RDF representations of these REST resources, in a similar way search engines gather their information, rather than compiling the LOD cloud manually.
This answer is marked "community wiki".
Unfortunately there is also a problem with large queries that has led to the SPARQL standard advocating the use of a POST where you should be using a GET.
answered 03 Feb '11, 19:21
I think Data Wikis are exciting, but I think many Linked Data publishers have a distinct point-of-view, and that's a good thing.
Have you ever heard of a game called "Association Football?"
You know the game, but you probably don't know that name. I like watching the World Cup and I've coached soccer for kids but until I became a semantician I never knew that, according to Wikipedia and Freebase, the game that many people call soccer or football (or some derivative of football) is officially called "Association Football."
Some political decision was made to call it that on Wikipedia, and I guess that's how it is, but if I was making a service aimed at ordinary people, I think I'd use a different name for that sport. I could certainly use the Freebase API to change that name, but it would get changed back. Organizations that want to maintain a stable POV won't want a write interface.