Proposal of POD Management

[luispc1998]

This is a proposal of a possible management of the POD of the Viade apps. From the group en2a we expect that this proposal can be taken into account by other groups in order to achieve the interoperability beetwen our apps.

[luispc1998]

I didn't add it to the index file, if I should do so, please tell me before merging it.

[labra]

I think it would be easier to track this pull request if you create one or more issues first to discuss it.

Reading your proposal, I can see several issues that could be separately discussed:

• Using JSON-LD to represent the routes
• The folder structure
• How to handle the GPX information when routes are represented as JSON-LD

[UO265180]

My group (es2a) has a few suggestions:

• Storing routes using a UUID as filename (i.e: ...routes/e90d146c-d7ab-42f9-a2de-5c32aeab8839.jsonld) to easily fetch the route using only that Id and avoiding storing the whole URL.
• When storing route points, changing "latitude" and "longitude" keys to "lat" and "lng" respectively. That's because Google Maps React Library, uses that naming, which simplifies route representation.
• In addition to the above, we suggest storing optionally name and point description.
• Another thing to comment, we think that it would be better to store comments with .jsonld format instead of .txt, that's because we don't want to store its content only, but adding some attributes like date (in millis/secs), author, optionally the point index which comment refers to (to be able to comment refering to a specific point) ... i.e: { content: "Muy wapa la ruta", date: 1584972023423, author: "https://marcosav.inrupt.net/profile/card#me", point: 1, route: "e90d146c-d7ab-42f9-a2de-5c32aeab8839" }

[labra]

My group (es2a) has a few suggestions:

• Storing routes using a UUID as filename (i.e: ...routes/e90d146c-d7ab-42f9-a2de-5c32aeab8839.jsonld) to easily fetch the route using only that Id and avoiding storing the whole URL.
• When storing route points, changing "latitude" and "longitude" keys to "lat" and "lng" respectively. That's because Google Maps React Library, uses that naming, which simplifies route representation.
• In addition to the above, we suggest storing optionally name and point description.
• Another thing to comment, we think that it would be better to store comments with .jsonld format instead of .txt, that's because we don't want to store its content only, but adding some attributes like date (in millis/secs), author, optionally the point index which comment refers to (to be able to comment refering to a specific point) ... i.e: { content: "Muy wapa la ruta", date: 1584972023423, author: "https://marcosav.inrupt.net/profile/card#me", point: 1, route: "e90d146c-d7ab-42f9-a2de-5c32aeab8839" }

Thanks for your comments. As I said before, I think it will be easier to discuss all those points separately with different issues and maybe once they are solved, we could improve this pull request taking into account the agreed resolutions...or using different pull requests for each of them.

[luispc1998]

I have just updated the proposal, according to issues: #28, #29, #30 and #33
This stands as a summary:

• Added elevation for the points.
• Added waypoints.
• Added author
• Comment system changed. Now the route points to a file that points to the comment.

[uo265363]

Rdf namespace (http://www.w3.org/2000/01/rdf-schema#) is included in the context but is never used in route files. Same for xml shema (http://www.w3.org/2001/XMLSchema#) and viade:comment in comments jsonld. Is there a reason for that? Or is just an error?

[luispc1998]

It is not necessary since as you say is not used in the context, I included it because of two reasons. The first one is that the proposal of @labra used that namespaces, I wanted to show that we can use them too. The second one is that in case that someone wanted to propose a new property, they can easily check in one of those namespaces if such a property already exists. In the end, I checked myself the documents to see if some properties matched. In fact I put exactly the same name in the comment example as the properties in Schema.org, you can see there the namespaces even though it is not used. In case no more is added to that file, I think that using an already defined property is a better approach.

[InigoGutierrez]

Formatting details: note that in bikeshed the final octothorpes are to be used only if the title has an ID, otherwise they appear in the final text. I added IDs to the titles so this doesn't happen and they can be referenced later if needed. Also, when building locally the json-ld route example is imported but appears as plain text without formatting. I was not able to solve this issue.

[InigoGutierrez]

I noticed that we are missing a specification for notifications to the inbox folder; I made one as a simplified version of the one proposed on #34 (comment) in jsonld format. I am no expert with these, so take this proposal with care.

{
  "@context": "https://www.w3.org/ns/activitystreams",
  "summary": "Sally offered 50% off to Lewis",
  "type": "Offer",
  "actor": {
    "type": "Person",
    "name": "Alice"
  },
  "object": {
    "type": "http://www.types.example/ProductOffer",
    "name": "50% Off!"
  },
  "target": {
    "type": "Person",
    "name": "Bob"
  }
}

We could add this to the proposal so we have a reference to make a base format for interoperability.

[labra]

Given that several people have said me that they agree with this pull-request, I proceed to merge it.