Using JSON-LD to represent the routes

[luispc1998]

This issue was requested by @labra to talk about the file format decision exposed in #21

We have identify this as a tradeoff, therefore we can point out advantages and disadvantages.

One the one hand, it is just a json with a "@context" property, we have already learned how to handle this format in the degree. Futhermore, javascript has a built-in object called JSON, that can help us with the parsing of the file.

On the other hand, JSON-LDis not yet supported by the pod, what does this mean? The POD cannot show its contents as a turtle file, that is we cannot navigate the data graph.

Summing up, we can use a format we are familiar with, really well documented, and based in something that it is really common, as it is JSON. As temporal consequence of that, we don't have support for it in the pod (but it can store it without any problem). Why I say temporal? The POD specification stated that it must support JSON-LD so if we use it correctly, eventually the POD will be able to manage it.

JSON-LD specification: https://www.w3.org/TR/json-ld/

[Raulpemol]

We can use solid-file-client library to handle reading and writing JSON-LDs in the POD, so I believe using this format is a really convenient approach

[Angelixus]

I don´t really see the downside when it comes to the POD not supporting JSON-LD, It does not matter that the POD itself does not support that, the data graph will be navigated using external libraries, not the POD itself. It is true that a user using its POD will not be able to navigate the data graph using the POD itself but, usually, end users will not have the need to do that.

[agmrezz]

As Angel says, the file will be navigated by our app, not the POD directly. The POD not supporting JSON-LD yet does not affect our goal, and it will be supported in the future anyway.

[christianpe98]

So you're proposing JSON-LD as the main format for serializing routes in RDF? If this is so, I disagree. I believe that the base format for representing the routes should be Turtle, a format supported by the PODs and which has been used as an example, which many groups have followed, in the specification. In addition, a change of this scope almost at the end of the second deliverable would be critical for the development of many applications.

[Raulpemol]

As you say, it is a bit late to start discussing about this. If everyone had participated since the creation of this repo it would be much easier to make our applications interoperable. When starting to work on the 0.1 deliverable, my group proposed an standard which has been discussed and extended since then, as you can see in other issues of this same repo. As no other standard was proposed, some groups also started working with it. Better late than never, se are open to read about your proposal and discuss It in order to provide the desired interoperability. However, if every group works by its own and don't communicate with the others, it will be impossible.

[uo265363]

We prefer using the json-ld as @luispc1998 has proposed because it's way more easy to handle. It doesn't matter that the POD doesn't support the json-ld, the app users are not going to read the data directly from their pods, the idea is to make it simpler through our app, a non technical user is not going to be able to understand the pod's data with the turtle syntax.What's the point on using turtle instead?

[gemarico]

As Christian says, I dont agree to use a file format not supported by the solid Pods, that's why in my group we use Turtle. I also think the common specification should have been done in the early stages of the development since right now there is general confusion about the specification and that delays the development of our applications.
Changing the namespaces or redefine some small issues is something we can afford, since we are in the end of the 2nd sprint, but changing the file format use to stored our files in the pod would have a mayor impact in our application.

[Raulpemol]

As @luispc1998 said, if hoy read the specification of Solid, JSON-LD must be supported in the future by the POD's interface. Therefore, this is neither a final nor a severe disadvantage

[agmrezz]

Solid spec repo: https://github.com/solid/solid-spec

Content Representation:

Linked Data resources (RDF in the form of JSON-LD, Turtle, HTML+RDFa, etc)

[uo258865]

The examples in the specification are in Turtle, so many groups use it because of this, you can see it here: https://arquisoft.github.io/viadeSpec/#dataModel

[christianpe98]

In view of the different opinions, perhaps we should start to consider solutions that do not affect anyone negatively.

[christianpe98]

I propose to implement 2 parsers:

• JSON-LD to Turtle
• Turtle to JSON-LD

When the group saving the routes in Turtle searches for a route on the POD and it is in JSON-LD format it will use the JSON-LD to Turtle parser and receive a Turtle object.
When the group that saves the routes in JSON-LD looks for a route in the POD and is in Turtle format it will use the JSON-LD Turtle parser and receive a JSON-LD object.
Each application would only have one external layer added to it which when reading a file would call a parser or not, so it would not affect it much.
What do you think?

