Its true that OData is a really good protocol, in the sense that it is more an 'application' layer over HTTP and I've been inspired by that. This way this proposal is also a meta-protocol over HTTP and paths are built along the lines of URI paths like:
/someSubject[path]/somePredicate[path]/someObject[path]
in the realm of some domain. Posted paths and metadata (referrer) are submitted through request body and headers. Let me work a while for real examples.
I think I've missed some important part for the 'application' layer (as HTML is for the 'document' oriented web) that is the 'representation' part of the resource. This paragraph added to the document (incomplete, confuse, questionable due this hypermedia approach) tries to address the issue:
"Representations (requesting client metamodel resources) are built upon aggregating and aligning protocol dialog 'path' resources into data (Fact, Event), information (Kind, Rule) and knowledge / behavior (Class, Flow) in the requesting node, maybe by multiple ‘posts’ / traversals of activated contexts. Those are the same models which get 'activated' in the requested side by means of async messages IO."
This is all but a incomplete draft of thoughts. Please be patient if bother in reading.
https://docs.google.com/document/d/1OqsVn6uo0cr6qruzWj9yRASrmvAIAf4HsHuLS2aRSy8/edit?usp=drivesdk
Regards,
Sebastián.
Neat stuff.The design covers a wide range but it does so very thinly. I would like to see a critical path identified and fleshed out in more detail, something along the lines of a research proposal, plan for a commercial product, or even a really cool demo.As for protocol, thought #1 is that it is hard to introduce an entirely new protocol because of the "two sided market" problem. A "good enough" protocol which gives you the data you need is better than a great protocol which has no data. You should look at OData as an example of a protocol that is well specified as opposed to GraphQL and see that the "one ring to bind them all" is really a system that can master all of the protocols. The rest of the world can (and will) do as it will.------ Original Message ------From: "Sebastian Samaruga" <ssamarug@gmail.com>To: "W3C Semantic Web IG" <semantic-web@w3.org>; "public-rww" <public-rww@w3.org>; "DBpedia" <Dbpedia-discussion@lists.sourceforge.net >; teiid-dev@lists.jboss.org; dev@metamodel.apache.orgSent: 8/23/2017 2:57:49 PMSubject: [DBpedia-discussion] ProtocolHi, newbie question again: what if a 'protocol' can be regarded as an issue for the 'data web' as there is one for the traditional 'document web'. The question is: does the design issues (ex.: RESTful application design patterns) of a document resource centric web holds (or at least part of them) for the concept of a 'data web' only because it relies in the same protocol / patterns (HTTP).
See attached file (or Protocol section in the link) for a first (confuse / abstract / questionable) set of thoughts in the subject:
https://docs.google.com/
document/d/ 1OqsVn6uo0cr6qruzWj9yRASrmvAIA f4HsHuLS2aRSy8/edit?usp= drivesdk Best Regards,
Sebastián.