ontologies pour gestion contacts

[Jean-Marc Vanel]

Bien sûr le point de départ incontournable c'est FOAF.
Il y a aussi VCARD:
http://www.w3.org/TR/vcard-rdf/

Mais pour les évènements je suis en manque d'onthologie.
Il y a celle fondée sur ICAL , mais je voudrais avoir d'autres choix.
http://www.w3.org/2002/12/cal/ical.rdf

Par ailleurs je pense utiliser
dcterms:subject
pour associer un sujet à un contact ou un document, comme dbPedia le
fait, exemple :
http://dbpedia.org/page/Taraxacum
en réutilisant le composant avec complétion de Wikipedia.

--
Jean-Marc Vanel
Déductions SARL - Consulting, services, training,
Rule-based programming, Semantic Web
http://deductions-software.com/
+33 (0)6 89 16 29 52
Twitter: @jmvanel ; chat: irc://irc.freenode.net#eulergui

[Jean-Marc Vanel]

En fait, CalDAV utilise ICalendar pour les données :
http://en.wikipedia.org/wiki/ICalendar

Pour l'instant je ne m'intéresse pas au protocole, je compte sur le service REST Google pour recevoir les données, éventuellement en envoyer (mais surtout ajouter localement des annotations sémantiques sur ces données).
Car le but est de raisonner en local sur l'ensemble des contacts et des rencontres.


Au fait , qu'est ce qui m'embête dans ICAL / RDF ?
Voici un extrait:

cal:dtstart  a          owl:ObjectProperty ;
        rdfs:comment    "\n\t    default value type: DATE-TIME" , "This property specifies when the calendar component begins." ;
        rdfs:domain     [ a            owl:Class ;
                          owl:unionOf  ( cal:Vevent cal:Vtodo cal:Vfreebusy cal:Vtimezone cal:Vevent cal:Vevent cal:Vfreebusy cal:Vtimezone cal:Vtimezone )
                        ] ;
        rdfs:label      "DTSTART" ;
        rdfs:range      [ a            owl:Class ;
                          owl:unionOf  ( cal:Value_DATE-TIME cal:Value_DATE cal:Value_DATE )
                        ] ;
        spec:valueType  "DATE-TIME" .

# ...

cal:Value_DATE-TIME  a  owl:Class .

Donc:

cal:Value_DATE-TIME est une classe et non un datatype, et il n'est pas autrement défini.

Pour rendre ça utilisable il faudrait dire que cal:Value_DATE-TIME a une propriété datatype de type xsd:dateTime .

Donc cette ontologie n'est pas utilisable telle quelle, ce qui ne donne pas confiance.

De plus l'usage immodéré de owl:unionOf ( à la place de simple rdfs:subclassOf ) est lourd.

Ce ne pose pas de gros problème avec les règles métier, mais un composant écrit en Java qui génère un formulaire ( N3From.java ) ne doit avoir à traiter des inférences trop compliquées pour générer les champs du formulaire.
Même pour une base de règles pour retrouver les champs possibles associés à une classe ou un individu ( au sens OWL :) ) , comme swing-rules.n3p , c'est compliqué de prévoir tous les cas.

Le 10 octobre 2013 17:27, Cyril Hansen <cyril....@gmail.com> a écrit :
> Le standard le plus avancé pour les protocoles de calendriers partagés c'est
> caldav :
>
> http://en.wikipedia.org/wiki/CalDAV
>
> http://www.calconnect.org/CD1104_Calendaring_Standards.shtml#CalDAV
>
>
> c'est du même auteur que CardDav (pour les contacts), qui réutilise Vcard.
>
> http://en.wikipedia.org/wiki/CardDAV
>
>
>
> ---------- Message transféré ----------
> De : Jean-Marc Vanel <jeanmar...@gmail.com>
> Date : 10 octobre 2013 17:12
> Objet : ontologies pour gestion contacts
> À : deduct...@googlegroups.com

> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "Déductions et EulerGUI en Français" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to deductions-f...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

[Jean-Marc Vanel]

Le 10 octobre 2013 18:08, Cyril Hansen <cyril....@gmail.com> a écrit :

Je parle du protocole car vous en avez besoin pour google (c'est normalement carddav)

Pas forcément :

https://developers.google.com/google-apps/calendar/

Je veux bien investir du temps dans ces API REST JSON, faute de RDF/Turtle entrée & sortie, et comme il y en a beaucoup dans la nature, mais éviter, il me parait sage, au maximum les anciens protocoles disparates, à moins qu'il y ait une API Java :) .

ensuite c'est les protocoles qui sont normalisés et constituent les standard de fait, et le format de données n'est qu'une pièce rapportée au protocole...

http://tools.ietf.org/html/rfc6352#section-5.2 -> VCard est embarqué dans Carddav (et donc gmail depuis 2012)

Vcard est aussi normalisé par l'IETF, mais pas d'XML ni de schéma, juste des champs à plats :

http://tools.ietf.org/html/rfc6350#page-56

Le 10 octobre 2013 18:02, Jean-Marc Vanel <jeanmar...@gmail.com> a écrit :

.......