- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Wed, 22 Jun 2011 20:02:38 +0100
- To: public-lod@w3.org
On 6/22/11 4:14 PM, William Waites wrote: > * [2011-06-22 16:00:49 +0100] Kingsley Idehen<kidehen@openlinksw.com> écrit: > > ] explain to me how the convention you espouse enables me confine access > ] to a SPARQL endpoint for: > ] > ] A person identified by URI based Name (WebID) that a member of a > ] foaf:Group (which also has its own WebID). > > This is not a use case I encounter much. Usually I have some > application code that needs write access to the store and some public > code (maybe javascript in a browser, maybe some program run by a third > party) that needs read access. I am assuming you seek multiple users of your end product (the application), right? I assume all users aren't equal i.e., they have varying profiles, right? > If the answer is to teach my application code about WebID, it's going > to be a hard sell because really I want to be working on other things > than protocol plumbing. Remember, I like to take the "problem solving approach" to technology. Never technology for the sake of it, never. There is a fundamental problem: you seek >1 users of your apps. All users aren't the same, profile wise. Simple case in point, right here, and right now. This thread is about a critical challenge (always there btw) that Linked Data propagation unveils. The very same problems hit us in the early '90s re. ODBC i.e., how do we control access to data bearing in mind ODBC application user profile variations. Should anyone be able to access pensions and payroll data to make a very obvious example. The gaping security hole that ODBC introduced to the enterprise is still doing damage to this very day. I won't mention names, but as you hear about security breaches, do some little digging about what's behind many of these systems. Hint: a relational database, and free ODBC, JDBC, OLE-DB, ADO.NET providers, in many cases. Have one of those libraries on a system, you can get into the RDBMS via social engineering (in the absolute worst case, or throttle with CPUs for passwords). Way back then we use Windows INI structure to construct a graph based data representation format that we called "session rules book". Via these rules we enabled organizations to say: Kingsley can only access records in certain ODBC/JDBC/OLE-DB/ADO.NET accessible databases if he met certain criteria that included the IP address he logs in from, his username, client application name, arbitrary identifiers that the system owner could conjure up etc.. The only drag for us what it was little OpenLink rather than a behemoth like Microsoft. When we encountered RDF and the whole Semantic Web vision we realized there was a standardized route for addressing these fundamental issues. This is why WebID is simply a major deal. It is inherently quite contradictory to push Linked Data and push-back at WebID. That's only second to rejecting essence of URI abstraction by conflating Names and Addresses re. fine grained data access that address troubling problems of yore. > If you then go further and say that *all* access to the endpoint needs > to use WebID because of resource-management issues, then every client > now needs to do a bunch of things that end with shaving a yak before > they can even start on working on whatever they were meant to be > working on. > No. This is what we (WebID implementers) are saying: 1. Publish Linked Data 2. Apply Linked Data prowess to the critical issue of controlled access to Linked Data Spaces. Use Linked Data to solve a real problem. In doing so we'll achieve the critical mass we all seek because the early adopters of Linked Data will be associated with: 1. Showing how Linked Data solves a real problem 2. Using Linked Data to make its use and consumption easier for others who seek justification and use case examples en route to full investment. > On the other hand, arranging things so that access control can be done > by existing tools without burdening the clients is a lot easier, if > less general. And easier is what we want working with RDF to be. It has nothing to do with RDF. It has everything to do with Linked Data i.e., Data Objects endowed with Names that resolve to their Representations. Said representations take the form of EAV/SPO based graphs. RDF is one of the options for achieving this goal via a syntax with high semantic fidelity (most of that comes from granularity covering datatypes and locale issues). What people want, and have always sought is: open access to relevant data from platforms and tools of their choice without any performance or security compromises. HTTP, URIs, and exploitation of full URI abstraction as mechanism for graph based whole data representation, without graph format/syntax distractions is the beachhead we need right now. The semantic fidelity benefits of RDF re. datatypes and locale issues comes after that. Thus, first goal is to actually simplify Linked Data, and make its use and exploitation practical, starting with appreciation of trust logic based ACLs delivered on a platter via WebID. When Facebook, Google, Microsoft, Yahoo! etc.. say: we are happy to use graphs as basis for exposing fine grained data access to their respective Web hosted Data Spaces, we are supposed grok the opportunity. The opportunity exists because they are really saying: our business models don't let us make high fidelity graphs, but we are hoping your Linked Data and Semantic Web folks will exploit the translation/transformation opportunity, at least until the associated opportunity costs force us to re-evaluate. Basically, this is the fundamental point that continues to blow by most. These guys grok graphs, names, and addresses. Their real problem is size, each is an ocean liner, courtesy of explosive growth. Data Access ultimately always boils down to performance and security. Linked Data is a powerful foundation for tackling these age-old problems. > Cheers, > -w > -- Regards, Kingsley Idehen President& CEO OpenLink Software Web: http://www.openlinksw.com Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca: kidehen
Received on Wednesday, 22 June 2011 19:03:18 UTC