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 <[email protected] <mailto:[email protected]>> 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 againThere 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 . KingsleyOn Mon, Jun 24, 2013 at 10:07 PM, Melvin Carvalho <[email protected] <mailto:[email protected]>> wrote: On 24 June 2013 21:56, Kingsley Idehen <[email protected] <mailto:[email protected]>> 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
smime.p7s
Description: S/MIME Cryptographic Signature
