Le 17 avril 2013 11:13, Christian Quest <cqu...@openstreetmap.fr> a écrit :
> J'aime bien l'idée d'Ista Pouss de pouvoir choisir les critères de flou, > mais en même temps ça me semble être une approche plus dans la logique d'un > outil que dans la définition d'un ID plus ou moins réutilisable entre bases > externes. > > Merci. Attention que le critère de flou n'est qu'un des critères ; en fait je propose de pouvoir choisir tous les critères. Chacun critère est une propriété d'un objet osm et, plus prosaïquement, un truc exprimable avec l'api overpass. > Si on arrivait à un ID qui puisse fonctionner hors OSM ou API à interroger > systématiquement ça serait pas mal non plus. > > Je reprends ma boulangerie... si l'ID "bakery@#a4u2k9" est utilisé dans 2 > bases externes, elle peuvent savoir qu'elles parlent de la même chose > (concept emprunté aux linked data). > > Mais pour obtenir le #a4u2k9 comment vas-tu faire ? Il va bien te falloir une api, non ? Une fois que tu l'as, il n'est plus besoin d'interroger l'api. Avec le système que je propose, c'est pareil. Il garantit que l'URL qu'il donne restera toujours la même, tant que l'objet satisfait les critères de reconnaissance. Plus fondamentalement, à partir du moment où OSM n'a comme ambition de n'enregistrer que ce qui se voit sur le terrain, il est nécessaire de disposer d'un système externe pour reconnaître et identifier les "objets". Si tu connais les linked data, tu sais aussi que, dans les conceptions programmations orientés objets les plus pures, un objet n'a pas d'id :-) Bien sûr, pour retrouver l'objet OSM actuel, il faudra faire la résolution > de l'ID. > > Pour la résolution, et pour la génération également. Tu peux t'en passer pour la génération si tu spécifies les critères de hash, pour que tout le monde génère le même hash pour un même objet osm. Donc ça revient à donner les critères sélectionnant les propriétés pertinentes, donc ça revient à... ce que je dis :-) Au lieu d'implémenter, tu spécifies, c'est tout. Je ne suis pas contre. > La partie sémantique pourrait même contenir une sorte de hiérarchie, ce > qui permettrait de gérer le flou sémantique au sein même de l'ID comme on > peut déjà le faire au niveau géographique en raccourcissant le geohash. > > Dans le système que je propose, la partie "hiérarchie" est prise en charge par le nom du schema de reconnaissance : http://truc/BAKERY/345 Il est conceptuellement possible (ça devient compliqué à la mise en oeuvre, mais c'est théoriquement possible) de modéliser la fabrication de l'id à partir des critères pertinents, puisqu'on a ces critères. Par exemple, on décide que, pour les boulangeries, le critère de reconnaissance c'est l'adresse et le nom ; on peut imaginer dire au système "pour les boulangeries fabrique moi un identifiant avec le nom" - puisqu'il a le nom. Et alors l'URL deviendrait http://truc/BAKERY/Boulangerie_Centrale:345 Ex: shop.bakery.Croustillette@#a4u2k9 est plus précis que shop@#a4u2k9 > > Oui, mais au niveau de l'id, on se fiche de tout ça. Ce qui est important au niveau de l'id est, soit de pouvoir le vérifier par un humain, soit de donner son autorité ("soit" non exclusif). Chez moi l'autorité sera le site d'hébergement du service (qui peut être osm ! ), et donnée aussi par le nom du schéma de reconnaissance. Ce que tu proposes est plutôt un id à partir d'un classement. Ça peut se faire aussi, mais au point où nous en sommes, ça me parait prématuré. Cordialement. -- Les dérives de rue : Profession émotion <http://drivrsdu.fr/profession-emotion/>
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
