• Tesauro, temetres y jusrisprudencia

  • Hemos intentado hacer de OpenKM una aplicación lo más intuitiva posible, sin embargo siempre viene bien algún consejo.
Hemos intentado hacer de OpenKM una aplicación lo más intuitiva posible, sin embargo siempre viene bien algún consejo.
Forum rules: Por favor, antes de preguntar algo consulta el wiki de documentación o utiliza la función de búsqueda del foro. Recuerda que no tenemos una bola de cristal ni poderes mentales, o sea que que para informar sobre un error es necesario que nos indiques tanto la versión de OpenKM que usas como la del navegador y sistema operativo. Para más información consulta Cómo informar de fallos de forma efectiva.
 #27820  by rubalkatrapa
 
Hola a todos:

Este es mi primer mensaje, quiero saludaros a vosotros, y, de paso haceros una pregunta.

Perdonad que empiece así tan de sopetón.

Me gustaría hacer una gestión de jurisprudencia y, no se hasta qué punto es útil utilizar el tesauro.

He probado de mil maneras construir uno para indexar los documentos pero no hay forma. Yo me muestro incapaz.

He probado con el ejemplo que aparece en la documentación y me funciona, pero si quiero construir algo más a medida me topo con un muro.

He probado temetres y exportado a OWL pero como que no.

Mis preguntas son las siguientes:

¿merece la pena el tesauro?
¿valdría simplemente con las categorias y demás?
Si merece la pena el tesauro ¿¿hay alguna manera de construirlo y que directamente lo implemente?? porque me lío con
Code: Select all
kea.thesaurus.owl.file
kea.thesaurus.base.url
kea.thesaurus.tree.root
kea.thesaurus.tree.childs
Pues no se cómo rellenar adecuadamente los datos (excepto kea.thesaurus.owl.file)

No busco que me guieis hasta el final, pues no quiero haceros perder el tiempo (no obstante se agradecería) pero es que no se por dónde empezar

Tengo OpenKM en una debian sin añadir la aplicación a una BBDD tipo MySQL

Gracias anticipadas. De verdad. Estoy atascado.
 #27833  by jllort
 
1- Lo primero es configurar openkm para que te funcione con mysql ( en un entorno de producción es lo suyo )
2- Sobre el tesauro si es o no útil. Hombre útil lo es en el sentido que tienes un vocabulario cerrado y especializado para tu lógica de negocio. Desde este punto de vista no hay discusión posible.
3- Sobre como importarlo con openkm, esto ya tiene mas complejidad ( piensa que estas en websemantica y que los ficheros estos tienen un determinado formado ). Esto me resulta muy complicado explicarlo en un post.
Por lo que veo el http://sourceforge.net/projects/tematres/ tiene una exportación a Complete export in RDF format (Skos-Core). Hasta aquí vamos bien.
En esta página tienes nuestro ejemplo http://wiki.openkm.com/index.php/Thesaurus_full_example y aquí es donde va a empezar la risa comparando el ejemplo que tenemos con el fichero que te ha generado.

Fíjate que hay unos parametros de configuración
Code: Select all
kea.thesaurus.owl.file=vocabulary/inroute.owl
kea.thesaurus.base.url=http://www.inroutenetwork.org
kea.thesaurus.tree.root=SELECT DISTINCT UID, TEXT FROM {UID} Y {OBJECT}, {UID} rdfs:label {TEXT} ; [rdfs:subClassOf {CLAZZ}] where not bound(CLAZZ) and lang(TEXT)="en" USING NAMESPACE foaf=<http://xmlns.com/foaf/0.1/>, dcterms=<http://purl.org/dc/terms/>, rdf=<http://www.w3.org/1999/02/22-rdf-syntax-ns#>, owl=<http://www.w3.org/2002/07/owl#>, rdfs=<http://www.w3.org/2000/01/rdf-schema#>, skos=<http://www.w3.org/2004/02/skos/core#>, dc=<http://purl.org/dc/elements/1.1/>
kea.thesaurus.tree.childs=SELECT DISTINCT UID, TEXT FROM {UID} rdfs:subClassOf {CLAZZ}, {UID} rdfs:label {TEXT} where xsd:string(CLAZZ) = "RDFparentID" and lang(TEXT)="en" USING NAMESPACE foaf=<http://xmlns.com/foaf/0.1/>, dcterms=<http://purl.org/dc/terms/>, rdf=<http://www.w3.org/1999/02/22-rdf-syntax-ns#>, owl=<http://www.w3.org/2002/07/owl#>, rdfs=<http://www.w3.org/2000/01/rdf-schema#>, skos=<http://www.w3.org/2004/02/skos/core#>, dc=<http://purl.org/dc/elements/1.1/>
Que son una consultas específicas para el fichero en cuestión y que no van a valer para otro fichero. Aquí se establece el fichero, la url base del tesauro así como la consulta para pillar los padres y los hijos de un nodo con una consulta por SPARQL, un formato que yo siempre he encontrado satánico.