[CarmenVigo]

I was thinking the same @christianpe98 I support that solution.

[fincamd]

Listen everyone,

First things first, I am not here to complain about the standard. I wouldn't have any rights whatsoever because I didn't take part in creating it. I am here to talk about those of you appearing out of the blue here and there criticising these people's hard work.

I am here to complain about people that has never been seen around here nor said nothing until this precise moment in which this poor guy proposes a solution that apparently is not suitable for many people.

As the teacher said, this is a proposal for a standard to provide our apps with interoperability, it is up to you whether you follow it or not, but don't throw people's job and ideas to the ground. And I am sorry for those of you having to withstand this non-sense. My apologies... but I had to.

Peace

[gemarico]

@fincamd For my part in this issue, i didnt criticise the work these people did. I just express my opinion in the matter. Since this is an issue, and since I'm using the specification proposed in this repository I just communicate that this "change" will affect several groups and that needs to be considered. If one propose a specification the rest of us can debate about it without taking it personal. I speak for me but reading the rest of the opposition comments I think they just want to express their concerns.

[christianpe98]

Hey @fincamd , nobody's criticizing anything. We're discussing a problem we're having. In the specification there is no indication of the format that the route should have in the POD, because this is basically the issue to talk about.

[fincamd]

It is clear that either I didn't make myself clear or you guys didn't catch my point. I am not going to provide further explanations since it is pretty clear who is going to be "negatively affected" by these changes.

I mean, you guys don't agree on following these guys' solution?

Go on then, fork the repo, define your own standard with your modifications and create a pull request. Then let these people "discuss" you back, see if you like it. It seems like boredom is wreaking havoc these days.

[christianpe98]

Maybe I have misunderstood but this repository is to define a specification between all the Spanish and English groups. I don't understand what is the problem of discussing in an issue the serialization format of an RDF route. We are trying to find a solution, not to confront anyone or anything.

[luispc1998]

I wasn't expecting this proposal to be such a controversial topic.

I want you to think as software architects, and follow my reasoning.

