assemblee-virtuelle
Avoir la possibilité d'ajouter plusieurs image pour une orga
Pour une organisation, nous avons besoin qu'elle ait plusieurs images associées :
- image de profil / logo
- image plus large de type bandeau facebook.
Possible de réifier les relations images ?
Il y a déjà une issue pour l'ajout de pair:image:
https://github.com/assemblee-virtuelle/pair/issues/135
Perso j'éviterai de multiplier les relations réifiées. Pour les sites web, on a trois prédicats: aboutPage, homePage, webPage. Pourquoi ne pas imaginer plusieurs prédicats pour les images ? logoImage, fullImage, etc ?
Petit ajout:
Récemment, je me suis dit que c'était pas terrible que, pour les images, on serve toujours l'image originale, car parfois elles sont énormes alors qu'on les affiche sur un carré de 100x100px. On pourrait les redimensionner automatiquement mais on perd du coup l'original. L'idéal serait de pouvoir avoir aussi un prédicat type thumbnailImage.
Il faut suivre le même pattern que pour les sites web, avec des sous-propriétés d'une propriété générique :
Première remarque:
En fait il y a 2 besoins distincts:
- Pourvoir distinguer les images par caractéristiques techniques (= une image "petite" qui peut servir de vignette vs. une image "grande" qui peut servir de bandeau)
- Pouvoir distinguer une image "principale" vs. plein d'autres images associées à l'entité. C'est par exemple la distinction entre foaf:depiction et foaf:img qui est une sous-propriété
Deuxième remarque: une Image est un (ou une sous-classe de) Document. A ce titre l'URI de l'image peut faire partie du graphe et être liée à un Sujet par pair:documents (image secondaire) et pair:represents (image principale).
Une solution qui:
- étendrait pair:Document avec une classe pair:Image
- ajouterait pair:depicts comme sous-propriété de pair:represents pour lier spécifiquement à des pair:Image
- ajouterait un attribut pair:imageType sur les Image avec pour valeur "logo", "thumbnail", "profilPage", etc.
vous conviendrait-elle ?
(ca me semble le plus proche de la philosophie de PAIR).
Cela me semble cohérent, même si ça va un peu compliquer l'implémentation côté interface (mais c'est gérable).
Quelques remarques/questions:
- Pour l'auto-génération de thumbnails (ce qu'on va sans doute faire dans SemApps à un moment, pour améliorer les performances), y aurait-il un predicate qui indiquerait qu'une image est un thumbnail d'une autre image ?
- Pour le type MIME, on utiliserait de préférence Dublin Core n'est-ce pas ?
- Si on crée une sous-classe Image, on pourrait aussi en profiter pour créer
Video, non ?
OK, alors je récapitule dans le détail les ajouts :
Classes :
- pair:Image subClassOf pair:Document
- pair:Video subClassOf pair:Document
- pair:ImageType subClassOf pair:DocumentType
Propriétés
Donner un type à une image :
- pair:hasImageType subPropertyOf pair:hasObjectType, domain pair:Image range pair:ImageType : indique le type d'une image (dans un vocabulaire contrôlé à créer : logo, thumbnail, profil image, etc.)
Donner le format technique d'un document / d'une image
- pair:format, domain pair:Document range xsd:anyUri : référence à un media-type IANA
Indiquer qu'un sujet est représenté par une image principale :
- pair:depicts subPropertyOf pair:represents, domain pair:Image, range pair:Subject, inverse pair:isDepictedBy : indique qu'un Sujet a une représentation principale sous forme d'image
Indiquer qu'un document est version différente d'un autre document / qu'une image est un thumbnail d'une autre image :
- pair:hasVersion / pair:isVersionOf, domain pair:Document, range pair:Document (indique qu'un Document est une autre version d'un autre Document)
- pair:hasThumbnail / pair:isThumbnailOf subProperty pair:hasVersion, domain pair:Image, range pair:Image : indique qu'une Image est la version vignette d'une autre image
Oui top ! Je suis juste surpris que tu veuilles incorporer pair:format car je croyais que tu préférais utiliser DublinCore pour ce qui est de l'ordre de la documentation. Or il y a un dc:format. Voir mon commentaire https://github.com/assemblee-virtuelle/pair/issues/161#issuecomment-817893596.
Pas sûr qu'on utilisera pair:format dans SemApps mais si tu penses que c'est cohérent, pas d'objection...
Oui il faudrait qu'on en parle. On est parti du principe que PAIR était une ontologie de domaine qui devait former un tout cohérent sans dépendance vers d'autres ontologies à part SKOS. Donc:
- soit on considère que les Document sont dans le périmètre de PAIR et alors il faut enrichir l'ontologie avec les propriétés décrites dans ce pointage que j'ai fait rapidement avec Guillaume
- soit on considère que la description des documents ne fait pas partie du périmètre de PAIR et que SemApps et d'autres applications devraient s'articulier ici avec DublinCore pour décrire les ressources
Et du coup là on s'achemine pour ajouter plein de propriétés descriptives des documents dans l'ontologie, en faisant au passage de Document une sous-classe de ressource. Mais il faut qu'on en parle tous les 2...
Ne peut-on pas considérer que la notion de document reliée aux sujets via documents / documentedBy s'inscrit dans le périmètre de pair sans pour autant y inclure toute la complexité liée à la description de l'univers documentaire ? Ce qui nous amènerait à conserver une certaine légèreté de PAIR. PAIR se situerait donc relativement meta et générique (un peu à la manière de org ) et s'appuierait sur des ontologies existantes ou des modules métiers pour décrire des domaines précis, comme l'univers documentaire via DC ?
Ne peut-on pas considérer que la notion de document reliée aux sujets via documents / documentedBy s'inscrit dans le périmètre de pair sans pour autant y inclure toute la complexité liée à la description de l'univers documentaire ?
Oui, c'est l'alternative proposée : on garderait la classe Document et les liens documents / documentedBy (et les autres) dans PAIR, mais sans rentrer dans plus de détails concernant les autres éléments descriptifs des documents. Et on trace la frontière en disant : "dans PAIR, ce qui nous intéresse c'est uniquement la façon dont les Documents s'articule avec les autres éléments de l'ontologies (Acteur, Resource, Type, etc.) mais ce n'est pas la description intrinsèque des documents eux-mêmes."
pair:hasThumbnail / pair:isThumbnailOf pourrait être dans une ontologie SemApps dédiée, idem pour le format. Il ne faut pas que SemApps soit dépendant de PAIR
Donc, voici les ajouts qui seront faits:
Classes :
pair:Image subClassOf pair:Document
pair:Video subClassOf pair:Document
pair:ImageType subClassOf pair:DocumentType
Propriétés
Donner un type à une image :
pair:hasDocumentType subPropertyOf pair:hasObjectType, domain pair:Document range pair:DocumentType : indique le type d'un Document + son inverse pair:typeOfDocument
pair:hasImageType subPropertyOf pair:hasDocumentType, domain pair:Image range pair:ImageType : indique le type d'une image (dans un vocabulaire contrôlé à créer : logo, thumbnail, profil image, etc.) + son inverse pair:typeOfImage
Donner le format technique d'un document / d'une image : à intégrer dans une ontologie technique SemApps
Indiquer qu'un sujet est représenté par une image principale :
pair:depicts subPropertyOf pair:represents, domain pair:Image, range pair:Subject, inverse pair:isDepictedBy : indique qu'un Sujet a une représentation principale sous forme d'image
Indiquer qu'un document est version différente d'un autre document / qu'une image est un thumbnail d'une autre image : à intégrer dans une ontologie technique SemApps
Finalement je m'aperçois qu'on a fait des restrictions locales sur la propriété pair:hasType et qu'on n'a pas redéclaré de propriété de type pour chaque classe. C'est mieux de faire ça. Du coup j'enlève pair:hasImageType - mais je laisse pair:ImageType, et on se sert de pair:hasType sur pair:Image, mais uniquement avec des valeurs de pair:ImageType