Live data from Hacker News

Publishing JSON-LD for Developers

datalanguage.com

61–64 of 64 posts

Re: Publishing JSON-LD for Developers

#61
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…

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

Re: Publishing JSON-LD for Developers

#62

Earlier quoted context omitted.

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…

I'll reply to you without quoting everything to make it more readable. First, the paper is already accepted and is not about RDF per se. I know about the serialization formats and none of them will fit my needs because the problem lies in the data model, not a concrete syntax. I don't really understand the point you try to make about literals. Mine is that because literals cannot be the origin of an edge, they form s…

> I know about the serialization formats and none of them will fit my needs because the problem lies in the data model, not a concrete syntax. I don't really understand the point you try to make about literals.

So create your own serialization format suited to your own needs.

> I don't really understand the point you try to make about literals. Mine is that because literals cannot be the origin of an edge, they form sinks. And that's very annoying for building a graph (of strings) because you then need to create proxy nodes for data all the way up.

If by origin you mean what RDF calls subject then yes, as I said, the RDF data model does not support subject literals. That is by design. What you could do is create a resource that encapsulates strings in the way you want a use that for both the subject and object. Don't think them as proxy nodes, think of it like you now have the ability decorate your string literals in an extensible way.

> For annotations, you can read[1]. What I meant however a really simple graph construct: information on edges. In the Neo4j lingo that is called a property[2]. There absence in RDF make it difficult to represent situations such "Paris"---distance:54---"Rennes".

    PREFIX distance: 

   [wdt:Q90 distance:354 wdt:Q647]
Because Paris and Rennes are already in Wikidata, why not use them? Create your own namespace, call the distance property "distance" when you're prefixing it, reserve numerals in this property to signify geographical magnitude in km. 354 between Paris and Rennes, not 54?

> I'm visibly not the only one it's itching[5].

Two wrongs don't make a right. Considering that link was calling for this in 2010 suggest to me that you oughtn't hold your breath. Also them self-describing as an expert is crass.

> Yes you can use URN, be some projects doesn't support them.

Well, that is not the fault of RDF now is it?

> Moreover, renting a domain (you can't buy a domain name) may be cheap but why putting this burden on yourself if you can avoid it?

If you can't afford €10 per year or the institution where your project is located can't afford it then you have bigger problems than imaginary RDF restrictions.

> Anyway I'll be curious to see something you built with RDF, if any. I failed to find your work besides two papers that aren't related to the subject.

I've used Wikidata and DBpedia to build a corpus of philosophers and their philosophical texts without too much of a problem once I wrapped my head around how RDF and SPARQL work.

Paris on Wikidata: https://www.wikidata.org/wiki/Q90

Rennes on Wikidata: https://www.wikidata.org/wiki/Q647

Re: Publishing JSON-LD for Developers

#63
post #6

Earlier quoted context omitted.

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.

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 lang…

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.

Re: Publishing JSON-LD for Developers

#64

Earlier quoted context omitted.

I'll reply to you without quoting everything to make it more readable. First, the paper is already accepted and is not about RDF per se. I know about the serialization formats and none of them will fit my needs because the problem lies in the data model, not a concrete syntax. I don't really understand the point you try to make about literals. Mine is that because literals cannot be the origin of an edge, they form s…

> I know about the serialization formats and none of them will fit my needs because the problem lies in the data model, not a concrete syntax. I don't really understand the point you try to make about literals. So create your own serialization format suited to your own needs. > I don't really understand the point you try to make about literals. Mine is that because literals cannot be the origin of an edge, they form…

You are changing the problem at hand. It is not how to create a distance relation, it is how to add more data to an existing edge. To do that in RDF you need reification, which is notoriously painful[1]. Moreover " rel="nofollow">http://www.my_cool_domain.fr/prop/distance54> is not equal to "54" and 54 cannot be inferred from it because URI are opaques. In addition, you have now a totally different property than those of every pair of cities that are not 54 km afar. So, RDF have some strengths and good points but in the current case it is creating unnecessary problems to encode a very simple situation.

[1] https://www.safaribooksonline.com/library/view/practical-rdf...

Post reply on HN