Re: WebID equivalence

On 4 January 2012 16:07, Kingsley Idehen <kidehen@openlinksw.com> wrote:

> Yes, but I would also like you to share some insights into the challenges
> associated with Linked Data deployment where de-referencable URI base Names
> are for all intents and purposes a luxury, irrespective of their intrinsic
> prowess.
>
> I am trying to remind people here that Linked Data is nuance laced albeit
> powerful. The fact that I have no problem deploying linked data with my
> toolset doesn't make that the norm for others. I am not getting this
> dimension of my message across with success here, each attempt starts of a
> series of long repetitive threads. Thus, I seeking alternative voices that
> also understand (from experience) the *luxury* nature of HTTP based
> de-referencable Names as required by Linked Data.

For me, this comes back to a discomfort with the 'religious zeal'
strand of Linked Data enthusiasm that we saw, at least 2006-9ish.
Don't get me wrong; on balance that enthusiasm brought us amazing
things and took the whole effort to a new level. But with wider
adoption looming I think we need to be a bit more tolerant and
open-minded about what we count as 'Linked Data'. I have a slightly
different spin on that than you but I believe there are some common
motivations.

Linked Data is a great name, and much more public-friendly than 'RDF'
or 'Semantic Web'. It's also a very general sounding name. But since
it came from a specific technical community ... those working with
W3C's RDF standards, and specifically those who cared about publishing
and interconnecting RDF descriptions in the Web, ... it also came to
have a fairly narrow interpretation. For some, it wasn't real proper
"Linked Data" unless every mentioned entity had a URI, and that URI
could be fetched in the public Web, and the resulting document was
also RDF, ... and so on. Omitting URIs was a cardinal sin ( hence FOAF
for some wasn't "really" proper/decent/good Linked Data, since we
allowed people to be described without being URI-named). And so on.

For me, "Linked Data" is a great name and brand, but it is
fundamentally a pun. It's a plan on words, clevery drawing attention
to two very different but -ahem- linked notions of "Link" that we have
in the world of RDFish Web data.

1. Links -good old hypertext references- between documents; each of
which modestly and partially describes some piece of the world.
2. Links between those things (virtual or real) described in said
documents; various kinds of relationship that can hold between
entities.

Linked Data is about using networks (graph structures and hypertext
structures, cleverly combined) to describe things. In some
circumstances, one or the other aspect takes primacy; and in some
circumstances, one or the other side can be a bit of a burden. That's
fine so long as we don't insist too heavily that all good data must
fit some rigid template of being hypertext-published interconnected
graphs.

Linked Data is great, even if sometimes you think "ok, great that I've
got triples here, but really I wanted the Excel file or the video or
the GraphML". We shouldn't assume that data in its ideal form is
always triples. And it's great even if you sometimes think "ok, it's
nice that these descriptions are broken up into bite-sized-chunks and
made accessible as Web documents ... but you know, I'd rather have a
giant compressed .tar.gz without the redundancy and Web crawling
sometimes....". To insist that data must *always* be expressed as RDF
(or EAV if you prefer the broader/vaguer term) is stubborn; to insist
that it must always be split up and published per-entity in thousands
or millions of cookier-cutter documents is equally stubborn. If we
aspire towards universal adoption we have to be comfortable with
relaxing each of these constraints, even while showing the value that
they can bring...

I have no problem using the phrase "Linked Data" even if the data
comes over CORBA; it's an evocative label for data that is structured
in a way that embraces sharing and mixing, rather than a specific
fixed recipe. For me the RDF effort is central to this, but we can do
this modestly: sometimes RDF (and EAV structures in general) just
isn't a great way of representing data, except as a metadata envelope.
I don't think we can impose much more on the wider world...

Dan

Received on Wednesday, 4 January 2012 16:27:10 UTC