Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Publishing JSON-LD for Developers

datalanguage.com

Post reply on HN
Print view View original

41–50 of 64 posts

Re: Publishing JSON-LD for Developers

#41

Post by igravious »

titanix2 wrote: post #4

I'm working on language ressources and graphs and in my opinion, RDF is so flawed you shouldn't even bother with it. I will address the topic during a conference in June (email me -- info in my profile -- for follow up or to get my articles if you're interested by the topic). JSON-LD is trying to make RDF sexier (more exactly said, RDF try to pimp itself by using JSON-LD) but as it is just RDF with a new serializatio…

If I were you I would not deliver that paper. Especially if these are the points you are going to be making.

> JSON-LD is trying to make RDF sexier (more exactly said, RDF try to pimp itself by using JSON-LD) but as it is just RDF with a new serialization syntax, it share every of its issues.

JSON-LD is _only_ a serialization format. Look, here are _nine_ others. https://help.poolparty.biz/doc/developer-guide/general-infor... Choose the one that best suits your needs. And using language like sexier and pimp, words fail me.

> a literal node (strings which carry the useful information for an human) cannot be the source of an edge, so you end up creating "resources" nodes and pushing content as leaf of the graph. Access to its is thus done with a lot of indirections.

What you mean here is that in the [S, P, O] resource, where S is the subject and P is the predicate and O is the object, one can't make the Subject a string literal. No you can't. Big deal. Whatever language and language framework you're using should have an abstraction for unpacking string literals, and if it doesn't you can roll your own. The semantics of RDF are that literal values are Objects. This is because in natural language we tend to say things like [User5000, is called, "titanix2"] and not ["titanix2", is the name of, User5000]. Sorry if you don't like it, that's the convention: https://www.w3.org/TR/rdf11-concepts/#section-Graph-Literal

> no annotations, which mean you cannot represent simple graph construct such as a weighted edge.

No idea what this means

> blank nodes, needed to join more than two piece of data which, are anonymous so they are difficult to reuse. That's sad because a graph is supposed to make data link each other. Coupled with issue 1, it mean most linguistic resources graphs are actually closer to trees than real graphs.

I didn't get how blank nodes worked originally and made myself look like a fool when I questioned how they worked on a mailing list. Such is life. They actually make sense for what they do once you wrap your head around them. Rather than me explaining them to you here I urge you consider how they work again: https://www.w3.org/TR/rdf11-concepts/#section-blank-nodes

> reliance on the web infrastructure […]

Well, it's not called the semantic web for nothing! Also, it's been pointed out to me that one can use URNs instead of URLs if you don't want to use the semantics of the HTTP schema. But you know what it seems to be working for pretty much everybody else and how expensive is it to but a domain these days?

> performances is abyssal. I tried one of the dictionary build on RDF, and some query took up to 40 seconds (!) to return no result. Even bloated web dictionaries perform under 2 seconds.

Without further details I'd have to presume you're talking about SPARQL? Yes some queries are slow but if you're dealing with millions or billions of triples then that's inevitable. I've discovered that you can optimize SPARQL once you start digging into it. No it's not easy, but it's not exactly simple tech either. Without details about the triple-store you were querying against and the query you used there's nothing more I can help you with. Anyway, your complaint is like you having a slow query on some particular relational database and you blame the entirety of SQL, wow.

Re: Publishing JSON-LD for Developers

#42

Post by dogweather »

igravious wrote: post #38
dogweather wrote: post #24

I've been developing a strongly-typed Ruby library for generating JSON-LD that might be interesting or useful: https://github.com/public-law/schema-dot-org

Awesome, I love messing with Ruby and semantic web stuff. Thanks for posting this. Could you explain more? How do you implement the strongly-typed feature? How does it interoperate with the Ruby-RDF library? https://github.com/ruby-rdf

Here's a quick example. Put this in a Rails template:
...and you'll see this in the HTML:

  
  {
    "@context": "http://schema.org",
    "@type": "WebSite",
    "name": "Texas Public Law",
    "url": "https://texas.public.law"
  }
This DRY's up my code - I just encode the right way of forming JSON-LD and the correct objects and attributes in one place, the library. (That JSON-LD is from my live site, https://texas.public.law)

Details:

First I created a small library which wraps Rails ActiveModel Validations so they can be used in any Ruby object. And I supply a new validator, TypeValidator.

https://github.com/public-law/validated_object

With this building block, I can create classes for each Schema type I care about. And they strictly enforce their attributes:

  class Organization
That's a little redundant, but to a Rails developer, it's immediately clear what's going on. The full Organization code: https://github.com/public-law/schema-dot-org/blob/master/lib...

I'm not using Ruby-RDF at all. I looked into the current Ruby meta-data and strong typing work, and found it all too complex for my simpler use case:

I'm creating websites, and I want to embed correct JSON-LD-formatted schema.org in a rock-solid way: (1) Correct syntax, and (2) correct semantics. I've got the information as Rails models and objects, and I need to convert this to HTML/JSON-LD.

So all of these objects, like Organization above, recursively creates proper markup in response to #to_s:
...instantiated from that class above, will result in this in the generated HTML page:

  
  {
    "@context": "http://schema.org",
    "@type": "Organization",
etc.

https://github.com/public-law/schema-dot-org#usage

Re: Publishing JSON-LD for Developers

#43

Post by igravious »

harlanji wrote: post #40

Please forgive me if off topic. I feel EDN deserves some love. Unsure if it’s lack of awareness or what. Defrecord with type hints is enough for most projects, esp. the data models. The collection types are complete and there are also comments, namespaces, and tags. The grammar is also short, simple and easy. Spec: https://github.com/edn-format/edn/blob/master/README.md Grammar: https://github.com/antlr/grammars-v4/b…

No worries, it is slightly off-topic though :) JSON-LD is a JSON format for the serialization of linked data, not a general data interchange format like JSON itself. Presumably an EDN fanboy could come up with EDN-LD without too much trouble if they so desired. I linked this elsewhere but here are nine other RDF serialization formats that you could model EDN-LD on: https://help.poolparty.biz/doc/developer-guide/general-infor... if it ever comes into being.

Re: Publishing JSON-LD for Developers

#44

Post by igravious »

TheAceOfHearts wrote: post #7

Try leading with an explanation of why developers should care about JSON-LD. Its value is not obvious to me. According to the Wikipedia article [0] this is used by Google Knowledge Graph, but there's no other examples. Are there open source RDF processors? What are they used for? Previously I've used json-schema for documenting, validating, and testing a REST API. The tooling wasn't very good, but it worked alright.…

Here: https://json-ld.org/

JSON-LD is JSON for Linking Data.

When you're passing semantic web data around or maybe storing it temporarily in a text file (rather than in a triple-store) one of the formats you can use is JSON-LD. So that covers when you use it; the next question is why you use it over one of the other interchange or at rest formats. And generally the answer to that is that you're using Javascript as your language and you hate XML :)

