- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Mon, 24 Jun 2013 17:55:20 -0400
- To: public-lod@w3.org
- Message-ID: <51C8C048.5030302@openlinksw.com>
On 6/24/13 5:29 PM, Luca Matteis wrote:
> Exactly. And for me Linked Data is defined by those set of
> implementation details (HTTP, RDF, URIs and SPARQL).
And that's absolutely fine. Nothing wrong with that. You only hit issues
if you mandate that to someone who seeks to pursue the same goal using a
different approach etc..
The challenge here is that everyone doesn't see things the same way,
initially.
>
> The only difference between my understanding and yours is that you
> think that you can still produce valid Linked Data even without HTTP
> (using your own URI resolver), whilst I think you can *only* use HTTP
> in order to call it Linked Data.
I am not thinking or speculating. I can produce Linked Data using
alternative URI schemes based on our own handcrafted resolvers. Of
course, custom URI handlers aren't the norm on desktops but that's the
lay of the land in the mobile space i.e., you can register a custom URI
handler with the host OS and it will then delegate handling to your
custom resolver.
>
> I'm still not sure this is a beneficial message to send to newcomers.
I believe in adjusting to the needs of the audience (newcomer or
advanced users). I don't believe in being draconian pathways to a
destination when choices exist. More than anything else, the new stuff
has to work with what exists i.e., do as much as possible to avert
telling customers to "rip and replace" what they have en route to Linked
Data exploitation.
> The implementation details are at the core of defining Linked Data,
> because they're actually what's making it work.
They ultimately make it work productively, most of the time. There are
times when alternative routes have to be taken to the destination -- due
to the realities of legacy IT infrastructure.
>
> So essentially we can replace our entire RDF discussions with HTTP,
> and you'd probably have the same feelings, right? That is that you
> HTTP isn't *strictly* part of Linked Data's definition. I would still
> disagree, but I also would understand your point and conclude it with
> a "fair enough".
Yes, I think you are understanding me much better now. I am just about
puzzle pieces and jigsaw puzzles.
My company makes and designs data management & data access middleware
products, which is why (in our eyes) the architecture of the Web remains
the most dexterous piece of middleware we've encountered to date :-)
Kingsley
>
>
> On Mon, Jun 24, 2013 at 10:47 PM, Kingsley Idehen
> <kidehen@openlinksw.com <mailto:kidehen@openlinksw.com>> wrote:
>
> On 6/24/13 4:24 PM, Luca Matteis wrote:
>> Kingsley, how about being crystal clear of HTTP as well then?
>> Isn't that an "implementation detail" just as your understanding
>> of "RDF within Linked Data" is?
>>
>> - sorry for unleashing hell again
>
> There is not hell being unleashed. When did asking questions
> become a terrible thing? In fact, HTTP is an implementation
> detail. Of course, when you take into consideration that HTTP URIs
> lie at the core of the World Wide Web, its most cost-effective to
> use this type of resolvable URI to get going with Linked Data.
>
> To answer you question, precisely: HTTP is an implementation
> detail just like RDF and SPARQL :-)
>
> The thing about all of this (which Ora Lassila also tried to
> articulate) is the fact that ultimately, the productive way to
> produce *powerful* Linked Data boils down to these implementation
> details:
>
> 1. HTTP URIs -- so that you don't have to write your own URI resolver
> 2. RDF data model -- {*I won't answer this until we make progress
> re. my question about RDF's unique characteristics*}
> 3. SPARQL protocol based URLs -- an option for handling content
> negotiation via re-write rules which is part of the Linked Data
> URI lookup functionality .
>
> Kingsley
>>
>>
>> On Mon, Jun 24, 2013 at 10:07 PM, Melvin Carvalho
>> <melvincarvalho@gmail.com <mailto:melvincarvalho@gmail.com>> wrote:
>>
>>
>>
>>
>> On 24 June 2013 21:56, Kingsley Idehen
>> <kidehen@openlinksw.com <mailto:kidehen@openlinksw.com>> wrote:
>>
>> All,
>>
>> I've taken the time to embellish TimBL's original WWW
>> proposal illustration with Linked Data URIs [1].
>>
>> Why?
>>
>> Because, it seems to be unclear (to many) if the original
>> WWW design had Linked Data in mind all along.
>>
>> My claim and long standing position:
>>
>> The original WWW design always had Linked Data in mind,
>> and the proof lies in the presence of fundamental Linked
>> Data characteristics which come to life once you turn the
>> literal relation names (denotations) into HTTP URIs,
>> without cluttering the diagram.
>>
>> Remember, the rules for Linked Data publication are:
>>
>> 1. use URIs to name (denote) entities (things)
>> 2. use HTTP URIs so that names can be looked-up (i.e, by
>> HTTP URI de-reference)
>> 3. provide useful information when HTTP URIs are looked
>> up -- basically, this is where industry standards for
>> data representation and access come into play (e.g., RDF
>> and SPARQL, respectively)
>> 4. also refer to other entities (things) using their URIs
>> as part of the information you provide in #3.
>>
>> The WWW proposal diagram shows an collection of entities
>> related is a variety of ways i.e., the links/relations
>> are typed. Basically you have a relations property
>> hierarchy where "linksTo" or "connectedTo" sits at the
>> top with "describes", "includes", "refers to" are sub
>> properties. Writing this all up in Turtle should be
>> pretty obvious, and If need be I'll even do that too.
>>
>> Conclusion:
>>
>> The point here is not to create and endless permathread.
>> The simple goal is to be crystal clear about Linked Data,
>> the World Wide Web, and eventually RDF.
>>
>> I am singling out RDF at this point because lost in many
>> of the fragmented threads is the fact that I am yet to
>> have any respond with a clear lits of characteristics
>> that are unique to RDF i.e., what makes a document
>> distinctly RDF and nothing but that?
>>
>> The fact that I claim that RDF distinguishing features
>> haven't been presented so far in no way implies:
>>
>> 1. that they don't exist
>> 2. that this is some quest to replace RDF.
>>
>> There is only one quest here, and that is to be crystal
>> clear about Linked Data while also being crystal clear
>> about RDF. They both deserve clarity since conflating
>> them remains eternally detrimental to both. Even worse,
>> it just pushes the same old permathreads into the future.
>>
>>
>> Links:
>>
>> 1. http://bit.ly/1aIiD0L -- directory browsing view
>> exposing the image mapped HTML doc, jpeg, and OmniGraffle
>> source file.
>> 2. http://bit.ly/16v8fpR -- original WWW proposal diagram
>> enhanced with actual live HTTP URIs (most resolve to
>> documents that describe the URI's referent) .
>>
>>
>> The original (and current) vision is expressed quite well in
>> Tim's book, "Weaving the Web". From the first pages:
>>
>> [[
>> .. the idea stayed with me that computers could become much
>> more powerful if they could be programmed to link otherwise
>> unconnected information.
>>
>> ... a vision encompassing the decentralized, organic growth
>> of ideas, technology, and society. T*he vision I have for the
>> Web is about anything being potentially connected with
>> anything*. It is a vision that provides us with new freedom,
>> and allows us to grow faster than we ever could when we were
>> fettered by the hierarchical classification systems into
>> which we bound ourselves. It leaves the entirety of our
>> previous ways of working as just one tool among many. It
>> leaves our previous fears for the future as one set among
>> many. And it brings the workings of society closer to the
>> workings of our minds.
>> ]]
>>
>> http://www.bookbrowse.com/excerpts/index.cfm/book_number/125/weaving-the-web
>>
>>
>>
>> --
>>
>> Regards,
>>
>> Kingsley Idehen
>> Founder & CEO
>> OpenLink Software
>> Company Web: http://www.openlinksw.com
>> Personal Weblog: http://www.openlinksw.com/blog/~kidehen
>> <http://www.openlinksw.com/blog/%7Ekidehen>
>> Twitter/Identi.ca handle: @kidehen
>> Google+ Profile:
>> https://plus.google.com/112399767740508618350/about
>> LinkedIn Profile: http://www.linkedin.com/in/kidehen
>>
>>
>>
>>
>>
>>
>>
>
>
> --
>
> Regards,
>
> Kingsley Idehen
> Founder & CEO
> OpenLink Software
> Company Web:http://www.openlinksw.com
> Personal Weblog:http://www.openlinksw.com/blog/~kidehen <http://www.openlinksw.com/blog/%7Ekidehen>
> Twitter/Identi.ca handle: @kidehen
> Google+ Profile:https://plus.google.com/112399767740508618350/about
> LinkedIn Profile:http://www.linkedin.com/in/kidehen
>
>
>
>
>
--
Regards,
Kingsley Idehen
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen
Attachments
- application/pkcs7-signature attachment: S/MIME Cryptographic Signature
Received on Monday, 24 June 2013 21:55:44 UTC