Proposición de la base de interoperabilidad/Proposal to set the basis of Interoperability

[andrrsin]

Versión Español

Introducción

AL hablar hoy en los laboratorios Labra nos ha mencionado la posibilidad de usar Schema para encontrar estructuras de datos comunes. Dichas estructuras que hay en la web estan en consenso entre grandes empresas como Google, Microsoft, Pinterest, Yandex... Estas estructuras estan estructuradas para las tecnologías RDFa, microdata y JSON-LD.

Nuestro caso concreto

En nuestro caso podríamos usar las estructuras de Schema. Por ello he tratado de identificar cuales son los principales focos que se me ocurren ahora mismo.

Landmarks

Los landmarks en el caso de mi web contienen:

• Nombre
• Descripcion
• Longitud
• Latitud

Posible solución

Además de estos se deberían de añadir los específicos a lomap, como la imagen o la review, etc. Por ello propongo revisar las distintas opciones que se ofrecen como Place o Location. El problema del segundo es la falta de Longitud y Latitud (Quizá otros grupos lo programaron de manera distinta).

Amigos

Otro problema que nos encontramos en mi grupo es decidir entre usar las opciones de amistad de Solid o por el contrario crear nuestra versión, ya que los amigos de solid puede interesarnos tenerlos en otra app que use Solid pero no en lomap o viceversa.

Posible solución

Se admiten sugerencias y putnos de vista ya que no sabemos decidirnos

Rutas

Por otra parte y sin que hayamos tocado esta la parte opcional de las rutas. Una posible solución es buscar en Schema pero también podría ocurrir que prefiramos crear nuestra propia estructura de datos. Así mismo al yo no tener conocimientos de las APIs que se usan para mapas y si se pueden trazar rutas entre landmarks. Quiza se podría hacer hasta un paquete conjunto para crear dicha estructura.

[andrrsin]

English version

Introduction

Today in the labs we have talked with Labra and he has suggested Schema this is an initiative of Google, Microsoft, Pinterest, Yandex... to make data structures with the tecnologies RDFa, microdata y JSON-LD which are shared by all of them.

Lomap case

In our lomap apps we can use the power of Schema to provide the interoperability. In order to accomplish such I have searched which could be the main focuses for us.

Landmarks

In my group @Arquisoft/course2223_en2b our landmarks for the moment have the structure with such fields as:

• Name
• Description
• Latitude
• Longitude

Possible Solution

Apart from those we should add the specific fields required by lomap such as the review, the image, etc. For that I propose revising the different options of Schema such as Place or Location. In this case the second option faces the problem of lacking the Longitude and Latitude fields, but perhaps some map APIs admit locations in a different way (Idk about map APIs).

Friends

Another problem my team have faced is the fact of friends of Solid as perhaps we wouldnt like the existing system. Let's think of a case you have a friend in another app using solid and you don't want to see those markers, in that case you wouldn't have the option but to erase him from your list.

Posible solution

I am searching for different proposals of all the groups as we weren't able to find what's best, I encourage everyone to collaborate and find the best solution :D

Routes

My team hasn't touched routes yet as it is optional and we can't even add Landmarks to our map haha. A possible solution could be creating our own data structure. As I don't have any knowledge in maps APIs it's better to hear what you offer but pehpas we could create an algoithm to process the landmarks and creates routes, or having arrays ?? idk. Anyways thanks for reading me <3

[garciafdezpatricia]

LandMark

En mi grupo los lugares también contienen nombre, descripción, longitud y latitud, además de las reseñas, comentarios e imágenes. Estuve mirando la especificación de Place de Schema que propusiste y creo que puede ajustarse bastante bien a lo que necesitamos. Quizá un acercamiento para guardar la información utilizando esa especificación podría ser esta:

• Una posible opción para name podría ser esta o esta
• Description
• Longitude
• Latitude
• Review
• Photo
• Comment

El link de los comentarios lleva a la propiedad 'additionalProperty' de Place que, por lo que entendí, te da la posibilidad de añadir propiedades adicionales en forma de pares. Otra posible solución tal vez podría ser usar la propiedad 'additionalType' y añadirle el tipo Comment.

Amigos

