Ipernity

Questions de MB:

• Il manque les types des groupes "privé, public, sur invitation", un groupe est une resource, on doit pouvoir utiliser amo onto.

==> Oui amo semble bien adapté pour ca "type 0 = privé invisible, nécessite une invitation. 1= public, 2= public + invitation", par contre pour les roles on a  : 1=administrateur, 2=moderateur, 4=membre , sioc fournit sioc:has_administrator, sioc:has_moderator et sioc:has_member.

• Les topics sont des sujets de discussion dans le groupe. Il existe sioc:discussion pour associer des discussions à des sioc:items dont dérive sioc:post. un topic a aussi un sioc:has_creator

 ==> effectivement, je pense que has_discussion est plus adapté, Et j'utiliserai sioc:Thread pour modéliser le fil de discussion, qu'on a pas d'ailleurs mais que rien n'empêche de modéliser.

Property: sioc:has_discussion

has_discussion - The discussion that is related to this Item. 

The has_discussion property links any sioc:Item to a related discussion. The discussion can be anything, for instance a sioc:Forum, a sioct:WikiArticle or simply a foaf:Document.

Property: sioc:topic

topic - A topic of interest, linking to the appropriate URI, e.g. in the Open Directory Project or of a SKOS category. 

A topic definition applies to most of the concepts defined in this ontology, and topic metadata can be a useful way to match documents and people to each other.

Class: sioc:Thread

Thread - A container for a series of threaded discussion Posts or Items. 

Mailing lists, forums and blogs on community sites usually employ some threaded discussion methods, whereby discussions are initialised by a certain user and replied to by others. The Thread container is used to group Posts from a single discussion thread together via the sioc:container_of property, especially where a sioc:has_reply / reply_of structure is absent.

• Dans les tables d'ipernity, il y a de la redondance, il faudra faire attention lors de la génération du RDF. En particulier, il y a une table qui type les relations entre membres, alors qu'ici ces relations apparaitront par le biais des groupes. Chez ipernity elles sont à la fois explicites (table des relations) et inférables (par les groupes).

==> Je ne vois pas ce que tu veux dire là michel,       "Il existe 3 type de relation entre membres : 4=simple contact (comme un favori), 1=réseau famille, 2=réseau amis, 3=réseau ami et famille."

• Je ne comprend pas trop comment tu modélise les niveaux de partage...

==> Si un document est partagé avec les amis: uri_doc ipernity:sharedWith rel:friendOf,  avec la famille: uri_doc ipernity:sharedWith ipernity:familiy (je viens de voir que dans relationship il n'y a pas super classe pour la famille...) et on délare les deux quand on partage avec la famille et les amis. Si c'est privé on ne déclare rien et personne n'y a accès, ca vous plait? 

• Je ne vois pas les albums dans la modélisation !

 ==> Je n'ai pas mis toute les sous-classes possibles dans le schéma, j'ai mis rdf:resource pour être générique, ensuite si on a un post la ressource est sioc:Post, si on a un album sioct:ImageGallery etc. voir la partie "types d'éléments" j'ai lancé une discussion dessus.

• sioc:group devrait être aussi sioc:usergroup_of du sioc:space 

==> vous pouvez répèter la question ;)? on utilise plus sioc:space pour le profile.

• Guigui semble-t-il veut représenter un profil par un sioc:space, je pense que sioc:space n'est pas fait pour ça... -> Nécessité de définir le profil !
  • Apparemment : dans le profil on stockerait tout l'historique des interactions (à la face book : machin a commenté, machin a créé, machin a taggué, machin a partagé, etc.)
  • Nécessité de faire une ontologie dédiée ?

==> je pense que sioc:space etait une erreur de modélisation, ni sioc ni sioct fournisse de classes appropriées, je suis pour modèliser la notion de profil dans un réseau social

messages privés

possibilités:

• Bonne solution selon guigui: extension de sioc:Post ==> ipernity:PrivateMessage, on étend creator pour l'émeteur: 'from' et un modélise le destinaire: 'to', J'ai envie de modèliser les intéractions en ligne en étendant SIOC
• sioc:MailMessage qui est une sous classe de sioc:Post, de même on étend creator pour l'émeteur: 'from' et un modélise le destinaire: 'to', mais bon ce ne sont pas des mails 
• irc:PrivateMessage? dans irc:PrivateMessage étend irc:MessageEntry qui étend sioc:Post, on rest bien relié à  SIOC mais on est pas dans la sémantique du message privé dans l'IRC tel que décrit dans cette ontologie
• Nepomuk Message Ontology: http://www.semanticdesktop.org/ontologies/nmo/ mais ils ne sont reliés à aucun schéma...

Types d'élément

• document :foaf:Document?

• post ==> sioc:Post :)

• album ==> sioct:ImageGallery?

<owl:Class rdf:about="http://rdfs.org/sioc/types#ImageGallery">
  <rdfs:label xml:lang="en">Image Gallery</rdfs:label>
  <rdfs:comment xml:lang="en">Describes an image gallery, for example, a photo album.</rdfs:comment>
  <rdfs:subClassOf rdf:resource="http://rdfs.org/sioc/ns#Container"                                            />
  <rdfs:isDefinedBy rdf:resource="http://rdfs.org/sioc/types#"                                            />
  <rdfs:seeAlso rdf:resource="http://www.w3.org/2003/12/exif/ns/IFD"                                            />
