One of the real problems that pervades all routes to Linked Data value prop. incomprehension stems
from the layering of its value pyramid; especially when
communicating with -initially detached- end-users.
Note to Web Programmers: Linked Data is
about Data (Wine) and not about Code (Fish).
Thus, it isn't a "programmer only zone", far from it. More than
anything else, its inherently inclusive and spreads its
participation net widely across: Data Architects, Data Integrators,
Power Users, Knowledge Workers, Information Workers, Data Analysts, etc..
Basically, everyone that can "click on a link" is invited to this
particular party; remember, it is about "Linked Data" not "Linked
Code", after all. :-)
Problematic Value Pyramid Layering
Here is an example of a Linked Data value pyramid that I am
stumbling across --with some frequency-- these days (note: 1 being
the pyramid apex):
-
SPARQL Queries
-
RDF Data Stores
- RDF Data Sets
-
HTTP scheme URIs
Basically, Linked Data deployment (assigning de-referencable
HTTP URIs to DBMS records, their attributes, and attribute values
[optionally] ) is occurring last. Even worse, this happens in the
context of Linked Open Data oriented
endeavors, resulting in nothing but confusion or inadvertent
perpetuation of the overarching pragmatically challenged "Semantic Web" stereotype.
As you can imagine, hitting SPARQL as your introduction to
Linked Data is akin to hitting SQL as
your introduction to Relational Database Technology, neither is an
elevator-style value prop. relay mechanism.
In the relational realm, killer demos always started with
desktop productivity tools (spreadsheets, report-writers, SQL QBE
tools etc.) accessing, relational data sources en route to
unveiling the "Productivity" and "Agility" value prop. that such
binding delivered i.e., the desktop application (clients) and the
databases (servers) are distinct, but operating in a mutually
beneficial manner to all, courtesy of a data access standards such
as ODBC (Open Database Connectivity).
In the Linked Data realm, learning to embrace and extend best
practices from the relational dbms realm remains a challenge, a lot
of this has to do with hangovers from a misguided perception that
RDF databases will somehow completely replace RDBMS engines, rather than compliment
them. Thus, you have a counter productive variant of NIH (Not
Invented Here) in play, taking us to the dreaded realm of: Break
the Pot and You Own It (exemplified by the 11+ year Semantic Web
Project comprehension and appreciation odyssey).
From my vantage point, here is how I believe the Linked Data value pyramid should be
layered, especially when communicating the essential value
prop.:
- HTTP URLs -- LINKs to documents (Reports) that users already
appreciate, across the public Web and/or Intranets
- HTTP URIs -- typically not visually distinguishable from the
URLs, so use the Data exposed by de-referencing a URL to show how each Data Item (Entity or Object) is uniquely identified by a
Generic HTTP URI, and how clicking on the said URIs leads
to more structured metadata bearing documents available in a
variety of data representation formats, thereby enabling flexible
data presentation (e.g., smarter HTML pages)
- SPARQL -- when a user appreciates the data representation and
presentation dexterity of a Generic HTTP URI, they will be more
inclined to drill down an additional layer to unravel how HTTP URIs
mechanically deliver such flexibility
- RDF Data Stores -- at this stage the user is now interested
data sources behind the Generic HTTP URIs, courtesy of natural
desire to tweak the data presented in the report; thus, you now
have an engaged user ready to absorb the "How Generic HTTP URIs
Pull This Off" message
- RDF Data Sets -- while attempting to make or tweak HTTP URIs,
users become curious about the actual data loaded into the RDF Data
Store, which is where data sets used to create powerful Lookup Data
Spaces (e.g., DBpedia) come into play such as those from
the LOD constellation as exemplified by
DBpedia (extractions from Wikipedia).
Related