Aquí tienes que hacer que el formato del RDF o OWL sea correcto y las consultas sean correctas para tu formato. Esto no es fácil. Yo se sugeríria una importación pequeñita para poder trastear un poco el xml resultante. Esta aplicación te puede ayudar a tocar alguna cosa http://protege.stanford.edu/ ( esto de la websemantica es un mundo bastante complicado hasta que lo tienes mínimamente controlado, te tengo que avisar ! ).

Si estas interesado en integrar por ws o similar el http://sourceforge.net/projects/tematres/ con esto podemos colaborar, me parece super interesante y mucho mas facil probablemente que el tema de la carga.
 #27839  by rubalkatrapa
 
Voy a digerir un poco lo que me comentas porque yo cuando veo XML y etiquetas XML ya me pongo malo :?

Ví tematres de pura casualidad y vi que exportaba a skos. Luego desde una página web (http://www.ebusiness-unibw.org/tools/skos2owl/) se transformaba a owl y me dije "¡voy a utilizar esta herramienta!"

Debo tratar con un grupo de personas y siempre me pareció mejor que estas personas de adaptaran a unas etiquetas comunes.
Ese es el problema que tengo, pues debo estandarizar los términos para que luego, al tiempo, sea sencillo buscar y encontrar exactamente lo que buscas.

Es decir, hay una sentencia del tribunal X que dice Y, le coloco etiquetas para que en el futuro la búsqueda sea relativamente sencilla y ya tenemos una herramienta útil.

Por eso me preguntaba si es buena la idea del tesauro. Aranzadi (ahora se llama Westlaw) tenía un tesauro que me pareció una idea estupenda. Ahora me toca organizar mis propios documentos y esa idea me parece acertada en el mundo jurídico.

Sobre ponerlo con MySQL o MariaDB pues me da lo mismo. Más miedo me da el engarzar el tesauro (si es que merece la pena) con mi problema concreto.

Otra cosa será pensar en cómo hacer un tesauro en condiciones. Es harina de otro costal.

Entonces, para finalizar, ¿hago un prueba/error en un fichero sencillo? o ¿hay documentación que hable de esto?

De verdad que muchísimas gracias
 #27852  by jllort
 
El xml efectivamente a veces puede ser algo satánico.

SKOS es un formato en xml de nodos que no tienen tienen padre y nodos con padre ( de aquí se saca el arbol ). En websemantica los nodos son url ( fíjate en el xml ). Si entiendes esto el xml en cuestión no tiene mucha mas historia. Yo te propondría que se parezca lo máximo posible al formato que hay en el ejmplo para no tener que ir investicando la consulta SPARQL que eso si que es criminal. Crea 2-3 nodos por ti mismo y a partir de ahí puedes hacer varias cosas -> por ejemplo procesar el xml que tienes para convertirlo al formato del ejemplo.

Lo de la base de datos ni me lo pensarí. Piensa que si te peta el hsql ( base de datos embebida ) eso es prácticamente imposible de recuperar.

About Us

OpenKM is part of the management software. A management software is a program that facilitates the accomplishment of administrative tasks. OpenKM is a document management system that allows you to manage business content and workflow in a more efficient way. Document managers guarantee data protection by establishing information security for business content.