- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Mon, 29 Apr 2013 22:06:15 -0400
- To: public-rdf-comments@w3.org
- Message-ID: <517F2717.10103@openlinksw.com>
On 4/29/13 6:44 PM, David Booth wrote: > On 04/29/2013 03:59 PM, Kingsley Idehen wrote: >> On 4/29/13 1:51 PM, David Booth wrote: >>>>> Apparently it was not entirely resolved. >>>> >>>> It was resolved, hence the definition in place today. >>> >>> It clearly has *not* been resolved, as: (a) we are still discussing >>> it; (b) there obviously is major contention; and (c) the definition in >>> the current draft substantially conflicts with the original sense of >>> the term and with established usage. >> >> It has been resolved on the JSON-LD side of things, to be clear. > > Not true. First, I see no such issue listed at all on the LDP working > group issue tracker, whether open or closed: > http://www.w3.org/2012/ldp/track/issues > Second, the JSON-LD spec as a whole is only in draft status. It is > far from resolved. Why are you debating this matter here when there is a JSON-LD list? This isn't the place for you to arrive at clarity about the status of this matter. > >> I have >> no idea what the state of play is on the RDF groups side of things, I do >> know that you are a single voice of dissent at this point in time >> though. > > For goodness sake, you just heard *two* voices of dissent in less than > 10 hours! And the voices are? Again, why not move this discussion to the right place. Do you truly believe that key JSON-LD spec participants are actually following this list? If they were, I would even be the one leading the retort to your position positions about Linked Data, RDF, and JSON-LD. > > Furthermore: > > - Of the top 10 hits from in a google search for "Linked Data", > **every one of them stated or implied that Linked Data is based on RDF.** > > - Of the top 10 sites listed in a google search for '"Linked Data" > is', **every one of them stated or implied that Linked Data is based > on RDF.** > > - Of the top 10 sites listed in a google search for '"Linked Data" > definition', **every one of them stated or implied that Linked Data is > based on RDF.** Wow! I didn't know that. > > How much evidence do you need? Not the kind you've presented so far. Since you haven't been able to clarify the relationship between RDF and Linked Data without utter conflation. The very kind of conflation that gets RDF nowhere and then simply drags Linked Data down with it, for no good reason whatsoever. None at all. > Shall we check the top 100 hits? Or the top 1000 hits? Shall we try > other search engines? If you search hard enough you might find a > tiny fraction that supports your claim. But the vast majority of the > evidence does not. > > The vast majority of the evidence indicates that in established usage, > the term "Linked Data" implies the use of RDF. You wish, but it's an utter fallacy. > If you wish to propose a new definition that is contrary to this > established usage, you are obviously free to do so. But please do > *not* make the patently false claim that your proposed new definition > reflects accepted usage. It very clearly does NOT. I am not proposing a new definition for JSON-LD or Linked Data. What I am telling you is that there is zero value in conflating RDF and Linked Data. > >> >>> >>>> >>>>> >>>>>> RDF and Linked Data are not the same thing. >>>>> >>>>> Of course not. Linked Data (in its original sense) *builds* on RDF >>>>> and other standards, most notably HTTP. >>>> >>>> Sorta. >>>> >>>> Linked Data is something you can produce using RDF and associated >>>> standards. >>>> >>>>> >>>>>> Linked Data is something that you can >>>>>> produce (5-star quality) using RDF. >>>>> >>>>> Yes. >>>>> >>>> >>>> Good, we are agreeing so far. >>>> >>>>>> TimBL's meme is all about a >>>>>> principled approach to producing Web-scale Linked Data that >>>>>> leverages >>>>>> standards such as RDF and SPARQL. >>>>> >>>>> Exactly. >>>>> >>>>>> That doesn't imply that the meme owns the phrase "Linked Data. >>>>> >>>>> The term was coined specifically for that purpose. AFAIK there is no >>>>> legal ownership of the term, so we're talking moral ownership here -- >>>>> not legal. The point is that attempting to redefine this term is >>>>> harmful to the Semantic Web community, because it creates confusion >>>>> about what "Linked Data" means. And that is harmful to W3C's >>>>> mission. >>>> >>>> TimBL cleverly generated a meme using a quite generic phrase. The >>>> original meme (the one that had no RDF or SPARQL references) was >>>> totally >>>> GOLDEN re., blending Open Data and Web Architecture. >>>> >>>> The meme got itself into trouble the moment RDF and SPARQL where added >>>> to its most recent revision, for the totally wrong reasons. This >>>> revision lay the foundation for RDF and Linked Data conflation. It >>>> took >>>> a GOLDEN meme and turned it into a vector for the same old political >>>> distractions that come with RDF (which is generally misunderstood). >>>>> >>>>>> >>>>>> Over extending what RDF is remains its ultimate problem. RDF doesn't >>>>>> have to cloud the definition of everything in order for it to be >>>>>> useful :-) >>>>> >>>>> That's directly backwards. What's clouding the definition is *not* >>>>> RDF, but the attempt to redefine the term "Linked Data" to mean >>>>> something different than what it was specifically coined to mean: >>>>> http://www.w3.org/standards/semanticweb/data >>>>> http://www.w3.org/DesignIssues/LinkedData.html >>>> >>>> RDF does not imply Linked Data, >>> >>> Of course not. The implication is the other way around: Linked Data >>> (in the original, established sense of the term) implies RDF. >> >> Linked Data doesn't imply RDF at all. > > Apparently it doesn't in *your* mind. No it doesn't. IN my mind RDF doesn't need to make a power-grab for the phrase "Linked Data" . RDF is useful on its own as a mechanism for producing powerful Web-scale Linked Data. > But in the established sense of the term, "Linked Data" very clearly > *does* imply RDF. Again, you wish. That's an utter fallacy. Repeating a fallacy doesn't make it true. "established sense of the term" means what? Who is doing the establishing here? > >> >> Linked Data simply implies that a URI resolves to a Document that >> describes its referent. >> >> RDF based Linked Data implies the above, plus the fact that the Document >> is comprised of RDF based content [1][2]. >> >>> >>>> most RDF resource out in the wild >>>> (modulo LOD cloud datasets) don't even conform to Linked Data >>>> principles >>>> in the slightest. >>> >>> Right. >>> >>>> Re-read this thread and I think you will see that you >>>> got "backwards" completely backwards. >>> >>> I am amazed that you think so. If you can show me evidence, then >>> perhaps I can figure out why we seem to be miscommunicating so badly. >>> At present I am mystified. >> >> As per my comments above, there are links to illustrations of RDF based >> Linked Data URIs which convey the critical aspects of RDF based >> Linked Data. >> >> Please note, the entity relationship model precedes any notion of RDF >> [3]. The contribution made by RDF is as follows: >> >> 1. URIs as denotation mechanism for entities >> 2. Explicit rather than implicit entity relationship semantics -- >> discernible to humans and machines. >>> >>>> >>>> RDF is a poor understood composite of: >>>> >>>> 1. Data Model >>>> 2. Data Model Syntax >>>> 3. Data Model Syntax Notations >>>> 4. Data Serialization Formats -- the product of processors >>>> transforming >>>> Syntax Notation into raw data for storage or across-the-write >>>> transfer. >>> >>> Please do not conflate RDF with its syntax or serializations. Many who >>> are new to RDF make this mistake. >> >> I am not making a mistake. A simple example: >> >> ## Turtle ## >> >> <> a <#Document> . >> >> ## End ## >> >> The above is an example of syntax notation. Note how the notation allows >> the use or relative URIs. That's syntax notation for expressing an RDF >> model graph using Turtle. >> >> A Turtle processor will not output an RDF graph serialization with >> relative URIs, such a thing is an invalid RDF graph. > > Turtle is a syntax for serializing RDF. It is a syntax notation for expressing RDF graphs. When a Turtle is exchanged between a client and a server, the final persisted data isn't Turtle notation. The final product is an RDF graph. A graph that will not have relative URIs, for instance. > It uses many syntactic conventions that are not a part of the RDF > model, including square brackets, parentheses for lists, "@prefix" > declarations, and relative URIs. The fact that those syntactic > elements do not appear in the RDF model is irrelevant. No, it means its a syntax notation that processors can interpret en route to making the actual RDF graph. > >> >>> It is harmful to perpetuate this misunderstanding. >> >> Who is perpetuating any kind of misunderstanding here? You have a simple >> Turtle example that backs up my point. > > No, Turtle is a syntax for serializing RDF. serialization != expression. > >> >> RDF has SPO based 3-tuples as its syntax. >> >> Turtle is an example of notation for expressing those 3-tuples. >> >> The final RDF graph is the product of processors that understand one or >> more syntax notations en route to producing actual RDF graphs. > > Right: Turtle is a syntax for serializing RDF. The Turtle > serialization is *not* the same as the actual RDF. Expressing a Graph is just that. Of course, you can serialize an RDF graph in Turtle, but that's the product of procession the graph expression. For example, the serialized Turtle will not have any relative URIs in it otherwise the RDF graph is utterly invalid. > >> >>> >>> RDF may be poorly understood to many developers, but that is >>> irrelevant, as many technologies are poorly understood to many >>> developers. >> >> It isn't irrelevant. RDF has taking a simple concept and turned it into >> a riddle, for all the wrong reasons. >> >>> But RDF is *not* poorly understood from a technical perspective: it is >>> a W3C standard and is very clearly defined. >> >> No comment. I think that statement speaks for itself with regards to >> actual reality. >> >>> >>>> >>>> Nothing in the RDF specs mandates that URIs or IRIs must resolve. >>> >>> Right. >>> >>>> Basically, the HTTP URI duality reality [1] isn't a part of the RDF >>>> spec. >>> >>> Right. >>> >>>> Thus, you cannot constructively conflate Linked Data and RDF. >>> >>> I didn't conflate them. >> >> You conflate them whenever you infer: >> >> 1. Linked Data is RDF > > No, in the sentence "Linked Data is RDF" the word "is" means "is > composed of" -- not "is the same as". The word "is" has many > definitions in English: > http://oxforddictionaries.com/definition/english/be > >> 2. RDF is Linked Data. > > I have never suggested that RDF is Linked Data. I have pointed out > more than once that Linked Data (in the established sense of the term) > is *based* on RDF -- not the other way around. The *established term* route will not get you to the point of clarity. You would like it to be so, but simply doesn't make it so. Worst of all, there is next to no value in it being so. The Web is about loose coupling. Break that "deceptively simple rule" and you end up with what's happened to RDF over the last 13+ years i.e., a really useful thing becomes the victim of poor and confusing narratives that repel rather than attract. > >> >> Linked Data is neither, it's something you can produce in very powerful >> form using RDF. >> >>> Linked Data (in the original and established sense of the term) >>> *builds* on RDF. Not the other way around. And the two are not >>> synonymous. >>> >>>> What you can do though, is talk about RDF based Linked Data. >>> >>> Yes, and in the original and established sense of the term "Linked >>> Data", *all* Linked Data is RDF based. >> >> It is not. Stop pushing that misconception. > > I resent that accusation. ?? I guess you haven't made any accusations in this discussion, right? > It is patently false, and I consider it libelous. If you can't take what you dish out, then don't make similar accusations. > > The vast majority of evidence shows that in the established sense of > the term, Linked Data *is* based on RDF. Dare I disagree? Would that be *libelous*? > > Please do not continue to make false claims either about the > established meaning of the term "Linked Data" or about me. ?? Bye, and I am done with this debate/discussion, the tone has deteriorated beyond any level that I can accept, personally. Kingsley > > Thank you, > David Booth > >> RDF is not the progenitor of >> "Linked Data" in any shape or form. Computing precedes the World Wide >> Web, you know that. >> >>> >>>> >>>> To conclude: >>>> >>>> JSON-LD is a good effort at outlining how to produce RDF based Linked >>>> Data that's expressible and serializable using JSON. >>> >>> I agree that's what JSON-LD *should* be. >> >> Great! >> >>> But the problem is that that is *not* what the current draft of the >>> JSON-LD spec reflects. >> >> To the degree the current draft can be tweaked without inferring: >> >> 1. Linked Data is RDF >> 2. RDF is Linked Data. >> >> I won't have any issue, anything else, well I will be in total >> disagreement. >> >>> In the current draft, JSON-LD has no normative basis in the RDF model >>> or the RDF semantics **at all**. >> >> Fine, and does it really need to? The connection with RDF has to be >> through the algorithms for producing RDF from JSON-LD or vice versa. >> >>> Sure JSON-LD *can* be mapped to RDF, but that's not saying much, >>> because *any* language can be mapped to RDF. >> >> But that's saying all that needs to be said re. JSON-LD. The goals or >> JSON-LD are clearly spelled out. >> >>> The current draft reads as a completely parallel attempt at defining >>> an independent language for achieving similar goals as Linked Data (in >>> the original, established sense of the term), while redefining the >>> term "Linked Data" to include this parallel language. >> >> It is an option for JSON developers seeking to work with Linked Data. >> Developers who have next to no interest in RDF and its inability to shed >> its riddle-like image which makes comprehension eternally mercurial to >> this Web developer profile. >> >>> >>> If the definition of "Linked Data" were broadened beyond using RDF as >>> the information model, where would the line be drawn? >> >> Again, Linked Data and RDF are not the same thing. You can produce >> powerful and very useful Linked Data using RDF. >> >> You continue to assume that RDF invented the 3-tuple and entity >> relationship model. You assume that HTTP URIs are the only mechanism for >> de-reference and indirection baked into structured data >> representation etc.. >> >> You can actually make 5-Star linked data using other URIs schemes. The >> downsides have more to do with the limitations in Web browsers and the >> ubiquity of this type of user agent re., the Web. On mobile platforms, >> the notion of URIs schemes works without the limitations imposed by >> desktop browsers etc.. >> >> >>> Would Excel spreadsheets be considered "Linked Data" if they contained >>> HTTP URIs that resolved to other spreadsheets? >> >> What does a named cell in an excel spreadsheet actually do? It uses >> name-address indirection to give you a name that resolves to an address. >> The problem is that in this case the actual relation semantics are >> implicit and coarse at best. Thus, to some it could be considered Linked >> Data. >> >> Better example, what about a CSV file comprised of 3 cols that's used to >> express entity relations in 3-tuple form? Where cols 1 & 2 hold URIs and >> the 3rd col hold URIs or literals? Is that Linked Data? >> >>> Would relational database tables? >> No they are not. >> >>> Would HTML documents? >> >> They are yet another example of coarse-grained linked data due to the >> fidelity entity relationship semantics. Remember, the HTML spec does >> have <link/> tags that denote relations. >> >>> >>> To step up a level: what is your goal in attempting to disassociate >>> RDF from Linked Data? >> >> Simple: end RDF narratives that are well intended but utterly >> distracting. RDF is useful without a distracting power-grab on "Linked >> Data" which is a very generic phrase. RDF based Linked Data is crystal >> clear and devoid of the aforementioned distractions. >> >> The real value of RDF is that it builds on the old entity relationship >> model by introducing explicit (rather than implicit) machine- and >> human-discernible entity relationship semantics. It also leverages the >> ingenuity of URIs as global identifiers for things in general. >>> What are you trying to achieve by redefining the term? >> >> I am not redefining anything. RDF has never been defined as Linked >> Data. If that was the case the spec would specifically mandate the very >> behavior expressed in TimBL's meme. >> >>> Are you trying to invent a different Semantic Web that is JSON-based >>> instead of being RDF-based? >> If you assume that, then we are speaking past ourselves on an inter >> galactic level :-) >> >> Links: >> >> 1. http://twitpic.com/cmw52i -- illustrating hashless Linked Data URIs >> (Webb Super Keys) e.g. those used by DBpedia >> 2. http://twitpic.com/cmw72m -- illustrating hash based Linked Data URIs >> (Webb Super Keys) >> 3. http://bit.ly/T3kWUv -- Peter Chen's 1976 dissertation on the entity >> relationship model . >> >> >> Kingsley >>> >>> David >>> >>>> >>>> >>>> Links: >>>> >>>> 1. http://bit.ly/YxW21k -- HTTP URI Duality that lies at the core of >>>> Linked Data as espoused by TimBL's original meme. >>>> >>>> Kingsley >> >> >> -- >> >> 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 >> >> >> >> > > > -- 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 Tuesday, 30 April 2013 02:06:39 UTC