Tal y como lo hicimos en mi grupo, al usuario, llamémoslo Manolo, no le pedimos registrarse en la aplicación para usarla, solo iniciar sesión en su proveedor del pod, ya sea Inrupt, Solid o cualquiera. Igual estaría bien utilizar el método de Solid, porque además de que igual es más simple, si uno de los amigos de Manolo, vamos a llamarlo Pepe, no usa la aplicación, creo que la única repercusión que puede tener en la funcionalidad de los amigos, es que Manolo no pueda ver lugares que Pepe haya marcado en el mapa de Pepe porque Pepe no usa LoMap.

Rutas

Respecto a este tema no puedo aportar mucho. Creo que la API de Google Maps te calcula rutas por sí sola pero supongo que no todos habremos hecho el mapa de la misma manera.

---

Todo esto son solo sugerencias, seguro que algunas cosas no se ajustan a las soluciones de varios grupos o, posiblemente, algunas de las propiedades de Schema que puse no son las más adecuadas.

[gonzalo-rr]

Buenas noches. Antes que nada, pido disculpas ya que en este comentario no voy a aportar nada en cuanto a cómo guardar lugares utilizando Schema (sobre todo porque, por el momento, no entiendo muy bien cómo funciona o cómo se usa).

Sin embargo, me gustaría preguntar a cerca de qué beneficios presenta Schema sobre otras maneras de guardar información en los PODs de SOLID (por ejemplo guardar datos en formato JSON, que es lo que mi grupo ha implementado para nuestra primera versión funcional de LoMap).

Debido a que nuestro grupo ha utilizado JSON, me gustaría explicar por qué lo hemos utilizado y posibles ventajas que tiene a la hora de guardar información:

• Facilidad de utilizar en JS/TS: es extremadamente sencillo utilizar JSON en JS y para guardar un punto, por ejemplo, sería tan sencillo como pasarle el objeto que represente al punto a la función JSON.stringify.
• Familiaridad de los alumnos con JSON: JSON ha sido utilizado y es comprendido por la inmensa mayoría de los alumnos que cursan ASW, sin embargo, dudo que la mayoría de alumnos tengan experiencia utilizándolo (hablo desde mi experiencia, podría estar equivocado).

Aunque nuestro grupo ha considerado las ventajas anteriormente citadas, la principal razón por la que utilizamos JSON hasta ahora ha sido la dificultad para leer y escribir datos en los PODs de SOLID en otro formato que no sea ficheros de tipos MIME (al menos yo no he sido capaz, seguramente por desconocimiento del formato Schema).

Por favor, antes de seguir con la conversación de cómo guardar los puntos utilizando Schema me gustaría que se considerase guardarlos en formato JSON y que se justifique por qué se deberían guardar utilizando Schema antes de seguir con la conversación.

[garciafdezpatricia]

Aparte de lo siguiente no te puedo decir muchas más ventajas porque estoy casi igual.

• Si vas a la página web de Solid, el apartado de Developers explica un poco por encima por qué los PODs utilizan vocabularios para guardar información.
• Si quieres verlo un poco más de cerca, si vas a tu POD a la URL '.../profile/card' y clicas en el icono de source (un cuadrado con </>) vas a ver como todo en tu pod está guardado utilizando varios vocabularios, por lo que se podría decir que una de las bases del almacenamiento de Solid son los vocabularios.
• Formato JSON: usar Schema no hace excluyente el uso de JSON, de hecho una de las opciones que propuso Andrés fue usar el formato JSON-LD, que combina ambas especificaciones. Ejemplo de Schema y JSON-LD con Place.

Creo que los vocabularios solo especifican una forma de enlazar diferentes tipos de datos y no determinan las 'tecnologías' que tienes que usar para utilizarlos, ya que puedes usar JSON-LD, RDFa, microdata... Con esto quiero decir que no sería del todo necesario que tu grupo ni ninguno otro dejara de usar el formato JSON, porque JSON-LD es prácticamente igual.

Respecto a la manera de leer y escribir datos en los PODs, quizá ya tenías conocimiento de esto pero si por si acaso no y te puede ayudar de alguna manera, mi grupo está utilizando las 'Things' definidas en la librería JS de inrupt.

[andrrsin]