</owl:Class>

Tags

<scot:Tag rdf:id="tag_ID">
  <scot:tagof rdf:resource="element_ID"                    />
  <scot:usedBy rdf:resource="user_ID"                   />
  <rdfs:label xml:lang="en"></rdfs:label                   />
</scot:Tag>

Topics

<skos:Concept rdf:id="topic_ID">
  <rdfs:label xml:lang="en"></rdfs:label                   />
</skos:Concept> <sioc:UserGroup rdf:id="group_id"> <sioc:topic rdf:resource="use" </sioc:UserGroup>

Modèle

• une table contenant les 10000 enregistrements d'utilisateurs avec comme colonne :
  • l'identifiant de l'utilisateur

• une table contenant les enregistrements des documents de ces utilisateurs avec comme colonnes :
  • l'identifiant du document 
  • l'identifiant de l'utilisateur
  • le niveau de partage du document : valeurs = privé (personne n'y a accès), amis (tout ou rien), famille (tout ou rien), et déduit : famille et amis. QUESTION : valeurs numériques ?
    
  • le niveau de partage du document : 0=privé, 1=avec famille, 2=avec amis, 3=avec famille et amis, 4=public

• une table contenant les enregistrements des posts de ces utilisateurs avec comme colonnes :
  • l'identifiant du post 
  • l'identifiant de l'utilisateur 
  • le niveau de partage du pos : IDEM
    
  • le niveau de partage du post : 0=privé, 1=avec famille, 2=avec amis, 3=avec famille et amis, 4=public

• une table contenant les enregistrements des albums de ces utilisateurs avec comme colonnes : C'est quoi un album ?
  • l'identifiant de l'album
  • l'identifiant de l'utilisateur
  • le niveau de partage de l'album
  • les compteurs du nombre d'élements partagés: c=total des élements, family_c=partagés avec famille, ...

- une table contenant les relations entre ces utilisateurs avec comme colonnes:

         - l'identifiants de l'utilisateur 1

         - l'identifiants de l'utilisateur 2

         -          la relation donnée par l'utilisateur 1 à l'utilisateur 2 : c'est quoi ? AMI OU FAMILLE ?

      Il existe 3 type de relation entre membres : 4=simple contact (comme un favori), 1=réseau famille, 2=réseau amis, 3=réseau ami et famille.

- une table contenant les visites des utilisateurs avec comme colonnes:

         - l'identifiants de l'utilisateur visitant (user_id),

         - l'identifiants de l'utilisateur visité (en fait du propriétaire de l'élément : owner_id),

         - le nombre de visites (visits)

         - le type d'élément visité (item) (item) (doc, post, topic, album, espace utilisateur) : VALEURS NUMERIQUES ?

item et item_id indiquent l'élément appartenant à owner_id. ex: "doc" 1 indique le document doc_id=1

         - l'identifiant de l'élément visité (item_id)
         - la date de la dernière visite (visit_at)
 

- une table contenant les commentaires des utilisateurs avec comme colonnes:

        - l'identifiants de l'utilisateur commentant (user_id)

        - le type d'élément commenté, (item) (doc, post, topic, album, espace utilisateur):

         - l'identifiants de l'élément commenté (item_id)

        - l'identifiant du commentaire auquel répond ce commentaire (parent_id)

        - la date de création du commentaire (created_at)

- une table contenant les messages des utilisateurs avec comme colonnes:

         - l'identifiants de l'utilisateur auteur du message (sender_id),

       -          l'identifiants de l'utilisateur destinataire (recipient_id)

         -  la date du message (sent_at)

- une table contenant les tags des documents et posts avec comme colonnes:

En fait cette table (itemkeywords) devrait s'appeller itemtags car elle contient les tags keyword et profile.

         - l'identifiants de l'utilisateur auteur du tag (user_id),

         - le type d'élément sur lequel porte le tag (item = doc ou post)

         - l'identifiant de l'élément sur lequel porte le tag (item_id)

         - le  propriétaire de l'élement : owner_id

         - le type de tag (keyword / profile)

       -  l'identifiant du tag (id)

- une table contenant les tags mot-clé des utilisateurs avec comme colonnes:

         - l'identifiants du tag mot-clé,

         - texte du tag mot-clé

 - une table contenant les groupes des utilisateurs avec comme colonnes:

         - l'identifiants du groupe,

         - type du groupe (privé, public, sur invitation) ?

type 0 = privé invisible, nécessite une invitation. 1= public, 2= public + invitation

 - une table contenant les rôles des utilisateurs dans les groupes avec comme colonnes:

        - l'identifiants du groupe,

        - l'identifiants de l'utilisateur,

        - rôle : VALEURS ?

role : 1=administrateur, 2=moderateur, 4=membre

- une table contenant les topics des groupes avec comme colonnes:

C'est quoi un topic exactement ? : un topic est un sujet de discussion dans le groupe.

         - l'identifiants du topic,

         - l'identifiants du groupe,

         - l'identifiants de l'utilisateur auteur