Linked data, the semantic web, are totally new concepts for us, 6 weeks ago most of us didn't even know its existence. Having that it mind, a need to store data in a linked way (rdf) appears, and we are forced to make a decision, to choose which format to use. Let's study the possibilities that
we are discussing right now and that were stated by @labra 23 days ago ( #5 ), , after we proposed our first draft, in json-ld, the unique format consider in this repo at that time.

Turtle: we didn't see this language in the degree, and comes as a new technology from us. Together with the use of react and Solid, it is quite a lot of things to learn during the development of the process. Futhermore, it is more difficult to parse than a json file.

Json-Ld: this is a json, a format we all are familiar with because we have used it in the degree, and to which javascript offers support with its built-in object. Taking this option our code will be more plain javascript since we are managing a json object, and it will be more understandable for us, since we are not familiar with the other format. Two drawbacks could be pointed out. First, we must define the context, following the json-ld specification, we are not familiar with that, and since I studied it to make this proposal I can say that it is not easy. Having said that, you have it solved, the context it's done, you don't even have to worry about that, and you will only have to manage a json file, with extension .jsonld. (Of couse if it were needed to modify something I would be the first one that would be ready to help and add whatever is necessary for the context.) The other possible drawback, is that the pod does not offer support for this format yet. For us, that does not matter at all.

So taking into account the tradeoff of both possibilities we concluded that Json-Ld was the best approach for us, not only as a team, but also as a course, and so we communicated it here long time ago.

Today we uploaded this almost complete draft because we know that some people are working in json-ld as we proposed, and we wanted to provide a more fixed view of what in the end woud be the final standard. (We are now receiving comments to include the gpx waypoints inside the route.)

I understand that you have implemented it using Turtle, and using json-ld forces you to change your code, we don't have that much time this semester and you are stressed, I get that. But I must confess that I a bit annoyed that you didn't expose previously what you were doing, and that you don't comment a tradeoff by which turtle is proven as a better option. I have talked to Labra many times explaining him my ideas about this specification in order to make as good as possible.

Talking about the proposed solution, of implementing a layer with parsers and accepting both formats at the same time, I believe (my personal opinion) that we should not do that, we were supposed to agree on a common way of managing the POD, doing this dirty things, that would lead to unnecessary conditional logic because we all didn't agree on a good design, when it should have been done, it is not the solution. We were requested for quality software, and that is what my team and I are trying to achieve.

[christianpe98]

The problem here is not which option is better, everyone will be able to weigh the disadvantages and advantages and choose an option. The problem is that many groups have already selected an option, some Turtle and some JSON-LD. What can't be done now is to impose one solution on another. If parsers is not a correct solution we will have to look for another one, let's look for an approach that does not harm anyone to a great extent.
I understand that you have been the group that has participated more in the specification, but at no time has the use of JSON-LD been specified. This is the first issue on this topic.

PS: We are not criticizing your work, we are simply discussing in the channel designed to discuss these things. I don't understand why you are taking it so personal.

[luispc1998]

Just to be clear, I'm not pissed of, or feeling attacked or something like that. I've talked to the professors in the previous sprint about this specification and they told me that in this one is when we should finish or almost complete it.

From my team we couldn't present something before because we didn't have the knowledge to do so. It is true that we didn't comment here in the repository that we were considering jsonld as the best option, we did it theory classes in order to know labra's opinion. We are commenting it here now because we have something that works, and that it is intuitive. I understand that some groups may have chosen turtle or even other language, but for those that have not done it yet, we hope that this approach proves useful.

I've thinking about the best approach to solve this situation. I still believe that we should determine just one format, and taking into account my previous explanation I still believe that it should be Json-ld, however I understand that depending on your architectural design even though what we propose it's quite straightforward takes time to be implemented, time that you may not have.

This whole discussion will end in parsing formats, and even as you commented previously accepting both formats, but given the importance of this decision, we need more people to participate in order to reach a conclusion. I propose to wait for the teachers to comment this topic, since I believe that they will help us to coordinate.

[kriogenia]

Damn, this issue got big since the last check I did 😅.

A lot of good arguments on both sides but I think there's something missing on the discussion. To be fair, if we take a look at the dataModel.bs we can see that turtle was already highlighted. The data model is the waypoint for a lot of groups (like mine) that followed it to implement the specification into their apps and just took that indication on the file as a guidance.
I also support looking for a way to satisfy both ways tho. There's a reason software development deprecates instead of just outright deleting, we can't left out a good number of the groups, specially when turtle appears on the data model. Maybe I'm biased as we use Turtle and our deadline is right over us but I really think it is the way to go.

As a first step into that possible conciliation I will leave here this conversor from Turtle to JSON-LD, it should make things easier for all you using JSON-LD if we finally accept both formats:
https://github.com/frogcat/ttl2jsonld

[labra]

After reading this long thread I wanted to remember something about how to behave in discussions...I started to write those things and created a specific issue for a code of conduct #26 that I recommend you to look.

Here I will talk about the specific issue of supporting the JSON-LD format.

You have to separate the data model from the syntax. The data model is the graph representation of the routes in terms of nodes and properties. That data model can have different serializations like Turtle, JSON-LD, RDF/XML, etc. Those serializations are usually compatible between each other and there are different tools and libraries that allow you to convert between each other.

In this way, adding support to JSON-LD is already supported by the current ViadeSpec when it proposes an RDF data model.

Maybe, we can define a common @context for viade Routes and add some example of how an example route can be represented in JSON-LD. If someone wants to create a Pull Request for that, it will be great.

In my opinion, following Postel's law the apps should be liberal to accept routes in different formats like JSON-LD, Turtle or even XML for GPX routes, but they should be conservative in which routes they store in the pods.

So I don't think it is necesssary to choose between JSON-LD or Turtle at the viadeSpec level, it should describe the common data model and the properties necessary to represent the different aspects of a route.