LoMap data specification

[gonzalo-rr]

This Issue is only to discuss what information to store (latitude, longitude, description, score, etc), not to discuss the format to use to save the data in the SOLID pods (such as using plain JSON, using JSON-LD, following the RDF format, etc).

Please stick to the subject, and use other issues to talk about other subjects, thank you.

[gonzalo-rr]

The current structure to save points in the SOLID PODs is described in the LoMap Spec Readme, in the part referring to the JSON specification. This structure is derived from the Issue #4.

Please keep in mind that the structure is described using JSON but this may not be the final format or it may not be the only one.

If anyone wants to add or remove information from the data specification, please discuss it in this Issue.

[UO284262]

Looking the previus information standars proposed in other issues or the README.md I don't get why we need a list of comments and a list of scores. As I have understand each user's marker must have just his/her comment and score. I don't think that we need to store more than one comment (from maybe more than one user) and more than one score (not directly related to the comment) as previus standars shows.
I think and propose to store only one comment, working as the description provided by the user that saves that marker on his own map, correlated to the only score stored in the marker.
As the contract suggest "Users can add review scores, comments, pictures, etc. about the added places." u post comments and scores about the places you added.
This approach will simplify data representation about what a user think related to his own markers, therefore, the application will focus on the user's favorite places. The access to multiple reviews of a place would be related to "Allow users to compare maps".

[Pelayo-Reguera]

Looking the previus information standars proposed in other issues or the README.md I don't get why we need a list of comments and a list of scores. As I have understand each user's marker must have just his/her comment and score. I don't think that we need to store more than one comment (from maybe more than one user) and more than one score (not directly related to the comment) as previus standars shows. I think and propose to store only one comment, working as the description provided by the user that saves that marker on his own map, correlated to the only score stored in the marker. As the contract suggest "Users can add review scores, comments, pictures, etc. about the added places." u post comments and scores about the places you added. This approach will simplify data representation about what a user think related to his own markers, therefore, the application will focus on the user's favorite places. The access to multiple reviews of a place would be related to "Allow users to compare maps".

Well, in case of my team, we thought on storing lists, because, for a start, we thought that several users could post a score and a comment over the same place. But, although the owner of that stored place were the only one able to post comments and scores, we think that it would be interesting to keep the collection so a person could make a history of the state of the place based on different comments in different days. In addition, supposing that the POD has a list, if your system only allows to post one comment it does not affect the rest of applications because it receives a list with only one thing, however, if we create the restriction of one comment it could be a problem in the future in case someone wants to expand that feature.

[UO284262]

Yeah, i can understand ur point. The only thing is that I would store together the comment and the score to have a 1-1 relation. Its true that the most flexible approach is a list and every team would be able to decide if more than one user can comment, the owner user can comment more than once, etc...
I think we shouldn't aim to have a 100% interoperability and reach a flexible specification that allow every team to take the decisions that allow their app to work as they have designed it.
Per example, if my team designed the application to only allow the owner user to comment on his markers, we should be able to do that while other team allow multiple users to comment the markers.
So, I propose to store together the comments and the scores directly related to them (when I comment I provide a score related with that comment) on a list, allowing each team to keep the design they thought about and reduce the interoperability between the applications that designed that feature in a different way.

[gonzalo-rr]

Hello, regarding your comment, @UO284262, I think what you propose is an interesting idea.

I would like to ask if the comment and score could be optional. This way a team could choose to have required scores and optional comments and another one could have optional scores and required comments. As I'm writing this I think this would be really flexible but really difficult to implement correctly.

I would also like you to consider having required scores and optional comments. I know this is not the most flexible approach but it is what most online stores use (for example Amazon).

The two options I consider to be more reasonable are:

1. Leaving it as it is (separated comments and scores), although it is a bit unusual that comments and scores are not related.
2. Storing together the comments and scores but leaving the comments as optional.

I understand your point and I agree that having a flexible specification leaves room for each team to create a different implementation. But in this case I don't see a solution that is both flexible and easy to implement. Please, let me know what you think.

[UO284262]

Hi @gonzalo-rr, i think we can leave both required but, with the flexibility of an empy comment you can get what u want. Leaving a comment as an empty string will allow u to have optional comments and required scores. Also if we set a "no set score" default value (-1 for example) we can have required comment and optional score.
It's maybe not the cleanest option but I believe this will let everyone implement comments and scores as they want.
So, we have required comment (empty string for no comment) and required score (-1 for no score). This allows me to implements single comment single score required and allow everyone to read that data. It also allow you to implements multiple comment and scores not required and I could read your data taking the last comment+score from the owner mark.
Let me know if we have reached an agreement.

