On 6/22/11 4:14 PM, William Waites wrote:
* [2011-06-22 16:00:49 +0100] Kingsley Idehen<[email protected]> é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
