Re: WebID vs. JSON (Was: Re: Think before you write Semantic Web crawlers)

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