json-ld (part 3 of 3)

Subject: json-ld (part 3 of 3)

• note: originally emailed 06/24/2014 and sanitized for public consumption
• sidenote: posting here so i can lead people here whenever they ask me about this stuff...
• series: part 1 & part 2

---

Let me first say, I can see why they want all of this stuff:

• xmlns:
• RDF
• JSON-LD
• And finally -- from the only [usable] JSON-LD implementation available so far [that I know of so far]
• a Hydra powered web API via symfony

This is the java nerds sticking their dirty fingers with a kung-fu death grip in the web world trying to make themselves still relevant.

Anyways, here's a HOWTO on getting "a" webby API thingie working with this JSON-LD stuff...


In a nutt shell
First, you need to know that Hydra is installed via "a" PHP package manger called Symfony

• If you are interested in learning about Symfony, here's the brain dead simple howto:
• http://symfony.com/doc/current/quick_tour/the_big_picture.html
• Note: this installs locally and can be safely deleted
• Just note that will require a running DB (e.g. mysql)

Now, install the sample hydra demo (so you have a working version to play with)

• https://github.com/lanthaler/sfHydraDemoApp
• Part 1 [of the demo] should look familiar if you did the crash course above
• When you get to part 3 [of the demo]: pay attention to the last line:
• "Please note that it will return JSON-LD so you might wanna access it using cURL or the Hydra Console"

Then there's "HydraBundle" -- which I'm guessing is a way to shove this Hydra server in your Symfony project.

• https://github.com/lanthaler/HydraBundle

My analysis
Anyways, the Hydra demo implementation has confirmed my suspicion -- the webserver (or whatever RESTy box) needs to handle the URI path (as the parameter to your "handler")

• E.g. http://webserver/account/foo/bar
• In this case, the following does not actually exist on the "web server":
• account/foo/bar
• account/foo
• account
• and yes, the webserver walks those paths first
• to see why, check out http://wiki.nginx.org/Pitfalls
• "Passing Uncontrolled Requests to PHP"
• Nick's mad HACK tip of the day!
• finally, (in this case) a "index" file -- at http://webserver/ would take over
• the demos have this file as "app.php"
• this file takes and read the URI path and processes it by (depending on the php implementation) walk the "path" as the parameters for the request
• so, http://webserver/app.php would process [ account/foo/bar ] and do with it as necessary

Side note: I've never used Symfony in the past -- and after this little exercise, I don't think I'll ever use it in the future...

• Really? [A] java build system that compiles PHP code to include a bunch of other PHP frame work code...
• And the "compiled" PHP code isn't even optimized -- cached, yes, but the number of files "loaded" is still HUGE
• Yes, it's nice that it automates some steps, does some checks, it looks pretty... but wowzers -- it's big and this code is supposed to be called every time there's a REST request?


• To understand how the REST URI is mapped to the handler, read this:
• http://williamdurand.fr/2012/08/02/rest-apis-with-symfony2-the-right-way/
• Basically, it's under app/config/*.yml
• Security.yml is a good start
• Note: This is part is from symphony -- hydra demo is just returning the json-ld response...

Personally, this is way too much code baggage for something that should be much simpler to ... implement?


Extra
And, since this was mentioned in today's meeting, if you've never used this before, BOOKMARK THIS:

• http://jsbeautifier.org/
• Shove your SUPER LONG LINE here and press the magic "beautify" button

json-ld (part 2 of 3)

Subject: json-ld (part 2 of 3)

• note: originally emailed 06/19/2014 and sanitized for public consumption
• sidenote: posting here so i can lead people here whenever they ask me about this stuff...
• series: part 1 & part 3

---

This message is primarily for the TO: peeps. But some of you have asked about json-ld before and this would benefit everyone here for future reference.


Epiphany:
While reading up on some (computer) graphics articles -- I found out (in a round-about way) what linked-data (um, actually) the * description languages would be good for.

Not so fast:
First, why I still think it's not needed (in the context of javascript's json handler) -- it's unused information (you'll see this in a sec).

• For more info on why I don't like json-ld (just like why I don't like VM's) -- it's heavy with a lot of un-needed cruff (you can read more about it from the email thread below).
• Again, I'm coming from a javascript coder [for a project with restricted and security considerations] point of view...

So, what is it good for?
It (linked-data/interface description language/data format description language/etc.) is good for:

• binary only data (i.e. structs/class)
• getting transported between different programming languages
• which might be running on different architecture (endian-ness, 32 vs 64 bits, etc.)
• these (the data payload) are quite specific and can lead to catastrophic behavior if not handled properly

Examples of this type of mechanisms are:

• ZeroC's Ice
• Apache's Thrift
• Google's Protocol Buffer
• etc...

What does all that mean?
Basically, it's good for defining your data structs without (sort of) knowing anything about them.

Here's what I mean. Back to the graphics article I mentioned before. Blender (3D) is an open source modeler that had its beginnings 20 years ago.

• http://code.blender.org/index.php/2013/12/how-blender-started-twenty-years-ago/

The creator of that program made his binary data files with "encoded types for the entire internal structure" -- in other words, self-describing and included in the data file. The intention was to make it backwards compatible knowing that future versions of the program will always require inevitable changes to the data file format.

