4 ms·

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 conferenc

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 serialization syntax, it share every of its issues. Main issues are: - 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. - no annotations, which mean you cannot represent simple graph construct such as a weighted edge. - 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. - reliance on the web infrastructure (IRI, DNS, web servers, ...) which is a big dependency with a lot of gotchas and not fitted for every uses cases (self contained data for example) - 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. Also, the second sentence of the article is totally false. I read the history of JSON-LD by one of its main author [1], and it does not originated in the RDF community. It originated elsewhere, and then there was RDF people included in the loop. [1] http://manu.sporny.org/2014/json-ld-origins-2/ http://manu.sporny.org/2014/json-ld-origins-2/

Boulth 8y ago
Is there a reasonable alternative? I've worked with RDF and LD and can agree with most of your points but would like to see if there is something better on the horizon.
- titanix2 8y ago
  Currently no. I am concerned with making dictionaries better (especially mobile applications), so I don't have a general purpose solution but I propose something for that use case. I basically started from scratch and came up with a very simple type system which aggregates a few values (name, id, type, ...). This type system is not hierarchical so no inheritance; you could implement it with a few classes in a OO language. Also, nodes can host complex structure but do not expose it to the graph (edges are made only between nodes) and edge can be of n-arity. The system is regular enough to implement simple and complex lexicographic constructs easily as well as to use the graph in an actual application. Issue with RDF et al if that before you start even working on your real data, you have to come up with an ontology, that is to describe the world in categories, which is not easy. Another problem is that a lot of projects want to define standards that works with everything. That's not realistic. So I took an approach where you can learn from your domain by working directly on your data, make something useful with it, and then expand it you need it. KISS.
  - rjsw 8y ago
    There are plenty of ontologies already defined that someone could use. I'm currently involved in work to map STEP [1] onto RDF/OWL/SKOS and it seems to be working out well. I know that some of my collegues are using JSON-LD as the interchange format for this kind of thing. [1] https://en.wikipedia.org/wiki/ISO_10303 https://en.wikipedia.org/wiki/ISO_10303
    - titanix2 8y ago
      It totally depends on what you are doing. You need to take in account if using an ontology will solve any problem at hand. Also you may have an ontological system not build in RDF. At least in what I'm doing, RDF is creating more problems than it solves. Finally there is all the political layer that may go against publishing your data in an open and (web) accessible format and then you need another solution anyway.
      - lolive 8y ago
        To counter the argument of opening data to the outside world, LinkedOpenData has been studied inside companies. I.e opening only inside the walled garden. And guess what? It failed. Simply because companies are not organized so data can "travel" flawlessly. Companies are organized as silos. With boundaries & (implicit) contracts between people, teams, hierarchies. Of course, everyone knows the information is somewhere here or there, but eventually it is a real hard job to get it for real.
  - dozzie 8y ago
    All this sort of sounds like topic maps, though they never gained much of attention and very few people know of or remember them, and beside Java there are virtually no libraries or tooling for them.
  - lolive 8y ago
    Ontologies first is an idiocy! Whenever you deal with a real data environment, you discover that your use cases drive your data model. Not the opposite way. For example, the DBPedia ontology is plainly wrong (or outdated, I don't know). If you want the real data model, you really should infer it from the data itself (Guess what, you CAN do that. Because proper RDF auto-describes its data model. But it is a lot of work). The more i deal with data, the more i realize that the exposed data models are not matching the data. And that is a SHAME for whoever calls himself/herself a data engineer.
- tannhaeuser 8y ago
  Prolog + Datalog? Prolog should even parse JSON without 3rd party libs with minimal fuss using just its integrated parser construction facilities (eg. the `op` built-in predicate). Prolog won't come with reasoners for the description logic profiles supported by OWL 2 (EL, RL), but can be used to implement such reasoners if needed.
TheAceOfHearts 8y ago
I don't know what MP means, but if you publish an article I'd be interested in checking it out.
- titanix2 8y ago
  I thought hacker news had private messages but no (and well MP is French, so my mistake it should have been PM), so send me a mail at the address found in my profile https://news.ycombinator.com/user?id=titanix2 https://news.ycombinator.com/user?id=titanix2 so I can contact you back.
  - jonawesomegreen 8y ago
    I'd also be interested in the article if you publish one, but I don't see any email in your profile. I believe only the `about` section is displayed publicly.
    - titanix2 8y ago
      Ah yes, the email field is not displayed. Fixed.
vfaronov 8y ago
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/ 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.
- titanix2 8y ago
  > RDF was not designed for arbitrary graphs. Exactly. That's my exact point. So, now, my problem is other scholars asking "why don't you use our model X or Y based of RDF" when the only thing I care about is the graph part. And I don't use RDF because of the points I exposed earlier. I should I've put emphasis that I'm working in a given field (lexicography), and that the RDF issues I face may be irrelevant for some other use cases. As for the JSON-LD origin I stand correct.
igravious 8y ago
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-information-on-the-poolparty-api/rdf-serialization-formats 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 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 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.
lolive 8y ago
The point is that all those problems are strictly worse with plain JSON.
- lolive 8y ago
  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.
  - lolive 8y ago
    Here is a small primer that i wrote on HN about N3: https://news.ycombinator.com/item?id=14476070 https://news.ycombinator.com/item?id=14476070 (as you can see, nothing very complex :)
    - lolive 8y ago
      Oh, and for your information, N3 has always had a reification syntax. For example: { [ x:firstname "Ora" ] dc:wrote [ dc:title "Moby Dick" ] } a n3:falsehood . PS: yep, there are blank nodes here. PPS: very few parsers take this into account, I agree. But I am pretty sure N3.parse() does.

Boulth 8y ago

Is there a reasonable alternative? I've worked with RDF and LD and can agree with most of your points but would like to see if there is something better on the horizon.

titanix2 8y ago
Currently no. I am concerned with making dictionaries better (especially mobile applications), so I don't have a general purpose solution but I propose something for that use case. I basically started from scratch and came up with a very simple type system which aggregates a few values (name, id, type, ...). This type system is not hierarchical so no inheritance; you could implement it with a few classes in a OO language. Also, nodes can host complex structure but do not expose it to the graph (edges are made only between nodes) and edge can be of n-arity. The system is regular enough to implement simple and complex lexicographic constructs easily as well as to use the graph in an actual application. Issue with RDF et al if that before you start even working on your real data, you have to come up with an ontology, that is to describe the world in categories, which is not easy. Another problem is that a lot of projects want to define standards that works with everything. That's not realistic. So I took an approach where you can learn from your domain by working directly on your data, make something useful with it, and then expand it you need it. KISS.
- rjsw 8y ago
  There are plenty of ontologies already defined that someone could use. I'm currently involved in work to map STEP [1] onto RDF/OWL/SKOS and it seems to be working out well. I know that some of my collegues are using JSON-LD as the interchange format for this kind of thing. [1] https://en.wikipedia.org/wiki/ISO_10303 https://en.wikipedia.org/wiki/ISO_10303
  - titanix2 8y ago
    It totally depends on what you are doing. You need to take in account if using an ontology will solve any problem at hand. Also you may have an ontological system not build in RDF. At least in what I'm doing, RDF is creating more problems than it solves. Finally there is all the political layer that may go against publishing your data in an open and (web) accessible format and then you need another solution anyway.
    - lolive 8y ago
      To counter the argument of opening data to the outside world, LinkedOpenData has been studied inside companies. I.e opening only inside the walled garden. And guess what? It failed. Simply because companies are not organized so data can "travel" flawlessly. Companies are organized as silos. With boundaries & (implicit) contracts between people, teams, hierarchies. Of course, everyone knows the information is somewhere here or there, but eventually it is a real hard job to get it for real.
- dozzie 8y ago
  All this sort of sounds like topic maps, though they never gained much of attention and very few people know of or remember them, and beside Java there are virtually no libraries or tooling for them.
- lolive 8y ago
  Ontologies first is an idiocy! Whenever you deal with a real data environment, you discover that your use cases drive your data model. Not the opposite way. For example, the DBPedia ontology is plainly wrong (or outdated, I don't know). If you want the real data model, you really should infer it from the data itself (Guess what, you CAN do that. Because proper RDF auto-describes its data model. But it is a lot of work). The more i deal with data, the more i realize that the exposed data models are not matching the data. And that is a SHAME for whoever calls himself/herself a data engineer.
tannhaeuser 8y ago
Prolog + Datalog? Prolog should even parse JSON without 3rd party libs with minimal fuss using just its integrated parser construction facilities (eg. the `op` built-in predicate). Prolog won't come with reasoners for the description logic profiles supported by OWL 2 (EL, RL), but can be used to implement such reasoners if needed.

TheAceOfHearts 8y ago

I don't know what MP means, but if you publish an article I'd be interested in checking it out.

titanix2 8y ago
I thought hacker news had private messages but no (and well MP is French, so my mistake it should have been PM), so send me a mail at the address found in my profile https://news.ycombinator.com/user?id=titanix2 https://news.ycombinator.com/user?id=titanix2 so I can contact you back.
- jonawesomegreen 8y ago
  I'd also be interested in the article if you publish one, but I don't see any email in your profile. I believe only the `about` section is displayed publicly.
  - titanix2 8y ago
    Ah yes, the email field is not displayed. Fixed.

vfaronov 8y ago

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/ 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.

titanix2 8y ago
> RDF was not designed for arbitrary graphs. Exactly. That's my exact point. So, now, my problem is other scholars asking "why don't you use our model X or Y based of RDF" when the only thing I care about is the graph part. And I don't use RDF because of the points I exposed earlier. I should I've put emphasis that I'm working in a given field (lexicography), and that the RDF issues I face may be irrelevant for some other use cases. As for the JSON-LD origin I stand correct.

igravious 8y ago

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-information-on-the-poolparty-api/rdf-serialization-formats 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 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 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.

lolive 8y ago

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

lolive 8y ago
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.
- lolive 8y ago
  Here is a small primer that i wrote on HN about N3: https://news.ycombinator.com/item?id=14476070 https://news.ycombinator.com/item?id=14476070 (as you can see, nothing very complex :)
  - lolive 8y ago
    Oh, and for your information, N3 has always had a reification syntax. For example: { [ x:firstname "Ora" ] dc:wrote [ dc:title "Moby Dick" ] } a n3:falsehood . PS: yep, there are blank nodes here. PPS: very few parsers take this into account, I agree. But I am pretty sure N3.parse() does.