Básicamente Schema es usado para tener estándares sobre estructuras que se usan comúnmente. Para que asi por ejemplo las posiciones de mapas, usuarios, imágenes, etc. Sean interoperables entre Microsoft, Google, Pinterest,... Esto no significa que no se puede usar Json, es simplemente el tener nombres comunes con properties conjuntas. No se si me explico.

[alvaroglezeri]

Hello! I'm going to contribute my two cents to the debate by talking a little bit about how we do it in lomap_en1a. You can find our code in our domain specification.

Example: Place

We call our markers Place, and we have these fields:

• Id: unique identifier of the object.
• Name: name of the marker.
• Owner: webID of the owner/creator of the marker.
• Visibility: represents the privacy level of the marker: public, only friends, or private.
• Latitude: latitude.
• Longitude: longitude, nothing more to it :)

Correspondence with the standard

The following fields fit us quite well:

• Id with Thing::identifier.
• Name with Thing::name.
• Owner with Thing::additionalProperty > "owner": webID.
• Visibility with Thing::additionalProperty > "visibility": visibilityLevel.
• Latitude with Place::latitude.
• Longitude with Place::longitude.

We are not currently using the other fields of Place, such as Place::aggregateRating, Place::geo, Place::photo, or Place::publicAccess, although we may use them in successive iterations since they fit quite well with the domain we handle.

Format

Regarding the issue of how to store these objects in the POD at the file level, I am in favor of storing them in LD-JSON format, because storing them in RDFa or Microdata (I don't know if this will be the case in practice, as I haven't tried it) will likely require more libraries and parsing processes, as well as occupying more space due to the need for so many tags and the like. On the other hand, when using Typescript as the main technology (which I suppose most of us do), working with JSON is more intuitive.

[Omitg24]

(A partir de ahora deberíamos continuar hablando en ingles, tal y como mencionamos en la issue #2).

Proposing JSON-LD

Having said that, I only wanted to address a possibility of following the RDF standard for PODs, but also being able to use JSON for the rest of the fields, and thats what JSON-LD is designed for (as I've understood), I haven't got into it a lot, but just wanted to share this info and see if we can come to a better solution. Here's the link to the JSON-LD docs.

Using GEORDF

If we decide to go this way, we might be able to use another profile of RDF, particulary designed for geo options, GEORDF already has fields that we could use in some parts of the app, for example, it has the posibility of including routes (using lines). Here's the link to the GEORDF docs.

As I said, I really haven't got into it a lot, so I might be wrong in some things, but if anyone finds it helpful to the development of the project it would be worth it.

• Omar Teixeira

[Omitg24]

About having more specific issues

As Labra told us on Friday, we should probably be doing more specific issues with smaller areas of discussion, so it's easier to read for everyone, ¿what do you think about this idea? If everyone is fine with doing it this way, how should we proceed, maybe we should follow how Viade's team made it in 2020. Here's the link to Viade's issues.

• Omar Teixeira

[alvaroglezeri]

I love the idea of smaller issues per topic. Should we open one to debate plain RDF vs GeoRDF? I believe the rest of this conversation can be comfortably left in this issue.

[gonzalo-rr]

Good evening, I also think it's a good idea to create new issues to divide the topics.

I think an Issue to debate plain RDF vs GeoRDF is a good idea. I would also like to suggest that we create a new Issue to discuss the JSON-LD format as the title of this Issue may be misleading and there are comments regarding other subjects, so this Issue may not be the best place to talk about JSON-LD. Please, let me know what you think.

[andrrsin]

Seems fine for me also! Perhaps we could create for the moment 2. The first one being what to include inside the data structure,and a second one based on the type of file we want to use.

[FdezAriasSara]

Good morning everyone, issue #4 contains a specific discussion of the fields a location/landmark element should have in a json (that could end up being a json-ld )

in summary, i suggest the following:

{
    "locations":[
        {
            "name":"Parque de invierno",
                         "category":"park"
            "latitude":"43.35302550278352",
            "longitude":"-5.849442050492078",
            "description":"A beautiful place I found when i went for a walk",
            "comments":[
                                         {
                                      "author":"webId of the person who comments",
                                      "comment":"I've been there with my dog !",
                                       "date": "1679832611",//timesamp of the comment
                          },
                            (..more comments)
                           ]
            "reviewScore":"5",//5 out of 5? out of 10? that would have to be discussed too.
            "date": "timestamp of the time the user placed the pin/landmark..."
        }