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

31–40 of 64 posts

Re: Publishing JSON-LD for Developers

#31

Post by titanix2 »

jshen wrote: post #29
titanix2 wrote: post #8

Earlier quoted context omitted.

> 3. What benefit does RDF in any format provide to the average web developer? Probably (almost) none, otherwise in its 20 years of existence it would have been used somewhere. Heck, even Semantic Web scholars actually don't use it for their own personal websites...

It provides a lot of benefits, see my other comment on this thread for a few specific benefits.

I read your post and you rose valid points.

I think one problem though is that RDF is a solution searching for a problem to solve. It's clear it was designed from some abstract space instead to be a solution evolving from real use cases. And that's why most people have a hard time understand it, and even more putting it in practice.

For example, even basic RDF concepts such as a resource are hard to grasp. You have an IRI, great, but should it be dereferenceable? If yes, what it expected to be returned: a document in various formats or more RDF triples? If not (URN case), what to do with it? All these problematics are not addressed in the spec itself but must be understood before even starting to implement a hello world.

There is interesting projects such as DBpedia. Another problem of RDF is social and pertains to its advocates: trying to impose the technology everywhere without taking in account the audience needs nor the limitations of the technology itself is not going to work great. See the suggestions made during this workshop to improve the technology: https://www.w3.org/2009/12/rdf-ws/ In 9 years (half of its live), nothing was addressed.

Re: Publishing JSON-LD for Developers

#33

Post by jshen »

titanix2 wrote: post #31
jshen wrote: post #29

Earlier quoted context omitted.

It provides a lot of benefits, see my other comment on this thread for a few specific benefits.

I read your post and you rose valid points. I think one problem though is that RDF is a solution searching for a problem to solve. It's clear it was designed from some abstract space instead to be a solution evolving from real use cases. And that's why most people have a hard time understand it, and even more putting it in practice. For example, even basic RDF concepts such as a resource are hard to grasp. You have a…

I think it solves a real problem. I work at a large company, with many data silos. I’ve had to hire armies of interns to match in merge data over the years because it wasn’t possible to automate the merging of data from different databases.

I agree with your other points though, people have a hard time understanding it, and the community hasn’t really shown the value. My hobby project is an effort to show the value, but it’s not ready to share yet.

And yes, there’s a lot of confusion things (URI vs URL, dereference or not) that the community hasn’t done a good job articulating a happy path. There’s another you didn’t mention, there’s an impedance mismatch between triples and resources. One is property oriented, and the other entity oriented, and they dont’ always play nice together.

Re: Publishing JSON-LD for Developers

#34

Post by Boulth »

neurotrace wrote: post #22
Boulth wrote: post #5

Earlier quoted context omitted.

1. This is not a schema language. 2. Context is for shortcuts, all properties can be expanded to full names but these are qualified and long. 3. Benefit over what? RDF is for describing things with machine readable language.

1. The article states that the `@context` is basically a schema and JSON-LD provides a consistent way of formatting JSON data. Sounds a lot like a schema for JSON. 2. Okay, so you either put the long data in the `@context` or in the original data. I suppose it may improve readability but for a data interchange format (which I believe this is), it seems wasteful. 3. Benefit in general. Why would I use RDF at all? What…

I think it's useful to put this into perspective, if you're designing a format for your backend and frontend you don't need semantic data. If you're one party providing API to others you don't need it too. But if there is an ecosystem of independent parties providing and consuming data there is a need for a way of describing meaning of your fields. By meaning I don't mean "field X is ISO time" (that would be JSON schema) but rather "field X is date of birth".

As for practical uses JSON-LD is used by Google to scrape things from the internet, and check if they got a Place here, Person or maybe a Business. Activitypub that powers Mastodon is also JSON-LD.

Re: Publishing JSON-LD for Developers

#35

Post by jshen »

jerf wrote: post #23
talltimtom wrote: post #21

Only slightly related bit does anyone have a good current take on how to get going on using RDF for something of value? I recently got interested through a colleague showing off his pet rdf setup, but the more I read the more I am just confused with the platora of dead/abandoned and renamed projects, different standards and tons of different shorter versions like this one. It really feels like everything on the topic…

RDF is a zombie format. It isn't entirely "dead" but after some wildly ambitious promises, it hasn't lived up to any of them, and it seems only a few "true believers" are still working with it. This being a world of seven billion people, a few "true believers" can still be a few thousand people, but it's just not a technology I can say is vibrant, alive, or worth spending much time with. The core problem is that it s…

RDF solves very real problems, see my other comment in this thread for a list of a few of them. A graph database does not solve those problems in any way.

I also find it strange to call it dead when companies like google and facebook are using it for metadata on content to power their core products. Again, a graph database does not solve that.

Re: Publishing JSON-LD for Developers

#36

Post by vfaronov »

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…

RDF was not designed for arbitrary graphs. It was specifically designed for resource descriptions on the Semantic Web.

> reliance on the web infrastructure (IRI, DNS, web servers, ...)

This is the whole point of RDF. It is what enables Linked Data.

> I read the history of JSON-LD by one of its main author [1], and it does not originated in the RDF community.

Not sure what you mean exactly, but here’s from http://manu.sporny.org/2014/json-ld-origins/:

> JSON-LD started around late 2008 as the work on RDFa 1.0 was wrapping up. We were under pressure [...] to come up with a good way of programming against RDFa data.

JSON-LD definitely was always an RDF serialization, created by people intimately familiar with RDF and the Semantic Web.

Re: Publishing JSON-LD for Developers

#37

Post by titanix2 »

jshen wrote: post #33
titanix2 wrote: post #31

Earlier quoted context omitted.

I read your post and you rose valid points. I think one problem though is that RDF is a solution searching for a problem to solve. It's clear it was designed from some abstract space instead to be a solution evolving from real use cases. And that's why most people have a hard time understand it, and even more putting it in practice. For example, even basic RDF concepts such as a resource are hard to grasp. You have a…

I think it solves a real problem. I work at a large company, with many data silos. I’ve had to hire armies of interns to match in merge data over the years because it wasn’t possible to automate the merging of data from different databases. I agree with your other points though, people have a hard time understanding it, and the community hasn’t really shown the value. My hobby project is an effort to show the value,…

Of course I don't know every issues but sure I forgot some. Difficulty of making reification for example. Anyway, I will be glad to hear about your project when it's published.

Re: Publishing JSON-LD for Developers

#38

Post by igravious »

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

Re: Publishing JSON-LD for Developers

#39

Post by vfaronov »

yoklov wrote: post #3

For an argument against using JSON-LD, see https://hsivonen.fi/no-json-ns/

This article does not have a valid argument against using JSON-LD.

It may be read as an argument against making namespaces a ubiquitous part of JSON, in the same way as they are ubiquitous in XML (even though not part of the base XML spec). It’s a valid argument against getting to the point where namespaces pop up in every JSON tutorial, and every JSON serializer takes a namespace map, and every user of JSON has to deal with them.

But JSON-LD (as RDF) uses namespaces to solve a particular problem (merging data from disparate sources). Solutions involve costs, that’s normal. You might weigh this cost against the expected payoff and decide it’s not worth it for you — but the article doesn’t do that.

Re: Publishing JSON-LD for Developers

#40

Post by harlanji »

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/blob/master/clojure/Clo... (EDN is a subset of Clojure).

Sorry if this is too fanboy, I just need to assume people aren’t aware when I see this big pile of mud that is JSON.

Post reply on HN