Come see other top popular articles surfaced by Semantic Web experts!…

One might push this analogy even further; FluidDB’s permissions model (which covers only namespaces and tags; objects don’t have permissions) addresses all of CRUD for operations on tags, which one might extrapolate to assertions in a triple store or quad store. I do think the analogy only works if one equates FluidDB’s namespaces with named graphs, however…

Note: This would be a much simpler discussion if FluidDB was more obviously compatible with linked data principles…

I want to separate the question of which data are selected (thats where the premium content goes in) from the way how data are transported.

As in earlier ‘middleware’ history you will have different means for different (technical) requirements in customers scenarios. (I think of e.g. a service bus scenario, where the focus is on fast distribution of updates).

But one things remains important: regardless how you get and distribute the data, the data consumer has to able to put it together again – based on URIs.

Kingsley

Looking forward, one of the key opportunities with the “Web of Data” model (leveraging linked data principles) is ease of data integration across a variety of sources. As value-added, premium datasets become more widely available, it will be critically important for clients and especially other services to access them in a uniform way. This will be much easier if those services are presented with, and in term present to their consumers, uniform authentication and authorization models.

Consider the iconic Web of Data graph. That is a reality in part because of the consistency of the data model, and in part because of the uniformity of the access models for the various providers — including access control, which is non existent!

One can imagine the emergence of an ecosystem of premium applications based on constructing and traverse such graphs. It is hard to imagine this happening at significant scale if such construction cannot be done with ease and agility, which begs for a minimum degree of technical uniformity…

- My assumption is that we are quite mature (as a community) regarding platforms & tools to technically provide linked data to any kind of consumers.

- I think we need fitting answers to business asking us, “how to implement and execute these business models IT-wise?”. (e.g. billing of data access/usage etc.)

Remember that we now have the following re. Linked Data and their host Graphs:

1. FOAF+SSL based Identity
2. Access Control Lists scoped to Named Graphs
3. Context Rules exist in Named Graphs (so #1 + #2 applies)
4. SPARQL endpoints can be protected by FOAF+SSL (so you can control access to data sets at an even higher level).

FOAF+SSL should render current API Keys obsolete.

Named Graphs are going to become the Entity Oriented Data Access realm variant of SQL Views (Transient or Fully Materialized).

No only do we have the super information highways, we also have the concessions and scenic views into the mix too. User Agents based on User Profiles provide enough information for an Linked Data Server to provide optimized paths based on preferences

Kingsley

I think this approach is at once elegant and straightforward to both understand and implement. It allows providers to manage the “controlled” aspects of their datasets in a straightforward way. A disadvantage is that it provides the “extended” data as “canard” on the primary cluster of data.

From a security standpoint, some might be concerned that this approach allows the client to learn of the existence of a resource that they potentially don’t have access to. A more secure solution (I believe) would ensure that clients can only ever see what they are authorized to see.

What I’m suggesting is that “access” could either be controlled at the predicate/vocabulary level — the are certain “premium” predicates, and access to the triples based on them is restricted — or at the triple level (meaning, really, at the quad level).

This means that every client would be challenged to authenticate; depending upon their credentials, they would have access to different subsets of the total set of triples.

An advantage of this approach is that a client service (customer) could readily “update” without having to think about processing the extended set; once they upgraded, their view of the data would simply be expanded.

I hope this has made sense; we can discuss further!

John

Links:

1. http://www.mail-archive.com/public-lod@w3.org/msg03561.html — mail subject: Making human-friendly linked data pages more human-friendly

Kingsley

People in the Linked Data realm often pooh-pooh OWL, ironically, its OWL that’s going to be the key weapon for executing premium routes on the Linked Data driven Information Super Highway

Links:

1. http://umbel.org
2. http://bit.ly/90tUKJ — old post re. state of Linked Data Web (which should link to to post about UMBEL and Data Dictionaries etc).

Kingsley