- From: Melvin Carvalho <melvincarvalho@gmail.com>
- Date: Fri, 2 Sep 2016 14:54:16 +0200
- To: Kingsley Idehen <kidehen@openlinksw.com>
- Cc: business-of-linked-data-bold <business-of-linked-data-bold@googlegroups.com>, public-rww <public-rww@w3.org>
- Message-ID: <CAKaEYhKEpqpn2xqUFqX1O=Jg162qHm+CPu48ERhw1aW11jDxUQ@mail.gmail.com>
On 25 August 2016 at 15:36, Kingsley Idehen <kidehen@openlinksw.com> wrote: > On 8/25/16 5:24 AM, Melvin Carvalho wrote: > > > > On 25 August 2016 at 04:10, Kingsley Idehen <kidehen@openlinksw.com> > wrote: > >> On 8/24/16 2:00 PM, Melvin Carvalho wrote: >> >> >> >> On 24 August 2016 at 18:25, Kingsley Idehen <kidehen@openlinksw.com> >> wrote: >> >>> On 8/24/16 9:08 AM, Melvin Carvalho wrote: >>> >>> >>> >>> On 24 August 2016 at 13:55, Kingsley Idehen <kidehen@openlinksw.com> >>> wrote: >>> >>>> On 8/24/16 3:52 AM, Melvin Carvalho wrote: >>>> >>>> >>>> >>>> On 24 August 2016 at 04:17, Kingsley Idehen <kidehen@openlinksw.com> >>>> wrote: >>>> >>>>> On 8/23/16 6:56 PM, Melvin Carvalho wrote: >>>>> >>>>> >>>>> >>>>> On 24 August 2016 at 00:28, Kingsley Idehen <kidehen@openlinksw.com> >>>>> wrote: >>>>> >>>>>> On 8/23/16 5:36 PM, Melvin Carvalho wrote: >>>>>> >>>>>> yes, i was able to create a file, nice! >>>>>> >>>>>> On 23 August 2016 at 20:43, Kingsley Idehen <kidehen@openlinksw.com> >>>>>> wrote: >>>>>> >>>>>>> On 8/23/16 2:25 PM, Melvin Carvalho wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 22 August 2016 at 14:49, Kingsley Idehen <kidehen@openlinksw.com> >>>>>>> wrote: >>>>>>> >>>>>>>> On 8/22/16 4:34 AM, Timothy Holborn wrote: >>>>>>>> >>>>>>>> Kingsley, >>>>>>>> >>>>>>>> Most of the interesting open data related platforms plug into >>>>>>>> Virtuoso. >>>>>>>> >>>>>>>> >>>>>>>> They support open standards. Virtuoso supports open standards. >>>>>>>> >>>>>>>> >>>>>>>> I think you need to step it up a bit, and am happy to help, but am >>>>>>>> unsure of the best way to go about it. >>>>>>>> >>>>>>>> >>>>>>>> I am totally unsure of what Virtuoso has to add to this matter. >>>>>>>> >>>>>>>> >>>>>>>> If SoLiD is Virtuoso compatible, I think the answer is bit of a >>>>>>>> no-brainer. Question remains one of business >>>>>>>> systems, rather than exclusively Tech. >>>>>>>> >>>>>>>> >>>>>>>> Virtuoso supports all the open standards covered by SoLiD, and some >>>>>>>> (e.g., WebID+TLS+Delegation). >>>>>>>> >>>>>>>> We need to speak clearly about these issues otherwise we have >>>>>>>> nothing but confusion. >>>>>>>> >>>>>>> >>>>>>> What will be really amazing is when Solid apps are tested to run on >>>>>>> an openlink backend and vice versa. >>>>>>>  >>>>>>> >>>>>>> Melvin, >>>>>>> >>>>>>> So why don't I share a folder endpoint [1] and the you try to use >>>>>>> SoLiD to create a document in that folder? Naturally, I would need to grant >>>>>>> access to you via your WebID (which I assume to be: >>>>>>> https://melvincarvalho.com/#me) . >>>>>>> >>>>>>> Links: >>>>>>> >>>>>>> [1] http://kingsley.idehen.net/DAV/home/kidehen/Public/solid/ >>>>>>> [2] https://kingsley.idehen.net/DAV/home/kidehen/Public/solid/ >>>>>>> [3] http://kingsley.idehen.net/DAV/home/kidehen/Public/solid%2Cacl >>>>>>> -- ACL doc (your webid has access to this too!) >>>>>>> [4] https://linkeddata.uriburner.com/rdf-editor -- Editor that can >>>>>>> be used to compare experience re. creation of document in the sample/qa >>>>>>> folder. >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Regards, >>>>>>> >>>>>>> Kingsley Idehen >>>>>>> Founder & CEO >>>>>>> OpenLink Software (Home Page: http://www.openlinksw.com) >>>>>>> >>>>>>> Medium Blog: https://medium.com/@kidehen >>>>>>> Blogspot Blog: http://kidehen.blogspot.com >>>>>>> Twitter Profile: https://twitter.com/kidehen >>>>>>> Google+ Profile: https://plus.google.com/+KingsleyIdehen/about >>>>>>> LinkedIn Profile: http://www.linkedin.com/in/kidehen >>>>>>> Personal WebID: http://kingsley.idehen.net/dataspace/person/kidehen#this >>>>>>> >>>>>>> -- You received this message because you are subscribed to the >>>>>>> Google Groups "Business Of Linked Data (BOLD)" group. To unsubscribe from >>>>>>> this group and stop receiving emails from it, send an email to >>>>>>> business-of-linked-data-bold+unsubscribe@googlegroups.com. For more >>>>>>> options, visit https://groups.google.com/d/optout. >>>>>>> >>>>>> -- You received this message because you are subscribed to the Google >>>>>> Groups "Business Of Linked Data (BOLD)" group. To unsubscribe from this >>>>>> group and stop receiving emails from it, send an email to >>>>>> business-of-linked-data-bold+unsubscribe@googlegroups.com. For more >>>>>> options, visit https://groups.google.com/d/optout. >>>>>> >>>>>> Melvin, >>>>>> >>>>>> Does that imply things are fine re. SoLiD or not? >>>>>> >>>>> One test is passing at least, which is a good sign! >>>>> I think to say things are 'fine' we really need to develop a test >>>>> suite and run tests. There may be other ways, but that >>>>> seems to be tried and tested. >>>>> >>>>> Melvin, >>>>> >>>>> I am trying to avoid "OpenLink doesn't support SoLiD" cycles that keep >>>>> on reoccurring. >>>>> >>>> Got it. But it requires testing and possibly some bug >>>> fixing. >>>>  >>>> >>>>> If there is a pattern that fails it should be identified and >>>>> demonstrated. >>>>> >>>> This is where a test suite comes in handy. W3C working groups >>>> typically require 1-3 years for this. I think we need a similar >>>> process. There may be short cuts but it would normally require one >>>> dedicated tester. >>>> >>>> W3C process != Practical Commercial process. >>>> >>>> Having worked on interop for more than 20+ years re., standards like >>>> SQL, ODBC, JDBC, ADO.NET, HTTP, and others, the process has more to do >>>> with willingness to collaborate than anything else. >>>> >>>> Given a server application (server) that implements standard X, there >>>> should be N number of client application (client) users willing enough to >>>> test interop as part of a practical QA process. Right now, the big issue is >>>> that interop gets scoped to the wrong levels. >>>> >>> Presently I see people testing Solid against node-solid-server and gold. >>> Previously I have seen testing against LDPHP. I've only seen you and >>> sometimes me test against an openlink back end and that's when we have a >>> bit of time free. >>> >>> Yes, but once again, its a case of understanding the roles of compliant >>> servers and clients. Virtuoso is a compliant server. All you need is an >>> endpoint and away you go. It either works or it fails. If it fails simply >>> report what's failing. >>> >> Is virtuoso Solid compliant? Compliant to what? Has it been tested? >> >> What do you mean by any of those questions? Put differently, why don't >> you provide cURL based examples of what doesn't work, based on your >> expectations? >> >> Does it handle globbing? >> >> cURL example please. >> >> Does it handle websockets? >> >> You now it does. >> >> Does it comply to the ACL spec? >> >> How did you end up creating a resource in a folder if it didn't comply >> with ACLs scoped to your WebID? >> >> Does it support inboxes? >> >> What is an inbox? Put differently, how is it different from folder where >> you store documents? >> >> Does it support Linked Data Notifications. >> >> No it doesn't . >> >> Does it comply to the sections of the latest solid spec? >> >> What are those? >> >> What browser coverage does it have, what breaks? These are questions we >> are going through on a daily basis with other backends. >> >> Instead of asking these questions you could demonstrate your point with a >> SoLiD client and/or curl interaction examples. >> >>  >> >>> What do I mean by "wrong levels" ? The fact that this kind of testing >>>> gets lost in presumptive patterns rife with compilation and platform >>>> dependencies e.g., open source and all the modules required to be located >>>> and built. After that, testers then find out that they have to right code >>>> to perform basic interop. >>>> >>> I think you mean people do not have the time to work though and fix bugs. >>> >>> No, I mean it is being approached the wrong way. What you need is: 1. >>> List of compliant servers and their live endpoints 2. List of compliant >>> clients 3. Folks testing the clients and the servers (this doesn't always >>> have to be the developers of either client or server being tested). There >>> isn't a single guideline that states: To verify or have some else verify >>> SoLiD based interop, simply add your SoLiD compliant server and its >>> endpoint to the list in the page at <some-server-usage-doc-location-uri> >>> . To verify or have some else verify SoLiD based interop, simply add your >>> SoLiD compliant client applications and a usage guide document link to the >>> page at: <some-client-app-usage-doc-location-uri> . Post your results >>> or share you experience via comments or reports to a document at: >>> <some-interop-results-doc-location-uri> . >>> >> We are doing this constantly in the gitter channel. Behind that lies >> the github solid repo which has active issue tracking. >>  >> >>>  As it's a new technology inevitably there will be bugs, it needs a >>> lot of persistence to work through. Openlink is not immune to bugs either, >>> I have found and reported some myself. >>> >>> Do you have a link to SoLiD related bugs or issues? That's all we need. >>> >> Various repos under: https://github.com/solid >> Pretty much all have issue tracking >>  >> >>> Interop should simply be about compliant client N talking to compliant >>>> server X. That's it. We don't need 6 months to pull that off, let alone 1-3 >>>> years. >>>> >>>> I am happy to perform interop with anyone (partner or competitor or >>>> customer) using the basic pattern outlined above. The end results are >>>> mutually beneficial, as they should be, when working with standards >>>> compliance. >>>> >>> Then just do it! >>> >>> I am confused. What is it that we haven't done? >>> >> Any kind of serious testing. My original point. If solid apps work on >> virtuoso that's going to be a big win. Write a backend, write apps. >> Test on virtuoso, test on node solid server, test on gold. That is the >> test of compliance. Failing that, work on passing a test suite. >>  >> >>>  I still believe the process we are using right now has not yielded >>> fast progress, but a working group where people actually commit to >>> deliverables does achieve interop. It's just a question of how much time >>> each process takes. The thing about a WG is that you generally commit 1 day >>> a week or as much as 0.5 of a FTE, per company involved. That's a more >>> resource that is currently being employed. >>> >>> There is subtle confusion about my point reflected in your last two >>> comments. If a SoLiD client fails to work with my Virtuoso instance, then >>> simply indicate what the issue is. You can also share a list of SoLiD apps >>> here and I can once again test them. That said, I have zero interest in >>> compiling anyting or heading out on module graph bounties. I just want to >>> install something and test. >>> >> Yes, I think we're talking high level perspective vs low level >> perspective. The devil is in the detail. >> I will be working on my own back end "solid live" and the acid test for >> me will be whether solid apps can work with it. >> >> Your description of SoLiD, as exemplified by this exchange, isn't how you >> make progress. First off, you need to be able to actually describe what >> SoLiD actually is, clearly. Simply declaring things as compliant vs non >> compliant, without any clarity isn't the way to generate uptake and interop >> activity. What is the fundamental goal of SoLiD? What is does it actually >> offer right now, that uniquely distinguishes it with regards to using HTTP, >> WebDAV, LDP, Web ACLs, WebID+TLS, WebID+TLS+Delegation, SPARQL Graph >> Protocol, SPARQL 1.1 etc. to perform Read-Write operations? Answering this >> question is crucial :) Kingsley >> > Have you looked at this? https://github.com/solid/solid-spec > > Melvin, > > You know I've looked at that, and much more. We are having a public > discussion and its really important that you (and other SoLiD supporters) > embark on the following: > > 1. Articulate what problem SoLiD solves, uniquely > > 2. Demonstrate how SoLiD delivers on its value proposition via simple > Client and Server implementations that just work i.e., no coding and > compilation involved. > > We have a maze of technologies and "best practices" all conflated under > SoLiD, unfortunately. That doesn't make for a sound interop basis when you > have failure points at the following levels: > > [1] WebID Authentication using WebID+TLS protocol > > [2] WebID+TLS authentication protocol and Browser UX issue -- which is > solved by WebID+TLS+Delegation protocol > > [3] Non-existent interop efforts across WebID+TLS, WebID+TLS+Delegation > compliant clients and servers > > [4] Non-existent interop efforts across WebACL compliant clients and > servers > > [5] All of the above for LDP compliant clients and servers; ditto SPARQL > Graph Protocol and SPARQL 1.1 compliant clients and servers. > > Without 1-5 sorted out, you have nothing to work with, in a practical > sense. > My suggestion to test solid compliance might be to see if this profile editor works with a given backend https://linkeddata.github.io/profile-editor/ There's also an issue tracker linked to page > Links: > > [1] https://medium.com/virtuoso-blog/http-read-write-operations-using-ldp- > protocols-virtuoso-http-s-server-bdaa2736169f#.uj8bvbuwu -- Example of > interop using Virtuoso as server and cURL as the client with regards to > Read-Write operations over HTTP > > [2] https://medium.com/@kidehen/note-about-solid-a-loosely- > coupled-read-write-initiative-f56113484bbb#.6mypw3psh -- What is SoLiD > > [3] https://github.com/solid/solid#standards-used -- reiterating my > points about conflating standards, "best practices", and applications . > > -- > Regards, > > Kingsley Idehen > Founder & CEO > OpenLink Software (Home Page: http://www.openlinksw.com) > > Medium Blog: https://medium.com/@kidehen > Blogspot Blog: http://kidehen.blogspot.com > Twitter Profile: https://twitter.com/kidehen > Google+ Profile: https://plus.google.com/+KingsleyIdehen/about > LinkedIn Profile: http://www.linkedin.com/in/kidehen > Personal WebID: http://kingsley.idehen.net/dataspace/person/kidehen#this > >
Received on Friday, 2 September 2016 12:54:49 UTC