Re: How the father of the World Wide Web plans to reclaim it from Facebook and Google

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