Anyway, less facetiously here is the blurb from the website!

“Linked Data empowers people that publish and use information on the Web. It is a way to create a network of standards-based, machine-readable data across Web sites. It allows an application to start at one piece of Linked Data, and follow embedded links to other pieces of Linked Data that are hosted on different sites across the Web.”

“JSON-LD is a lightweight Linked Data format. It is easy for humans to read and write. It is based on the already successful JSON format and provides a way to help JSON data interoperate at Web-scale. JSON-LD is an ideal data format for programming environments, REST Web services, and unstructured databases such as CouchDB and MongoDB.”

Re: Publishing JSON-LD for Developers

#45

Post by vfaronov »

jshen wrote: post #28
TheAceOfHearts wrote: post #7

Try leading with an explanation of why developers should care about JSON-LD. Its value is not obvious to me. According to the Wikipedia article [0] this is used by Google Knowledge Graph, but there's no other examples. Are there open source RDF processors? What are they used for? Previously I've used json-schema for documenting, validating, and testing a REST API. The tooling wasn't very good, but it worked alright.…

The main benefit in my eyes is data integration. If you have multiple systems with data, and you want to merge the data together into a unified whole for some reason then RDF/JSON-LD make it easy and mostly automatic. For example: 1. How do you distinguish IDs from one system with those of another? RDF solves this. 2. How do you distinguish property names across systems? RDF solves this. 3. What if a entity originate…

Outstanding explanation. I would like to emphasize one point:

> If you have multiple systems with data, and you want to merge the data together into a unified whole for some reason

This isn’t just about “big data” or “data warehousing” or such OLAPy concerns. It’s really about the bread and butter of modern information systems.