[Pelayo-Reguera]

Yeah, i can understand ur point. The only thing is that I would store together the comment and the score to have a 1-1 relation. Its true that the most flexible approach is a list and every team would be able to decide if more than one user can comment, the owner user can comment more than once, etc... I think we shouldn't aim to have a 100% interoperability and reach a flexible specification that allow every team to take the decisions that allow their app to work as they have designed it. Per example, if my team designed the application to only allow the owner user to comment on his markers, we should be able to do that while other team allow multiple users to comment the markers. So, I propose to store together the comments and the scores directly related to them (when I comment I provide a score related with that comment) on a list, allowing each team to keep the design they thought about and reduce the interoperability between the applications that designed that feature in a different way.

Yes, I agree with keeping as an unit the score together with the comment. For us is not a problem

[Pelayo-Reguera]

So in the end, are both of you proposing to leave optional comments and scores giving them default values in case of not fullfilling some of them?

[UO284262]

Yes @Pelayo-Reguera. I think this is the most flexible and easy to implement way to store the places. If any other team that have something designed that can't match with the format we talked about is invited to post about his problems and we will reach a common agreement.

[gonzalo-rr]

So in the end, are both of you proposing to leave optional comments and scores giving them default values in case of not fullfilling some of them?

I also agree with this change, yes.

[Omitg24]

About what @UO284262 said:

So, we have required comment (empty string for no comment) and required score (-1 for no score).

I think its a good idea but I would force somehow the user to add a score about the place, even if he's creating a new one or just giving a score to other user's markers (I don't know if you and your team have implemented it this way), I explain myself.

If we want to see the score a place, we would probably would like to see a general measurement of what some users have thought of it, we might not want to read a comment, and that's why I think leaving them empty is a great idea, but leaving a default number could affect negatively to the score of the place (if I have understood correctly), I'll put an example:

1. User 1 adds a score of 5 to a place, with a comment (in this case it does not matter).

Now the score of the place is 5/5 (just in case you have followed this metric).

2. User 2 adds a score of 0 to the same place, with no comment.

Now the score of the place is 2.5/5.

3. User 3 adds just a comment, default score value will be -1.

Because of setting a default value of -1, and the number of users who have added a review (if we count as that the duo of score/comment), have increased, the score will decrease to 1.33...

As @gonzalo-rr has proposed in #6, we could use aggregateRating, which I think would have this problem if we do not force the user to add at least a score (with comments being totally optional).

All I'm following is the model of Google Maps, as it can be seen in the following image:

In case I'm wrong and i have missunderstood what you proposed let me know, I'll be looking right now how we could implement the aggregateRating part on our apps.

• Omar Teixeira.

[UO284262]

@Omitg24
If u want to implement something like that u can ignore -1 scores. I don't know why u wanna make the specification less flexible. I understand its a little bit more difficult for you this way but probably not everyone wanna implement like you that part.
We are just trying to be flexible and help everyone to implement the app on their own design. I think that force some type of implementation and let everyone that wanna implement commemts without score is not the way we should focus the interoperability.
I did not research a lot about the aggregate rating but I guess you can filter the comments u aggregate or you can assume a little effort on your implementation as everyone of us is doing to reach a specification that allow everyone to implement as they want.

[Omitg24]

I understand what you mean @UO284262 and I totally agree, I thought we all were supposed to do it that way, so it was my mistake, I'm okay with what you've just said then.

Sorry for the inconvenience.

• Omar Teixeira.

[gonzalo-rr]

Hello everyone.

I would like to ask if everyone is ok with the information a map should store. Right now I think we are all in the same page about using a JSON-LD (or JSON as some groups are using) per map as commented here.

Right now in the JSON specification the map has an id, a name and a list of locations.

I was wondering some things. I think the map should have a property like author so we can identify the owner of the map. The author could be the url of the author's POD or a Person that has the url of the author's POD as a property. Maybe it would be easier if there was no default value for the id, then we can choose the map to show based on the user and the name of the map (if user A is in session we choose as the default map the first one that has the user A as author for example). This way we can share maps without having to worry about id collisions. I also think having a date in the map is a good idea and something really easy to implement.

Let me know what you think, for now I'm going to add those properties to my application as I find them really useful.

[Omitg24]

Hello everyone,

I've created a separate issues for the categories of the app, just to have more concrete and separate issues, you can access through this link.

• Omar Teixeira.