search

juanbm99 / TFG-OpenCityData-JuanBernal

Repositorio correspondiente al material generado para la elaboración del Trabajo de Fin de Grado relacionado con datos abiertos sobre ciudades desarrollado por Juan Bernal Mencía
0 stars 0 forks source link

Posible URI para Entidad Observacion #8

Closed juanbm99 closed 3 years ago

juanbm99 commented 3 years ago

He estado analizando el CSV y he visto que para cada observación con misma fecha y misma URI, hay únicamente una observación para el periodo Total (T), otra para el vespertino (E) y así sucesivamente con el resto de periodos del día. Esto me lleva a pensar si podría existir la posibilidad de que una observación tenga las siguientes posibles URIs:

ocorcho commented 3 years ago

Las dos primeras opciones son las más adecuadas, pues es importante que esté la estación identificada. De entre las dos, prefiero la segunda, con esta modificación

http://datos.linkeddata.es/madrid/recurso/medio-ambiente/contaminacion-acustica/observacion/carlos-v-01-01-2020-T

Otra opción es la de generar un hash a partir de ("Carlos V" + "-" + "01/01/2020" + "-" + "T"). Aunque en este caso la que propones está bien

juanbm99 commented 3 years ago

En principio voy a tirar por la opción que me has recomendado, pero por mera curiosidad: como haría el hash que mencionas (como lo generaría)? Y una vez que generase ese hash, como podría el usuario poder saber a que sujeto está referida esa entidad? o no tendría por qué saberlo.

ocorcho commented 3 years ago

En OpenRefine se puede hacer con una expresión GREL del tipo: md5(xxxxxxxxx), y esto genera el hash. Si no, cualquier otra función generadora de hash. Si se usa RML, habría que hacer uso de una función, que no sé si está implementada en la Function Ontology (FnO).

Para saber a quién se refiere la observación siempre se usarán las tripletas que obligatoriamente vas a crear desde esa observación al sensor que la ha generado, dateTime cuando se ha generado, etc. Es decir, las URIs no tienen por qué tener ninguna "semántica".