JSON-LD Criticisms, #json-ld IRC channel on freenode, April 19th 2013: [Fri 15:02] we are very concerned the json-ld does not handle structured data effectively nor is it optimal for processed data structures [Fri 15:02] ist slow, it does not have suitable wrappers, whoever wrote it is severely short sighted about data types, and it is horribly inefficient [Fri 15:03] much of that is due to the javascript and json structure, but these problems are not compensated for [Fri 15:06] ? [Fri 15:12] ? [Fri 15:17] if you want a serious response to such a statement, please elaborate on each point. [Fri 15:20] Cat4D: Do you have a blog post or a paper explaining each one of those points in more detail? [Fri 15:20] from the perspective of those of us who have been working on this spec and with json-ld data for a long time, that statement makes no sense. we would be happy to help clear up confusion and explain things if you would like. [Fri 15:21] we are working on a demonstration model that uses the jsonld guides, however (due to json/dom deficiencies) it is highly inefficient especially for accessing or processing structured data [Fri 15:21] are there any schema constructors using jsonld strict definitions, or other tools/demos we should review? [Fri 15:25] the simple fact that both of you respond with horrible lack of comprehension that a data management system or definition is best represented as data, not a "blog" or "document" [Fri 15:25] is disconcerting [Fri 15:26] you work for W3 eh? undermining human society for illicit gains? [Fri 15:27] Cat4D: That sort of approach isn't very helpful, please refrain from personal attacks. [Fri 15:27] W3 is the problem, we can handle basic math, we know when someone has precomputed invalid systems and designed exploits or distinct holes [Fri 15:27] it is upsetting [Fri 15:27] Cat4D: Why are you depending on the DOM to get your data? [Fri 15:28] the problem is json's lack of structure [Fri 15:28] What are the JSON deficiencies that you are talking about? [Fri 15:28] but ignoring that [Fri 15:28] |<-- scor has left freenode (Quit: scor) [Fri 15:28] what are the inefficiencies you are referring to? [Fri 15:28] 3 factor indexes are prevented in all dom/json/etc standards [Fri 15:28] what do you mean by 'schema constructors'? [Fri 15:29] what do you mean by 'suitable wrappers'? [Fri 15:29] because of this, it requires multiple nested sets of information to accurately represent or wrap data [Fri 15:29] Why aren't you using something other than JavaScript to process the data if efficiency is a concern for you? [Fri 15:29] what sort of data are you trying to represent? Do you have a link to the data? [Fri 15:29] answers to all of these questions will help us help you. [Fri 15:30] fuckers, get a dictionary or get your criminal racket out of the global infrastructure... all of you are of the same exact distinct pattern, and known to our military and police institutions as a criminal organization and averse influence [Fri 15:30] the browser is the problem [Fri 15:30] the more you design holes upon holes [Fri 15:30] you undermine the usability of the systems [Fri 15:30] the american criminal racket and nato influences are a problem in their own [Fri 15:31] but W3 and the rest espeially mozilla do nothing but .. fuck over ... the planet [Fri 15:31] why would you knowingly design holes in a system? [Fri 15:31] you make illicit gains off of other exploits and major organized crime or american terrorism? [Fri 15:31] WHY THE HOLE YOU DESIGN HERE? [Fri 15:32] please, go on... we're listening with great interest. [Fri 15:32] the browser has nothing but js and dom to read jsonld [Fri 15:32] unfortunately this is the only deployed "standard" [Fri 15:32] don't use a browser, you can use non-browser tools to read JSON-LD. [Fri 15:32] sure [Fri 15:33] but because the json is intrinsicly limited, its futile [Fri 15:33] ok, then don't use JSON. [Fri 15:33] and most clients that exist are browser based [Fri 15:33] what are you trying to achieve here, Cat4D ? [Fri 15:33] what is your goal? [Fri 15:33] then why does W3 and mozilla and the associated criminal rackets undermine their own viability? [Fri 15:33] FIX YOUR PROBLEMS [Fri 15:33] Ok, start suggesting fixes. [Fri 15:34] we're listening. [Fri 15:34] it looks like your structure that is presented as json-ld is inverted [Fri 15:34] what's the solution? [Fri 15:34] we're loading a diversity of data types to see if there is a distinct efficiency or handling problem [Fri 15:34] who is 'we'? [Fri 15:34] (aside from json designed limitations) [Fri 15:35] your prioritization of order in the structure is error [Fri 15:35] especially when bound to indexed or flat arrays [Fri 15:36] also, there is no standard for the required components, the interassociated linking [Fri 15:36] -- or, its upside down [Fri 15:36] one must know a structured type to interpret or load a data structure [Fri 15:36] this is generally @link or @type [Fri 15:36] however because of the json limitations [Fri 15:37] the next layer in the nesting must also have supporting structure information [Fri 15:37] which is independent of the data itself [Fri 15:37] follow? [Fri 15:37] Cat4D: Have you seen this: http://json-ld.org/spec/latest/json-ld-framing/ [Fri 15:37] the lack of multiple factor nesting in the json system requires multiple layers of wrappers to handle these structures [Fri 15:38] or, if flattened, it requires EXPLICIT reserved names as standard [Fri 15:38] but here is the primary problem [Fri 15:38] Cat4D: point to a paper or specification that is talking about what you're attempting to convey. [Fri 15:38] what do you mean by "EXPLICIT" reserved names? [Fri 15:38] (first, your structure does not handle complex composite structure nor depth) [Fri 15:39] do you have an example of a 'complex composite structure' ? [Fri 15:39] a clear definition of the URI link definition, which you have tried, should mirror purl and other standards [Fri 15:39] what does that mean? [Fri 15:40] however inside this type definition, is a parallel data structure for the definition, which is similar to the data set [Fri 15:40] however the efficiency of this structure is critical in the accurate representation of the data [Fri 15:40] |<-- vikash has left freenode (Quit: Leaving) [Fri 15:41] your criminal group, with trained identical patterns here now, manu-db, needs to learn how to read a dictionary. [Fri 15:41] oh, of course, that would imply some semantic extrapolation or abstraction, which is what you get paid by a criminal racket to prevent. [Fri 15:41] ok, I'll learn how to do that tonight, I promise. [Fri 15:41] all of you need to look at the structure efficiency of the system [Fri 15:41] wait, who is the criminal racket again? W3C? [Fri 15:41] or was it the browser vendors? [Fri 15:42] especially related to possible parsing and access methods [Fri 15:42] no, all of the "standards" have mathematically designed holes which guarantee the systems are never usefull [Fri 15:42] oh, ok... all standards bodies are criminals. [Fri 15:42] for every wrapper you have a recursion weight [Fri 15:43] are the standards bodies colluding? Or are each a separate criminal syndicate? [Fri 15:43] the ammount of processing for the index lookup [Fri 15:43] do you have a formula for the recursion weight based on depth? [Fri 15:43] manu-db: you can claim to not comprehend how criminal influences mislead you and train you to respond in such ways [Fri 15:43] I'm not claiming that at all! [Fri 15:43] model it using the json standard in both the browsers and [Fri 15:43] I am very influenced by standards bodies. [Fri 15:44] various host systems' processing techniques [Fri 15:44] an index or array lookup, hash, etc have certain required processsing intensity [Fri 15:44] wait, are we still talking about the recursion weight algorithm? [Fri 15:44] so with this in mind [Fri 15:44] ok [Fri 15:44] the use of @whatever for a standard index has been useful for 2 decades [Fri 15:45] however the design and placement of the @whatever and the nesting data is critical [Fri 15:45] wait the actual literal string '@whatever'? [Fri 15:45] more importantly, if you parse out the structure to more optimal [Fri 15:45] no [Fri 15:45] you mean the '@' sign? [Fri 15:46] flat binary or various physical implementations, you note that ANY design based on json is fundamentally excessive [Fri 15:46] its just wrong [Fri 15:46] then why do you care about JSON-LD? [Fri 15:46] but in the browsers or any other existing defacto standard [Fri 15:46] or fixing JSON-LD? [Fri 15:46] because it is your job to define a set of @whatevers to handle linked data correctly [Fri 15:47] if it's just fundamentally wrong, surely your time is better spent elsewhere working on the 'right' solution? [Fri 15:47] and right now, its a bit short sighted [Fri 15:47] if not intentinoally designed to be inefficient and counter-productive [Fri 15:47] but if JSON is just fundamentally broken, there is no hope that we'll be able to salvage it, right? [Fri 15:47] and for such a small and simple definition, you need to concentrate on the processing effectiveness and access to the data [Fri 15:47] no, its designed that way, there is no way to expand it [Fri 15:48] so the way you compensate for that [Fri 15:48] is to use the @ definition to present the most effective structure possible [Fri 15:48] which right now your lookup is inverted / backward [Fri 15:48] understand? [Fri 15:48] and it makes a huge difference as the complexity of the structure increases [Fri 15:49] no [Fri 15:49] now hopefully you can pass this on and get some attention on the weight issue [Fri 15:49] manu-db: was not expecting so [Fri 15:49] thats why you all get paid by W3 and the racket! [Fri 15:49] yeah, I'm pretty sure I'm a lost cause, Cat4D. [Fri 15:49] hmmm, didn't really think that these people got paid to do this [Fri 15:50] pass it on. should be obvious, but anyone who understands the problem is also party to ensuring that the exploits and invalidity of the system are maintained [Fri 15:50] I also find it funny that manu-db is being blamed for JSON sucking [Fri 15:50] well, linclark - it probably is my fault in some way. [Fri 15:50] I kind of wonder if this is an elaborate prank [Fri 15:50] json problem is its own issue, but trying to work within it, the only way is to define the standards needed ( in @ ) to compensate [Fri 15:50] I would think a prank would have stopped a good 20 minutes ago, linclark [Fri 15:51] good point [Fri 15:51] although, the best pranksters know how to follow through [Fri 15:51] linclark: yes, given the mathematical model that eliminated the use of multiple factor indexes and structures has been ... the problem for decades [Fri 15:51] ya, like disa and nato, unfortunately [Fri 15:51] what are the exploits? can debate over bad design, inefficient, etc, but exploits? [Fri 15:51] yes, manu and his shady nato ties [Fri 15:52] that one simple designed problem has undermined the viability of the entire system, 800% excess load [Fri 15:52] yes, by technical terms, the intentional prevention of a means of representation of structure, as typical in json/dom, is an exploit against the system and implementatino [Fri 15:53] the lack of multiple factors other than those defined and hardcoded to the browser/system [Fri 15:53] then of course, the same exact problem in the code implementation of all the browser dom manages [Fri 15:54] it is designed, intentional, and prepared by a very malicient influence [Fri 15:54] and as such, their influences impede your ability to present structured data [Fri 15:54] what are your thoughts on using XML instead of JSON? [Fri 15:54] the american military and usdoj are the primary influences inherited to nato [Fri 15:54] xml has some option of structure, but it is even more of a mess [Fri 15:54] ah right, manu the army man [Fri 15:54] w3, linclark [Fri 15:54] manu leads a much more interesting life than I thought he did [Fri 15:55] mozilla, google, the rest of them [Fri 15:55] ;) [Fri 15:55] the processing of rdf, xml, etc all have the same problems [Fri 15:55] although the assignment process can BUILD structure [Fri 15:55] same with jsonld [Fri 15:55] linclark: you have no idea... well, I mean... now you do, I guess. [Fri 15:55] lol [Fri 15:55] its efficiency is intentionally limited [Fri 15:56] now, in these idiot browser implementations, which is the global standard, these magnitudes of designed inefficiency incapacitate the ability to implement [Fri 15:57] it wasnt until a decade and half after html/dom was created that the influences allowed more than a single lut and limited memory and horrible js ... problems [Fri 15:57] and not until the last 5 years that those have even partially worked [Fri 15:57] you know what the index lookup speed is for machine code [Fri 15:57] linclark... just to catch you up - this is what I've gathered so far: JSON is designed to be inefficient by the cronies paid by the standards organizations... I mean, nato/disa funded criminals. JSON-LD builds on top of this failure, which is designed with mathematical holes on purpose by us (but we don't know it because we've been brainwashed to think that way). We could fix this bad... [Fri 15:57] ...design, but it's imperative that we build a structure using the '@' indexing in JSON-LD to create a non-inverted structure that will result in less recursion weight. [Fri 15:57] did I get that right, Cat4D? [Fri 15:57] why is the browser a thousand times DESIGNED ineffective? [Fri 15:58] yeah, manu's responsible for that too [Fri 15:58] the @ is a viable option, its commonly understood from the old yahoo project [Fri 15:58] ya, pretty much [Fri 15:58] except the fundamental influences have undermined the viability of doing so [Fri 15:59] uhh influences on fundamental design [Fri 15:59] against [Fri 15:59] aww, come on linclark - let's spread the blame around a bit... taaz hasn't been blamed for any browser inefficiencies yet. [Fri 15:59] lol [Fri 15:59] * manu-db is surprised the Semantic Web hasn't been blamed yet... I mean, talk about a ripe target. [Fri 15:59] and it /was/ funded by the army, nato, etc. [Fri 15:59] manu-db :) [Fri 16:00] get this through to everyone working on json-ld, if its a purported standard intent, it needs to at least have correct structure and the ability to handle future expansions of the json/etc if such become available [Fri 16:00] manu-db: thats exactly the point, they have undermined the critical components in data management [Fri 16:00] to make sure the browser is fucked [Fri 16:00] and the related data structures, json etc [Fri 16:01] there is a rigid and well structured definition for the optimal representatino of semantic data [Fri 16:01] they looked at that, and guaranteed nothing does it correctly. [Fri 16:01] thats a criminal syndicate and well documented as such. [Fri 16:02] now, you try a half-assed attempt to handle structured data while undermined by those historical influences [Fri 16:02] ah, well - if you want to talk to the criminal syndicates undermining the data management critical components in browsers, they hang out in the #whatwg channel. [Fri 16:03] i was going to say -- "its fine" or could be -- but things like the link URI need to be standard definition if so, and the structure modeled for usability, which it currently is not [Fri 16:03] ya, you can pass it on. [Fri 16:03] I don't think they'll believe me if I tell them what has transpired here. [Fri 16:04] load some dense semantic data and run some test, it should be obvious [Fri 16:04] haha, I don't think they will [Fri 16:04] and we don't log this channel, which I really, really, regret us not doing at this point. [Fri 16:04] and get the required parts to a standard [Fri 16:04] manu-db: I do though.... [Fri 16:04] woo! [Fri 16:04] well copy it and pass it on. [Fri 16:04] Thanks Cat4D, I definitely will.