“Get some ID from service A, use it to query service B.” Does that sound familiar? That’s data integration for you. That’s what RDF / Linked Data is about.

Re: Publishing JSON-LD for Developers

#46

Post by dogweather »

TheAceOfHearts wrote: post #7

Try leading with an explanation of why developers should care about JSON-LD. Its value is not obvious to me. According to the Wikipedia article [0] this is used by Google Knowledge Graph, but there's no other examples. Are there open source RDF processors? What are they used for? Previously I've used json-schema for documenting, validating, and testing a REST API. The tooling wasn't very good, but it worked alright.…

> why developers should care about JSON-LD. Its value is not obvious to me.

This is at a lower level of abstraction, but... I care simply because it's Google's preferred encoding for web publishers to communicate metadata to them:

https://developers.google.com/search/docs/guides/intro-struc...

Re: Publishing JSON-LD for Developers

#47

Post by igravious »

dogweather wrote: post #42
igravious wrote: post #38

Earlier quoted context omitted.

Awesome, I love messing with Ruby and semantic web stuff. Thanks for posting this. Could you explain more? How do you implement the strongly-typed feature? How does it interoperate with the Ruby-RDF library? https://github.com/ruby-rdf

Here's a quick example. Put this in a Rails template: ...and you'll see this in the HTML: { "@context": "http://schema.org", "@type": "WebSite", "name": "Texas Public Law", "url": "https://texas.public.law" } This DRY's up my code - I just encode the right way of forming JSON-LD and the correct objects and attributes in one place, the library. (That JSON-LD is from my live site, https://texas.public.law ) Details: Fi…

Thanks for the in-depth explanation. Sounds really great. I'll add it to my Ruby RDF toolkit.

What do you think of Spira https://github.com/ruby-rdf/spira , does it complement what you are doing in any way?

Re: Publishing JSON-LD for Developers

#48

Post by lolive »

titanix2 wrote: post #4

I'm working on language ressources and graphs and in my opinion, RDF is so flawed you shouldn't even bother with it. I will address the topic during a conference in June (email me -- info in my profile -- for follow up or to get my articles if you're interested by the topic). JSON-LD is trying to make RDF sexier (more exactly said, RDF try to pimp itself by using JSON-LD) but as it is just RDF with a new serializatio…

The point is that all those problems are strictly worse with plain JSON.

Re: Publishing JSON-LD for Developers

#49

Post by lolive »

lolive wrote: post #48
titanix2 wrote: post #4

I'm working on language ressources and graphs and in my opinion, RDF is so flawed you shouldn't even bother with it. I will address the topic during a conference in June (email me -- info in my profile -- for follow up or to get my articles if you're interested by the topic). JSON-LD is trying to make RDF sexier (more exactly said, RDF try to pimp itself by using JSON-LD) but as it is just RDF with a new serializatio…

The point is that all those problems are strictly worse with plain JSON.

Ok, to be fair, I would say that JSON-LD could solve the problem of sending typed data through the wire once we have typed-contracts between server and client (for example when everybody switches from JS+REST to TS+Swagger).

Imho, JSON-LD is a piece of crap (because it is based on JSON, that is flawed by design). So I would definitely promote the usage of RDF/N3 (and its N3.parse()) as the way to go when you need to transmit typed graphs from server to client.

Note: N3 is a dialect of RDF, that is super easy to serialize and deserialize, that builds graphs of objects in memory (which JSON cannot do, because it can only describe trees). And that (almost always) follows a normalized vocabulary for types, IDs and labels.

Re: Publishing JSON-LD for Developers

#50

Post by lolive »

lolive wrote: post #49
lolive wrote: post #48

Earlier quoted context omitted.

The point is that all those problems are strictly worse with plain JSON.

Ok, to be fair, I would say that JSON-LD could solve the problem of sending typed data through the wire once we have typed-contracts between server and client (for example when everybody switches from JS+REST to TS+Swagger). Imho, JSON-LD is a piece of crap (because it is based on JSON, that is flawed by design). So I would definitely promote the usage of RDF/N3 (and its N3.parse()) as the way to go when you need to…

Here is a small primer that i wrote on HN about N3: https://news.ycombinator.com/item?id=14476070

(as you can see, nothing very complex :)

Post reply on HN