• http://www.blendernation.com/2008/12/01/blender-dna-rna-and-backward-compatibility/
• Blender DNA, RNA and extreme backward compatibility
• "This makes .blend files still readable, even when saved in 1.00"
• This blew my mind.
• 20 years of the application -- and you can still load the data file that was made from v1.00
• Not sure if a v2.71 (current version) data file would load on the v1.00 application, but you get the gist
• Here are details on how this is done (just in case you're interested in how it was done)
• http://wiki.blender.org/index.php/Dev:2.5/Source/Architecture/RNA#DNA_Matching
• http://wiki.blender.org/index.php/Dev:Source/Data_Structures/DNAStructs
• http://wiki.blender.org/index.php/Dev:Source/Architecture/SDNA_Notes

Why strike linked-data and call out the * description languages
Back to "unused information" I mentioned earlier, [for our system] -- the LD stuff will NEVER be used (I can pretty much say that now with 99.9% certainty).

• C/C++/java/etc. however, would HUGELY benefit from a self-describing struct/class object.

So when I started to play with:

• http://json-ld.org/playground/

I said to myself, "this is interesting -- but what is this good for?"" -- I even said ([in part 1]):

• this terse way of representing all of the data [is] highly error prone if written by humans -- this will need to be generated with tools just to be safe

The playground only showed results for JSON-LD and an RDF item.

• But, there seems to be a number of possible representation for the same dataset:
• http://rdf-translator.appspot.com/
  • Raw data: ( CSML | CSV )
  • RDF ( N-Triples | N3/Turtle | JSON | XML )
  • OData ( Atom | JSON )
  • Microdata ( JSON | HTML)
  • JSON-LD
• I thought to myself, there has got to be a better way to create this (remember: highly error prone if written by humans)

Then, the following showed up in [redacted] (today in fact!):

• [link redacted]
• They mentioned hive-json
• This showed how a json ld-ish output was created from (in this case) the apache hive schema

So, out of curiosity, I thought if there were other ways to help write json-ld via converters?

• Here's what I found:
• http://jsonschema.net/reboot/#/
• Write out your 'sample' json data
• Click on the "schemarize" button it to generate the starter "schema"
• Use the schema to help write the json-ld definitions


• There were other resources I scanned through -- not really useful by itself, but helpful to figure out this linked-data stuff
• http://www.w3.org/wiki/ConverterToRdf
• http://notes.3kbo.com/json
• http://www.convertcsv.com/sql-to-csv.htm
• http://www.w3.org/TR/sparql11-update/
• http://www.cambridgesemantics.coam/semantic-university/sparql-by-example

json-ld (part 1 of 3)

Subject: json-ld (part 1 of 3)

• note: originally emailed 05/28/2014 and sanitized for public consumption
• sidenote: posting here so i can lead people here whenever they ask me about this stuff...
• series: part 2 & part 3

---

[Boss,]

Over the weekend, I looked into more about the JSON-LD stuff -- I get what it's doing -- but, we [are not] building a social network nor do we want dynamically generated 'queries' in areas that should be 'sanitized' (input validated, [...] etc.).

That said, the inventor of JSON-LD complained about a lot of things and the reason for creating JSON-LD (but hated on quad store a.k.a. named-graph).

• http://manu.sporny.org/2014/json-ld-origins-2/

I'll getting to the "sparkle" part in just a bit. But, here's a sneak peek:

• http://en.wikipedia.org/wiki/Named_graph

Anyways, if you ever read any of Microsoft's HTML exporter from their Word app you would see things like:

<html xmlns:v="urn:schemas-microsoft-com:vml"
xmlns:o="urn:schemas-microsoft-com:office:office"
xmlns:w="urn:schemas-microsoft-com:office:word"
xmlns:m="http://schemas.microsoft.com/office/2004/12/omml"
xmlns="http://www.w3.org/TR/REC-html40">
<head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><title></title>
<style>
...

See all those xmlns: items?

Those are never used outside of your work, except for tracking purposes outside of your company. To "help" them figure out what you're document "means" instead of just a bunch of "content". This is what is known as the RDF annotation. RDF stands for Resource Description Format -- basically meta data for your content.


So, going back to JSON-LD: they want to transform something like this:

• http://XYZ/ajax/api/path.php?user=name1
• That would return something like this:
• { "result" : "pass", "balance" : "111111" }
• To returning something like this:

  {
      "@context": {
          "name": "http://xmlns.com/foaf/0.1/name",
          "balance": "http://json-ld-server/rdf/0.1/name",
      },
      "name": "X name1",
      "balance": "111111"
  }
  

• In other words, you need to describe what the data is -- instead of just dumping it.
• Do note, this will also mean there's no stopping them from changing the simple ajax request of:
• http://XYZ/ajax/api/path.php?user=name1
• To something more convoluted like:
• POST: http://json-ld-server/
• POSTDATA:

  {
      "@context": {
          "name": "http://xmlns.com/foaf/0.1/name",
          "query": "http://json-ld-server/rdf/0.1/query",
      },
      "name": "X name1",
      "query": "balance"
  }
  

• Again, all meant for systems outside of ours to help them understand our system (i.e. route around/through our data)...

Finally, SPARQL (pronounced -- sparkle) can be seen like this: S(PAR)QL -- which stands for: SPARQL Protocol and RDF Query Language

• This allows you to do all things SQL (CREATE, INSERT, UPDATE, DROP, etc.) with this terse way of representing all of the data (highly error prone if written by humans -- this will need to be generated with tools just to be safe)
• The named-graphic link above earlier, shows some examples -- but it's still means this needs someone to write the query... this is all duplicated work...