blog de Darwin Betancourt

Fusionar dos imágenes en GIMP

Este post lo he pensado para aquellos entusiastas del diseño gráfico en GIMP esta vez voy a mostrar como podemos fusionar dos imágenes con esta herramienta OPEN SOURCE es un procedimiento bien simple que seguramente te familiarizaras con facilidad. Bueno basta de palabrería y empecemos con la creación.
  1. Conseguimos dos imágenes cualquiera que deseemos fusionar (mezclar) en mi caso voy a tomar la imagen de una amanecer en Loja y la iglesia de Santo Domingo (Loja).
  2. Amanecer en LojaIglesia de Santo domingo
  3. Abrimos la primera imagen en el editor y luego copiamos la segunda imagen y la incluimos como una capa nueva.
  4. El proceso de realizar capa nueva se hace automáticamente o en su defecto podemos crear primero una capa vacia y luego anclarla con nuestra imagen flotante.
  5. Visualizamos los diálogos de capa bajo Diálogos -> Capas o con (Ctrl+L)
  6. Una vez sobre esta capa le añadimos una mascara a la capa, esto lo podemos hacer desde el menu Capa -> Mascara -> Añadir mascara o en su defecto presionando botón derecho de mouse sobre la imagen en el dialogo de capas y seleccionamos Añadir mascara. mascara de una capa
  7. Luego seleccionamos la mascara de esa capa.
  8. Una vez que hemos seleccionado la mascara procedemos a realizar un degradado sobre la misma y veremos nuestro efecto fusion.
  9. Iglesia de Santo Domingo
Saludos y espero sea de utilidad.
Secciones: 

Solución a problema con J9 y Palm

Tungsten E2Hace algún tiempo desarrolle una aplicación en J2ME para mi PDA específicamente la Tungsten E2 que funcionaba a la perfección pero luego de un tiempo empece a experimentar algunos problemas como recibir errores de “Fatal Exception” y lo cual me indicaba que reinicie, pase varios dias investigando a ver de que podía provenir el error con decir que hasta me toco chatear con soporte técnico de palm y dormir pocas horas con la preocupación, pero bueno di con la solución y la quiero compartir con Uds. Uno de los primeros problemas que experimente (Inicio del proyecto) y que fue por la novatada de no gestionar bien la variables y los procesos en mi sistema me salia un error al sincronizar los datos a mi aplicación bueno esto se soluciono con un Hardreset en el equipo. Pero luego de un tiempo me volvió a dar otro problema (luego de 6 meses) el cual me daba un "Fatal Exception" al usar mi sistema y si volvía a reiniciar el problema persistía intente hacer un hardreset como lo habia hecho anteriormente pero esto no lo soluciono y ahora aparecían otros errores al intentar cargar solo la máquina virtual el problema por lo general tenia los siguientes síntomas o mensajes:
  • Mensaje de error luego de la sincronización “DataMgr.c Line: 8878” y no cargaba el J9 en la palm.
  • VSFDBCache.c, Line: 4051, unattached record
  • Carga el J9 pero al querer configurarlo en la Palm recibía “Fatal Exception” o la pantalla se quedaba pegada o colgada.

Porque se da este error:

La KVM de java tiene un algoritmo para liberar memoria y reservarla para otros objetos que no desfragmenta la memoria utilizada y como que llega a saturar los espacios de memoria, como no encuentra memoria intenta escribir en la ROM como ya sabemos que no es posible y lanzara el error “DataMgr.c....”. El problema de este algoritmo es que no relaciona espacios de memoria libres, aunque sean vecinos, y por lo tanto produce una gran fragmentación de la memoria. Una de las sugerencias es liberar todos los espacios de memoria y apuntarlos a null o en su defecto si son enteros encerarlos para ayudar de cierta manera el Garbage Collector.

Solución:

  • Realizar un warm reset y luego un software reset
Que es lo que se logra con este warm reset o tambien conocido como software reset es evitar que al reiniciar no cargue las extensiones (los hacks, programas gestores de hacks, parches del SO, preferencias e alamas, etc). Entonces evitaremos que todo lo que haya estado ocupando este programa no se cargue y como que de cierto modo se libere todo sus consumos de memoria. Si tiene dudas de como se hace un hard reset o un warm reset lo puedes ver en la sección Palm de este blog además de algunos estrategias para desarrollar aplicaciones J2ME y optimizar el recurso de memoria. Actualizado: Este detalle es bien importante no olvidarlo, una vez realizado los pasos anteriores realizas un hard-reset y restauras los datos desde un respaldo anterior que hayas tenido para que se sobreescriba cualquier archivo, aplicación o base de datos y de esta manera evitar este tipo de errores, tambien puedes probar a cambiar de usuario de sincronización para el PDA, con esto logras que se regeneren todas las aplicaciones para el nuevo usuario. Saludos y espero les sea de mucha utilidad.
Secciones: 

Solución a problema con J9 y Palm

Tungsten E2Hace algún tiempo desarrolle una aplicación en J2ME para mi PDA específicamente la Tungsten E2 que funcionaba a la perfección pero luego de un tiempo empece a experimentar algunos problemas como recibir errores de “Fatal Exception” y lo cual me indicaba que reinicie, pase varios dias investigando a ver de que podía provenir el error con decir que hasta me toco chatear con soporte técnico de palm y dormir pocas horas con la preocupación, pero bueno di con la solución y la quiero compartir con Uds. Uno de los primeros problemas que experimente (Inicio del proyecto) y que fue por la novatada de no gestionar bien la variables y los procesos en mi sistema me salia un error al sincronizar los datos a mi aplicación bueno esto se soluciono con un Hardreset en el equipo. Pero luego de un tiempo me volvió a dar otro problema (luego de 6 meses) el cual me daba un "Fatal Exception" al usar mi sistema y si volvía a reiniciar el problema persistía intente hacer un hardreset como lo habia hecho anteriormente pero esto no lo soluciono y ahora aparecían otros errores al intentar cargar solo la máquina virtual el problema por lo general tenia los siguientes síntomas o mensajes:
  • Mensaje de error luego de la sincronización “DataMgr.c Line: 8878” y no cargaba el J9 en la palm.
  • VSFDBCache.c, Line: 4051, unattached record
  • Carga el J9 pero al querer configurarlo en la Palm recibía “Fatal Exception” o la pantalla se quedaba pegada o colgada.

Porque se da este error:

La KVM de java tiene un algoritmo para liberar memoria y reservarla para otros objetos que no desfragmenta la memoria utilizada y como que llega a saturar los espacios de memoria, como no encuentra memoria intenta escribir en la ROM como ya sabemos que no es posible y lanzara el error “DataMgr.c....”. El problema de este algoritmo es que no relaciona espacios de memoria libres, aunque sean vecinos, y por lo tanto produce una gran fragmentación de la memoria. Una de las sugerencias es liberar todos los espacios de memoria y apuntarlos a null o en su defecto si son enteros encerarlos para ayudar de cierta manera el Garbage Collector.

Solución:

  • Realizar un warm reset y luego un software reset
Que es lo que se logra con este warm reset o tambien conocido como software reset es evitar que al reiniciar no cargue las extensiones (los hacks, programas gestores de hacks, parches del SO, preferencias e alamas, etc). Entonces evitaremos que todo lo que haya estado ocupando este programa no se cargue y como que de cierto modo se libere todo sus consumos de memoria. Si tiene dudas de como se hace un hard reset o un warm reset lo puedes ver en la sección Palm de este blog además de algunos estrategias para desarrollar aplicaciones J2ME y optimizar el recurso de memoria. Actualizado: Este detalle es bien importante no olvidarlo, una vez realizado los pasos anteriores realizas un hard-reset y restauras los datos desde un respaldo anterior que hayas tenido para que se sobreescriba cualquier archivo, aplicación o base de datos y de esta manera evitar este tipo de errores, tambien puedes probar a cambiar de usuario de sincronización para el PDA, con esto logras que se regeneren todas las aplicaciones para el nuevo usuario. Saludos y espero les sea de mucha utilidad.
Secciones: 

Planificando un sitio con Web Semántica

La planeación de la web semántica me ha parecido un articulo bastante interesante por lo cual me he tomado la libertad de traducirlo de modo que me sirva para proyectos que diseñe e implemente en el futuro y de paso aportar con conocimiento a alguien mas que este en busca de nuevas tecnologías en el ámbito web. La dirección del articulo en ingles esta en la siguiente dirección: http://www.ibm.com/developerworks/xml/library/x-plansemantic/index.html?ca=drs- --

Prepara tu sitio para estructurar los datos

La Web semántica trae oportunidades para que los usuarios pueden obtener resultados inteligentes en sus búsquedas, y para sus dueños conseguir mas trafico como usuarios que buscan lo que realmente quieren. Pero estos beneficios no aparecerán mágicamente. Este post te lleva a través de los aspectos de la arquitectura de la información e infraestructura general que necesitas para tomar una verdadera ventaja de esta palpable oportunidad. Este post discute lo que necesitas saber para hacer tu sitio parte de la Web semántica. Empieza con una discusión de los problemas que la Web Semántica e intenta resolver y moverlo a tecnología involucrada, como Resource Description Framework(RDF), Web Ontology Language (OWL), and SPARQL Protocol and RDF Query Language (SPARQL). Verás como la Web Semántica es dividida en capas desde la web existente. Cubrirán algunas dificultades que quieres saber cuando planificas un nuevo Web Site y darte algunos ejemplos específicos de como usar tecnologías como RDFa y Microformatos para que tu Web Site existente sea parte de la Web Semántica.

Introducción a la Web Semántica

El World Wide Web es el gran recurso de información producido por la humanidad. Desafortunadamente, a pesar que depende de computadoras en su operación, mucha de la información es solamente entendida por humanos y no por computadoras. Mientras las computadoras pueden usar la sintaxis de los documentos HTML para mostrarla en un browser o navegador, las mismas no pueden entender el contenido-- la semántica. La Web Semántica es una visión del futuro de la web de Tim Berners-Lee. Su sueño no esta todavía realizado, suficientes bloques generados son ahora puestos para que tomes ventaja de varias tecnologías de Web Semántica en tu Web Site, incluyendo RDF, OWL y SPARQL. La meta de la Web Semántica es mostrar los recursos de información de la Web como datos que las computadoras puedan interpretar automáticamente. La web era originalmente todos los documentos. El click sobre un enlace en tu browser web dispara la petición a un Servidor web que te envie un documento, ademas que te los mostraría. El documento puede ser el calendario de los próximos 7 dias, o puede ser un correo de un amigo. El browser realmente no especifica; solo sigue las reglas internas para mostrar la página. Tu debes entender la información en la misma. Estructurando los datos se agrega valor a esos datos. Con estructura consistente, puede ser usado en mas de una forma. Puedes ver hoy en dia la demanda de la estructura de datos en la proliferación de APIs que se tienen suspendida en sitios web como parte de la Web 2.0 un API esta estructurando datos, de una variedad de fuentes de los poderosos mashups. La idea tras los mashups es que los datos con incluidos de varias fuentes en la Web, cuando son combinados y mostrados en una manera unificada, esta combinación de elementos agrega valor y eleva la fuente de información. Los APIs individuales que todos estan ocupando para resolver el mismo extracto del problema que la Web Semántica esta intentando direccionar: Exponer el contenido de la web como datos y disparar la combinación de fuentes de datos en diferentes formas al generar un nuevo valor. Mas bien generar y mantener tu propio API, puedes generar tu Web site tomando gran ventaja de la infraestructura de la Web Semántica que ya tiene su lugar. Si tu web site es tu API, puedes reducir la sobrecarga de desarrollarlo y mantenerlo. De forma similiar, generara soluciones personalizadas para cada web site donde quiere poner datos, puedes implementar una solución basada en tecnologías de Web Semántica y tener trabajo intercambiable en muchos web sites -- incluyendo web sites que no estaban consciente antes de empezar a desarrollar.

Resumen de tecnologías de Web Semántica

Las tecnologías de Web Semántica pueden ser consideradas en términos de capas, cada capa descansa y extiende la funcionalidad de las debajo de la capas. La Web semántica esta hablando a menudo como si hubiera una entidad separada, es una extensión y mejora de la web existente sino un reemplazo. Figura 1. Pila de la tecnología de la Web Semántica [caption id="attachment_129" align="alignnone" width="208" caption="Pila de la Web Semántica"]Pila de la Web Semántica[/caption] Como se muestra en la Figura 1, la capa base de la Web Semántica es HTTP y URIs. Son comúnmente consideradas "Web" sino "Web Semántica", pero cada propósito de la tecnología de la Web Semántica descansa en los principios Web. URIs son los nombres de la Web Semántica. HTTP son los verbos: GET, PUT y POST tambien como un numero de soluciones probadas en los campos de autenticación y encriptación. El Resource Description Framework (RDF) es una gramática para codificar relaciones. Un triple RDF tiene tres componentes: un sujeto, un predicado (o verbo), y un objeto. Cada uno puede ser expresado como un recurso en la Web, eso es un URI. Es medio ambiguo codificar datos en documentos XML aleatorios. Puedes comparar las diferentes formas de expresar una relación en XML mediante el Listado 1 con el triple RDF en el Listado 2. Listado 1: Relaciones ambiguas en XML
  • <author>
        <uri>page</uri>
        <name>Rob</name>
    </author>
    
    <person name="Rob">
        <work>page</work>
    </person>
    
    <document href="http://www.example.org/test/page" author="Rob" />
Listado 2 muestra el triple RDF Listado 2: Relaciones ambiguas en XML
  • <page> <author> <Rob> .
Las relaciones expresadas en los ejemplos mostrados en Listado 1 es "Rob es el autor de página" una simple sentencia-- todavía expresada en varias formas en XML. Debería ser difícil generar software que derive esa relación desde todas las maneras posibles de expresarlo en XML. Pero un expresado RDF que relaciona solamente una forma viene a ser factible al generar un parser genérico. En dias anteriores a la Web semántica, estaba esperando producir contenido debía hacer todo su contenido disponible en RDF y hacer pronto una metafora de los datos disponibles. Desafortunadamente, quizas porque la principal expresión XML de RDF se veia una innecesaria complejidad. de lentitud. Mas sucesos de representaciones RDF, como Notation3 (N3) y Terse RDF Triple Languaje (Turtle) estan ahora disponibles pero han sido desactivados al sobrevenirse la inercia. Una solución al problema fue inspirada por los microformatos. Con microformatos, el valor semántico es agregado al contenido existente HTML usando patrones consistentes de estándares en elementos y atributos HTML. Microformatos existen para estrechar items comunes de datos como información de contenido e items de calendario. El equivalente de W3C es RDFa, los datos embebidos RDF en XHTML. La implementación es ligeramente mas compleja que los microformatos pero es lejanamente mas genérico -- nada que puedas expresar en RDF, puedes agregarlo a documentos XHTML usando RDFa. A traves de esta técnica la Web Semántica puede ser inicializada en contenido existente web. Por supuesto el RDF embebido en documentos XHTML como RDFa no es bueno para todos las herramientas de Web Semántica, que requieren salida. La solución W3C para esto es Gleaning Resource Descriptions from Dialects of Languages (GRDDL). La idea es que puedes ejecutar un documento XHTML existente a traves de una transformación XLS al generar RDF. Puedes enlazar cualquier transformación GRDDL a traves de la directa inclusión de referencias o indirectamente a través de perfiles y nombres de documento. Mientras la ambigüedad expresada semánticamente con RDF es buena, aunque si cualquier lo hizo, es de poco uso si no tienes idea de como el RDF en diferentes sitios es relacionado. El RDF triple en el Listado 2 expresa una relación de autor en el predicado, y mientras el significado puede ser obvio para ti, las computadoras necesitan ayuda. Si expresas una relación de autor en un archivo RDF en un sitio, puede la computadora asumir que fueran la misma cosa? Que si tienes una relación escrita en RDF triple? Necesitas una forma al expresar un vocabulario común, será capaz de decir que mi autor y tu autor son la misma cosa, y que el "autor" y el "escritor" son análogos. En la web Semántica este problema es resuelto por ontologías, y el estándar W3C para expresar ontologías es el Lenguaje de Ontología Web (OWL). Una vez que tienes algunas fuentes de datos en RDF, y tienes ontologías para permitir determinar las relaciones entre ellas, necesitas una forma de conseguir el uso de información fuera de ellos. El protocolo simple y RDF Query Language (o SPARQL, pronunciado 'sparkle') es una sintaxis como SQL para expresar consultas entre datos RDF y ver las consultas que actúen como datos RDF. El paradigma fundamental para SPARQL es un patrón de concordancia y es diseñado para trabajar en la Web como datos combinados al disparar fuentes y ser flexibles. Por ejemplo concordancias pueden ser descritas como opcionales, que lo hacen mucho mejor que en la consulta de datos SQL rotos. Romper datos tiene una impredecible e inconfiable estructura, que es que puedes esperar encontrar si tus datos estan combinados de varias fuentes en la Web sino desde una simple bien controlada base de datos.

Lo que necesitas saber cuando planeas una Web Semántica

Como lo has visto, si generas el próximo gran sito Web 2.0, puedes ahorrar tiempo si planeas desde el inicio a el uso de la tecnología de Web semántica y cambiar tu Web Site en un API, si no crear una API separado para su Web Site. Una Web Semántica te da libre funcionalidad como API. Usualmente una API es una forma de conseguir estructurar datos, en formato XML o JSON, fuera de un Web Site sin estructura. LLeva a un doble acercamiento: Tienes páginas web para consumo humano y tienes un API donde las computadoras pueden meter información estructurada para procesamiento automático. Sin embargo, esto crea trabajo extra para ti; si esperas que la gente haga uso de tu API, entonces tienes que documentarlo, apoyarlo y mantenerlo sincronizado con nuevas características en tu Sitio Web. Con una Web Semántica tu sitio es la estructura de datos. No necesitas una implementación separada. Tu y tus usuarios pueden tomar ventaja de otras herramientas de Web semántica para hacer el procesamiento automático. Este aumenta algunas dificultades para planearlo. Con un API estas libre de definir tu propio formato de datos para cada item de información que quieres entregar, en la web semántica esto es análogo al definir tu propia ontología. El diseño de ontología puede ser una dificultad al conseguir un poco de experiencia, deberías considerar si cualquier de los grandes arreglos de existencia sera disponible para los tipos de datos que pleneas usar, que será discutido en la siguiente sección. Cuando diseñas un API usualmente consideras un modelo de objetos para conceptualizar la organización y los desarrolladores pueden entender cuando ellos consiguen la colección de items o simplemente items o que colección de items les pertenecen. En un sitio de Web semántica este será parcialmente determinado por la elección de la ontología, pero tambien por el esquema de URI, Luego veras el acercamiento al hacer tus URIs usables como parte de tu API. Finalmente en un web site existente tu y tus usuarios todavía se benefician de la web semántica, si actualizan su contenido al tomar ventaja de GRDDL, RDFa y microformatos.

Evaluando tus datos en un contexto de ontología existente

La parte más compleja de la web semántica es diseñar una ontología que iguales tus datos. Llegar a la correcta ontología es usualmente un elemento critico de implementación satisfactoria de proyectos de Web semántica. Afortunadamente, muchas ontologías ya existen. Tabla 1 algunas de ellas.
DublinCore Este elemento estándar metadato para cruce de dominio descripción de recurso provee un simple y estandarizado conjunto de convenciones para describir cosas en linea de manera que sean fáciles de encontrar.
SIOC Semantically-Interlinked Online Communities Project es una ontología que expresa la información contenida explicita e implícitamente en discusión de métodos en Internet, como blogs, foros o listas de correo.
FOAF The Friend of a Friend ontology (Amigo de un amigo) describe individualmente sus actividades y sus relaciones con otra gente y objetos. FOAF permite la descripción de redes sociales en una distribución de moda.
DOAP Description Of A Project (Descripción de un proyecto) es una ontología para describir proyectos open source.
ResumeRDF Esta ontología expresa un resumen o currículum vitae (CV) incluyendo información del trabajo, experiencia académica o habilidades.
Además muchas ontologías son de dominio especifico en campos como tecnología, científico, químico y lingüístico. Estas aplicaran a menos sitios web que las listadas. Un lote de tus datos es como ajustarlos dentro de al menos una de las areas cubiertas por las ontologías en la Tabla 1, en que caso puedes caso puedes incorporarlas en tu planeación.

Eligiendo un esquema semántico URI

Si tu web site es tu API, entonces tus URIs son los métodos que programadores accesará al obtener los datos. Un suceso sensible y estructura consistente es por eso muy importante, necesitas pensarlo en avanzado porque cambios frecuentes después de todo esta lanzado costará la buena voluntad de tu audiencia. Deberías tambien recordar que los componentes de un triple RDF son usualmente URIs. Al cambiarlos invalidará muchos RDF existentes que refieren a tu sitio web. En dias anteriores a la web, la estructura de URI reflejaba la organización de archivos en un servidor web. Si vendes un particular tipo de widget entre una colección de productos, este URI puede ser similar a: http://www.mysite.com/products/gadgets/widget.html. La ventaja de esto es que es relativamente semántica clara; si tambien vendes un doodad, entonces un obvio URI donde tu puedes esperar los detalles del producto es: http://www.anothersite.com/products/gadgets/doodad.html. La relación entre el widget y el dooad es lejanamente claro. El problema principal son inflexibles; la categoría de jerarquía es corregida. Como un web avanzado genera dinámicamente sitios que son la norma. Pero mientras los sitios fueran mas flexibles con estructura no grande atado a un particular esquema de archivos, el monto de información semántica en el decrementado URI. La página que muestras es determinada por alguna información criptada en la cadena de consulta. Por ejemplo, el URI del widget puede ser: http://www.mysite.com/inventory.cgi?pid=12345 y el URI del doodad puede ser: http://www.mysite.com/inventory.cgi?pid=67890. Repentinamente la URI te da un poco de valor semántico. Esto ciertamente no es claro que los dos productos pueden estar en la misma categoría. Mas recientemente los sistemas manejadores de contenido (CMS) y los frameworks de desarrollo Web empezaron a direccionar esta dificultad. Ahora es mas fácil tener URI semánticamente estructurada todavia retiene la flexibilidad de páginas dinámicas. Este es alcanzado a través de URIs que se refieren no a un archivo fisico en el servidor, pero el contenido que puede ser entregado de un script o una página en una ubicación diferente. En la configuración de Ruby en el framework Rails es alcanzado a través de rutas (reglas que mapean coincidentes URIs al especificar controladores y acciones). En paquetes CMS la característica depende en mod_rewrite de Apache (o el equivalente en otros servidores) y es a menudo referenciado como "Search engine friendly URIs" (Búsqueda de URIs amigables) o algo similar. Cuando eliges un CMS o framework de desarrollo para tu sitio mira si es capaz. Una nota final: Si es posible considerar quitar la extensión del nombre de tus archivos en los URIs. La extensión de archivo (.html, .cgi) no provee información semántica que es relevante al usuario y actualmente causa problemas en la ejecución. Si cambias tu web stie al usar PHP en lugar de scripts CGI, repentinamente tienes diferentes URIs pero cumplen el mismo propósito. Esto es malo para el valor semántico de tus URIs, tambien como el ranking Google. Un método mas elegantemente semántico es tomar ventaja de las cabeceras HTTP al hacer negociación de contenido. Considera la siguiente URI: http://www.mysite.com/products/gadgets/widget. Un browser generalmente indicaría que prefiere el tipo de contenido usando le cabecera Aceptar HTTP. Cuando pregunta por este recurso, el servidor web puede chequear esa cabecera, note text/html es una de las opciones, y sirve una página HTML. Si tienes una aplicación mashup que quiere RDF entonces la cabecera Aceptar en la petición HTTP debería contener application/rdf+xml y el servidor web de la misma URI puede servir una versión de la página RDF. Al presente este funcionalidad de negociación de contenido no esta disponible en muchas off-the-shelf soluciones CMS, pero en corto termino debería ser posible para muchos de ellos usar URIs sin las extensiones de archivo, que significa que puedes agregar esta funcionalidad en el futuro sin actualizar el esquema URI.

Tomar ventaja de herramientas de agregado semántico

Si estas emocionado de la web semántica en tu infraestructura web, o solo quieres hacer tu contenido existente mas usado, hay varias oportunidades al incluir estructura al contenido existente en tu sitio web. Este es dominio de microformatos, RDFa y GRDDL. Tabla 2 la información mas común de tipos que puedes fácilmente marcarlos como datos estructurados. Tabla 2. Oportunidades para marcar la estructura y transformación automática
Tipo de Información Estructura marcada
Gente y Organizaciones hCard, RDF vCard
Calendarios y Eventos hCalendar, RDF Calendar
Opiniones, Ratings y Revisiones VoteLinks, hReview
Redes Sociales XFN, FOAF
Licencias rel-license
Tags, Keywords, Categorias rel-tag
Listas y Outlines XOXO
Agregando el marcado estructurado a tu página es simple. Listado 3 y 4 muestra un fragmento de información de contenido HTML sin ellas y con información adicional de marcado requerido para RDF vCard respectivamente. Listado 3. Información de contacto sin estructura Listado 4. Información de contacto usando vCard En el Listado 4, puedes ver elementos span agregados al delimitar el significado semantico de texto, atributos indicando que significan. Agrega el nombre "contact" enlazado al vocabulario RDF vCard. Luego indica que este elemento es acerca del recurso representado por el URI http://example.org/staff/robertc. Entonces agregas metadatos usando el atributo rel para enlazar relaciones y el atributo property en no enlaces. La parte ligeramente compleja es el telefono porque necesitas especificar un tipo como un número. Alcanzando esto anidas el tipo y los elementos de valor dentro del elemento tel. Agregando esta estructura permite a los usuarios agregar detalles del contacto a su libro de direcciones con un simple click del mouse. Otros procesamientos automaticos es posible con otras formas estructuradas, Technorati hace uso de microformato rel-tag al categorizar esta agregación a los post del blog. Un rel-tag es mostrado en el Listado 5, y como puedes ver. es simple un link que hace uso del atributo rel. La parte significativa es la última bit de URI despues del final /. Esto es el tag (usando la normal convención de configuración URI donde un espacio es representado por un señal plus) Listado 5 rel-tag para Technorati para el tag 'semantic web' Si escribers un post de un blog realacionado a la Web Semántica que incluye el codigo del Listado 5 y haces un ping a tecnorati al dejarle saber que tu hiciste un nuevo post (mucho del software blog puede ser configurado para hacer esto automáticamente), entonces su crawler indexara tu post e incluirá un resumén de la página que tus elementos de tag enlazaron a lo largor de cualquier otros post con el mismo tag (mira la figura 2). Figura 2.La página 'web semántica' en Technorati, generado desde rel-tag [caption id="attachment_134" align="alignnone" width="286" caption="Ejemplo Web Semántica"]Ejemplo Web Semántica[/caption]

Conclusiones

En este articulo, viste como las tecnologias de web semántica direcciona la necesidad para estructurar datos en la web en una manera estandard y consistente, en contraste al actual método popular de que cada sitio definia su propio API. Puede ver como las tecnologias de web semántica agregaron valor en capas del HTTP y URIs en la web existente, primero permitiendo la expresión ambigua de relaciones con RDF, permitiéndoles compartir el significado con OWL ontologías basadas y finalmente consultar el conocimiento distribuido usando SPARQL. El post tambien enfoca en como puedes tomar ventaja de las ontologías existentes al definir que tus datos son y usan un esquema semántico URI al habilitar tu sitio web a ser tu API. Finalmente el post enfoca como puedes actualizar el contenido de tu web existente usando RDFs y Microformatos entonces con servicios GRDDL puedes automáticamente extraer RDF de tus páginas. A través de la promesa de web semántica de Tim Berners-Lee es todavía a ser realizada, los años de investigación y pensamiento están siendo hechos y empiezan a rendir frutos en términos de soluciones a problemas prácticos de la gente de hoy. La fuerte colaboración de avance en Web 2.0 lidero mas requerimientos para estructuras y codificar los datos disponibles en la red. Con alguna planeación puedes estar en posición de tomar ventaja de las herramientas de la web semántica que te ayudan a suplir esa necesidad.

Recursos

Conseguir productos y tecnologias
  • IBM trial software: Build your next development project with trial software available for download directly from developerWorks.
Discusión --- Saludos.
Secciones: 

Planificando un sitio con Web Semántica

La planeación de la web semántica me ha parecido un articulo bastante interesante por lo cual me he tomado la libertad de traducirlo de modo que me sirva para proyectos que diseñe e implemente en el futuro y de paso aportar con conocimiento a alguien mas que este en busca de nuevas tecnologías en el ámbito web. La dirección del articulo en ingles esta en la siguiente dirección: http://www.ibm.com/developerworks/xml/library/x-plansemantic/index.html?ca=drs- --

Prepara tu sitio para estructurar los datos

La Web semántica trae oportunidades para que los usuarios pueden obtener resultados inteligentes en sus búsquedas, y para sus dueños conseguir mas trafico como usuarios que buscan lo que realmente quieren. Pero estos beneficios no aparecerán mágicamente. Este post te lleva a través de los aspectos de la arquitectura de la información e infraestructura general que necesitas para tomar una verdadera ventaja de esta palpable oportunidad. Este post discute lo que necesitas saber para hacer tu sitio parte de la Web semántica. Empieza con una discusión de los problemas que la Web Semántica e intenta resolver y moverlo a tecnología involucrada, como Resource Description Framework(RDF), Web Ontology Language (OWL), and SPARQL Protocol and RDF Query Language (SPARQL). Verás como la Web Semántica es dividida en capas desde la web existente. Cubrirán algunas dificultades que quieres saber cuando planificas un nuevo Web Site y darte algunos ejemplos específicos de como usar tecnologías como RDFa y Microformatos para que tu Web Site existente sea parte de la Web Semántica.

Introducción a la Web Semántica

El World Wide Web es el gran recurso de información producido por la humanidad. Desafortunadamente, a pesar que depende de computadoras en su operación, mucha de la información es solamente entendida por humanos y no por computadoras. Mientras las computadoras pueden usar la sintaxis de los documentos HTML para mostrarla en un browser o navegador, las mismas no pueden entender el contenido-- la semántica. La Web Semántica es una visión del futuro de la web de Tim Berners-Lee. Su sueño no esta todavía realizado, suficientes bloques generados son ahora puestos para que tomes ventaja de varias tecnologías de Web Semántica en tu Web Site, incluyendo RDF, OWL y SPARQL. La meta de la Web Semántica es mostrar los recursos de información de la Web como datos que las computadoras puedan interpretar automáticamente. La web era originalmente todos los documentos. El click sobre un enlace en tu browser web dispara la petición a un Servidor web que te envie un documento, ademas que te los mostraría. El documento puede ser el calendario de los próximos 7 dias, o puede ser un correo de un amigo. El browser realmente no especifica; solo sigue las reglas internas para mostrar la página. Tu debes entender la información en la misma. Estructurando los datos se agrega valor a esos datos. Con estructura consistente, puede ser usado en mas de una forma. Puedes ver hoy en dia la demanda de la estructura de datos en la proliferación de APIs que se tienen suspendida en sitios web como parte de la Web 2.0 un API esta estructurando datos, de una variedad de fuentes de los poderosos mashups. La idea tras los mashups es que los datos con incluidos de varias fuentes en la Web, cuando son combinados y mostrados en una manera unificada, esta combinación de elementos agrega valor y eleva la fuente de información. Los APIs individuales que todos estan ocupando para resolver el mismo extracto del problema que la Web Semántica esta intentando direccionar: Exponer el contenido de la web como datos y disparar la combinación de fuentes de datos en diferentes formas al generar un nuevo valor. Mas bien generar y mantener tu propio API, puedes generar tu Web site tomando gran ventaja de la infraestructura de la Web Semántica que ya tiene su lugar. Si tu web site es tu API, puedes reducir la sobrecarga de desarrollarlo y mantenerlo. De forma similiar, generara soluciones personalizadas para cada web site donde quiere poner datos, puedes implementar una solución basada en tecnologías de Web Semántica y tener trabajo intercambiable en muchos web sites -- incluyendo web sites que no estaban consciente antes de empezar a desarrollar.

Resumen de tecnologías de Web Semántica

Las tecnologías de Web Semántica pueden ser consideradas en términos de capas, cada capa descansa y extiende la funcionalidad de las debajo de la capas. La Web semántica esta hablando a menudo como si hubiera una entidad separada, es una extensión y mejora de la web existente sino un reemplazo. Figura 1. Pila de la tecnología de la Web Semántica [caption id="attachment_129" align="alignnone" width="208" caption="Pila de la Web Semántica"]Pila de la Web Semántica[/caption] Como se muestra en la Figura 1, la capa base de la Web Semántica es HTTP y URIs. Son comúnmente consideradas "Web" sino "Web Semántica", pero cada propósito de la tecnología de la Web Semántica descansa en los principios Web. URIs son los nombres de la Web Semántica. HTTP son los verbos: GET, PUT y POST tambien como un numero de soluciones probadas en los campos de autenticación y encriptación. El Resource Description Framework (RDF) es una gramática para codificar relaciones. Un triple RDF tiene tres componentes: un sujeto, un predicado (o verbo), y un objeto. Cada uno puede ser expresado como un recurso en la Web, eso es un URI. Es medio ambiguo codificar datos en documentos XML aleatorios. Puedes comparar las diferentes formas de expresar una relación en XML mediante el Listado 1 con el triple RDF en el Listado 2. Listado 1: Relaciones ambiguas en XML
  • <author>
        <uri>page</uri>
        <name>Rob</name>
    </author>
    
    <person name="Rob">
        <work>page</work>
    </person>
    
    <document href="http://www.example.org/test/page" author="Rob" />
Listado 2 muestra el triple RDF Listado 2: Relaciones ambiguas en XML
  • <page> <author> <Rob> .
Las relaciones expresadas en los ejemplos mostrados en Listado 1 es "Rob es el autor de página" una simple sentencia-- todavía expresada en varias formas en XML. Debería ser difícil generar software que derive esa relación desde todas las maneras posibles de expresarlo en XML. Pero un expresado RDF que relaciona solamente una forma viene a ser factible al generar un parser genérico. En dias anteriores a la Web semántica, estaba esperando producir contenido debía hacer todo su contenido disponible en RDF y hacer pronto una metafora de los datos disponibles. Desafortunadamente, quizas porque la principal expresión XML de RDF se veia una innecesaria complejidad. de lentitud. Mas sucesos de representaciones RDF, como Notation3 (N3) y Terse RDF Triple Languaje (Turtle) estan ahora disponibles pero han sido desactivados al sobrevenirse la inercia. Una solución al problema fue inspirada por los microformatos. Con microformatos, el valor semántico es agregado al contenido existente HTML usando patrones consistentes de estándares en elementos y atributos HTML. Microformatos existen para estrechar items comunes de datos como información de contenido e items de calendario. El equivalente de W3C es RDFa, los datos embebidos RDF en XHTML. La implementación es ligeramente mas compleja que los microformatos pero es lejanamente mas genérico -- nada que puedas expresar en RDF, puedes agregarlo a documentos XHTML usando RDFa. A traves de esta técnica la Web Semántica puede ser inicializada en contenido existente web. Por supuesto el RDF embebido en documentos XHTML como RDFa no es bueno para todos las herramientas de Web Semántica, que requieren salida. La solución W3C para esto es Gleaning Resource Descriptions from Dialects of Languages (GRDDL). La idea es que puedes ejecutar un documento XHTML existente a traves de una transformación XLS al generar RDF. Puedes enlazar cualquier transformación GRDDL a traves de la directa inclusión de referencias o indirectamente a través de perfiles y nombres de documento. Mientras la ambigüedad expresada semánticamente con RDF es buena, aunque si cualquier lo hizo, es de poco uso si no tienes idea de como el RDF en diferentes sitios es relacionado. El RDF triple en el Listado 2 expresa una relación de autor en el predicado, y mientras el significado puede ser obvio para ti, las computadoras necesitan ayuda. Si expresas una relación de autor en un archivo RDF en un sitio, puede la computadora asumir que fueran la misma cosa? Que si tienes una relación escrita en RDF triple? Necesitas una forma al expresar un vocabulario común, será capaz de decir que mi autor y tu autor son la misma cosa, y que el "autor" y el "escritor" son análogos. En la web Semántica este problema es resuelto por ontologías, y el estándar W3C para expresar ontologías es el Lenguaje de Ontología Web (OWL). Una vez que tienes algunas fuentes de datos en RDF, y tienes ontologías para permitir determinar las relaciones entre ellas, necesitas una forma de conseguir el uso de información fuera de ellos. El protocolo simple y RDF Query Language (o SPARQL, pronunciado 'sparkle') es una sintaxis como SQL para expresar consultas entre datos RDF y ver las consultas que actúen como datos RDF. El paradigma fundamental para SPARQL es un patrón de concordancia y es diseñado para trabajar en la Web como datos combinados al disparar fuentes y ser flexibles. Por ejemplo concordancias pueden ser descritas como opcionales, que lo hacen mucho mejor que en la consulta de datos SQL rotos. Romper datos tiene una impredecible e inconfiable estructura, que es que puedes esperar encontrar si tus datos estan combinados de varias fuentes en la Web sino desde una simple bien controlada base de datos.

Lo que necesitas saber cuando planeas una Web Semántica

Como lo has visto, si generas el próximo gran sito Web 2.0, puedes ahorrar tiempo si planeas desde el inicio a el uso de la tecnología de Web semántica y cambiar tu Web Site en un API, si no crear una API separado para su Web Site. Una Web Semántica te da libre funcionalidad como API. Usualmente una API es una forma de conseguir estructurar datos, en formato XML o JSON, fuera de un Web Site sin estructura. LLeva a un doble acercamiento: Tienes páginas web para consumo humano y tienes un API donde las computadoras pueden meter información estructurada para procesamiento automático. Sin embargo, esto crea trabajo extra para ti; si esperas que la gente haga uso de tu API, entonces tienes que documentarlo, apoyarlo y mantenerlo sincronizado con nuevas características en tu Sitio Web. Con una Web Semántica tu sitio es la estructura de datos. No necesitas una implementación separada. Tu y tus usuarios pueden tomar ventaja de otras herramientas de Web semántica para hacer el procesamiento automático. Este aumenta algunas dificultades para planearlo. Con un API estas libre de definir tu propio formato de datos para cada item de información que quieres entregar, en la web semántica esto es análogo al definir tu propia ontología. El diseño de ontología puede ser una dificultad al conseguir un poco de experiencia, deberías considerar si cualquier de los grandes arreglos de existencia sera disponible para los tipos de datos que pleneas usar, que será discutido en la siguiente sección. Cuando diseñas un API usualmente consideras un modelo de objetos para conceptualizar la organización y los desarrolladores pueden entender cuando ellos consiguen la colección de items o simplemente items o que colección de items les pertenecen. En un sitio de Web semántica este será parcialmente determinado por la elección de la ontología, pero tambien por el esquema de URI, Luego veras el acercamiento al hacer tus URIs usables como parte de tu API. Finalmente en un web site existente tu y tus usuarios todavía se benefician de la web semántica, si actualizan su contenido al tomar ventaja de GRDDL, RDFa y microformatos.

Evaluando tus datos en un contexto de ontología existente

La parte más compleja de la web semántica es diseñar una ontología que iguales tus datos. Llegar a la correcta ontología es usualmente un elemento critico de implementación satisfactoria de proyectos de Web semántica. Afortunadamente, muchas ontologías ya existen. Tabla 1 algunas de ellas.
DublinCore Este elemento estándar metadato para cruce de dominio descripción de recurso provee un simple y estandarizado conjunto de convenciones para describir cosas en linea de manera que sean fáciles de encontrar.
SIOC Semantically-Interlinked Online Communities Project es una ontología que expresa la información contenida explicita e implícitamente en discusión de métodos en Internet, como blogs, foros o listas de correo.
FOAF The Friend of a Friend ontology (Amigo de un amigo) describe individualmente sus actividades y sus relaciones con otra gente y objetos. FOAF permite la descripción de redes sociales en una distribución de moda.
DOAP Description Of A Project (Descripción de un proyecto) es una ontología para describir proyectos open source.
ResumeRDF Esta ontología expresa un resumen o currículum vitae (CV) incluyendo información del trabajo, experiencia académica o habilidades.
Además muchas ontologías son de dominio especifico en campos como tecnología, científico, químico y lingüístico. Estas aplicaran a menos sitios web que las listadas. Un lote de tus datos es como ajustarlos dentro de al menos una de las areas cubiertas por las ontologías en la Tabla 1, en que caso puedes caso puedes incorporarlas en tu planeación.

Eligiendo un esquema semántico URI

Si tu web site es tu API, entonces tus URIs son los métodos que programadores accesará al obtener los datos. Un suceso sensible y estructura consistente es por eso muy importante, necesitas pensarlo en avanzado porque cambios frecuentes después de todo esta lanzado costará la buena voluntad de tu audiencia. Deberías tambien recordar que los componentes de un triple RDF son usualmente URIs. Al cambiarlos invalidará muchos RDF existentes que refieren a tu sitio web. En dias anteriores a la web, la estructura de URI reflejaba la organización de archivos en un servidor web. Si vendes un particular tipo de widget entre una colección de productos, este URI puede ser similar a: http://www.mysite.com/products/gadgets/widget.html. La ventaja de esto es que es relativamente semántica clara; si tambien vendes un doodad, entonces un obvio URI donde tu puedes esperar los detalles del producto es: http://www.anothersite.com/products/gadgets/doodad.html. La relación entre el widget y el dooad es lejanamente claro. El problema principal son inflexibles; la categoría de jerarquía es corregida. Como un web avanzado genera dinámicamente sitios que son la norma. Pero mientras los sitios fueran mas flexibles con estructura no grande atado a un particular esquema de archivos, el monto de información semántica en el decrementado URI. La página que muestras es determinada por alguna información criptada en la cadena de consulta. Por ejemplo, el URI del widget puede ser: http://www.mysite.com/inventory.cgi?pid=12345 y el URI del doodad puede ser: http://www.mysite.com/inventory.cgi?pid=67890. Repentinamente la URI te da un poco de valor semántico. Esto ciertamente no es claro que los dos productos pueden estar en la misma categoría. Mas recientemente los sistemas manejadores de contenido (CMS) y los frameworks de desarrollo Web empezaron a direccionar esta dificultad. Ahora es mas fácil tener URI semánticamente estructurada todavia retiene la flexibilidad de páginas dinámicas. Este es alcanzado a través de URIs que se refieren no a un archivo fisico en el servidor, pero el contenido que puede ser entregado de un script o una página en una ubicación diferente. En la configuración de Ruby en el framework Rails es alcanzado a través de rutas (reglas que mapean coincidentes URIs al especificar controladores y acciones). En paquetes CMS la característica depende en mod_rewrite de Apache (o el equivalente en otros servidores) y es a menudo referenciado como "Search engine friendly URIs" (Búsqueda de URIs amigables) o algo similar. Cuando eliges un CMS o framework de desarrollo para tu sitio mira si es capaz. Una nota final: Si es posible considerar quitar la extensión del nombre de tus archivos en los URIs. La extensión de archivo (.html, .cgi) no provee información semántica que es relevante al usuario y actualmente causa problemas en la ejecución. Si cambias tu web stie al usar PHP en lugar de scripts CGI, repentinamente tienes diferentes URIs pero cumplen el mismo propósito. Esto es malo para el valor semántico de tus URIs, tambien como el ranking Google. Un método mas elegantemente semántico es tomar ventaja de las cabeceras HTTP al hacer negociación de contenido. Considera la siguiente URI: http://www.mysite.com/products/gadgets/widget. Un browser generalmente indicaría que prefiere el tipo de contenido usando le cabecera Aceptar HTTP. Cuando pregunta por este recurso, el servidor web puede chequear esa cabecera, note text/html es una de las opciones, y sirve una página HTML. Si tienes una aplicación mashup que quiere RDF entonces la cabecera Aceptar en la petición HTTP debería contener application/rdf+xml y el servidor web de la misma URI puede servir una versión de la página RDF. Al presente este funcionalidad de negociación de contenido no esta disponible en muchas off-the-shelf soluciones CMS, pero en corto termino debería ser posible para muchos de ellos usar URIs sin las extensiones de archivo, que significa que puedes agregar esta funcionalidad en el futuro sin actualizar el esquema URI.

Tomar ventaja de herramientas de agregado semántico

Si estas emocionado de la web semántica en tu infraestructura web, o solo quieres hacer tu contenido existente mas usado, hay varias oportunidades al incluir estructura al contenido existente en tu sitio web. Este es dominio de microformatos, RDFa y GRDDL. Tabla 2 la información mas común de tipos que puedes fácilmente marcarlos como datos estructurados. Tabla 2. Oportunidades para marcar la estructura y transformación automática
Tipo de Información Estructura marcada
Gente y Organizaciones hCard, RDF vCard
Calendarios y Eventos hCalendar, RDF Calendar
Opiniones, Ratings y Revisiones VoteLinks, hReview
Redes Sociales XFN, FOAF
Licencias rel-license
Tags, Keywords, Categorias rel-tag
Listas y Outlines XOXO
Agregando el marcado estructurado a tu página es simple. Listado 3 y 4 muestra un fragmento de información de contenido HTML sin ellas y con información adicional de marcado requerido para RDF vCard respectivamente. Listado 3. Información de contacto sin estructura Listado 4. Información de contacto usando vCard En el Listado 4, puedes ver elementos span agregados al delimitar el significado semantico de texto, atributos indicando que significan. Agrega el nombre "contact" enlazado al vocabulario RDF vCard. Luego indica que este elemento es acerca del recurso representado por el URI http://example.org/staff/robertc. Entonces agregas metadatos usando el atributo rel para enlazar relaciones y el atributo property en no enlaces. La parte ligeramente compleja es el telefono porque necesitas especificar un tipo como un número. Alcanzando esto anidas el tipo y los elementos de valor dentro del elemento tel. Agregando esta estructura permite a los usuarios agregar detalles del contacto a su libro de direcciones con un simple click del mouse. Otros procesamientos automaticos es posible con otras formas estructuradas, Technorati hace uso de microformato rel-tag al categorizar esta agregación a los post del blog. Un rel-tag es mostrado en el Listado 5, y como puedes ver. es simple un link que hace uso del atributo rel. La parte significativa es la última bit de URI despues del final /. Esto es el tag (usando la normal convención de configuración URI donde un espacio es representado por un señal plus) Listado 5 rel-tag para Technorati para el tag 'semantic web' Si escribers un post de un blog realacionado a la Web Semántica que incluye el codigo del Listado 5 y haces un ping a tecnorati al dejarle saber que tu hiciste un nuevo post (mucho del software blog puede ser configurado para hacer esto automáticamente), entonces su crawler indexara tu post e incluirá un resumén de la página que tus elementos de tag enlazaron a lo largor de cualquier otros post con el mismo tag (mira la figura 2). Figura 2.La página 'web semántica' en Technorati, generado desde rel-tag [caption id="attachment_134" align="alignnone" width="286" caption="Ejemplo Web Semántica"]Ejemplo Web Semántica[/caption]

Conclusiones

En este articulo, viste como las tecnologias de web semántica direcciona la necesidad para estructurar datos en la web en una manera estandard y consistente, en contraste al actual método popular de que cada sitio definia su propio API. Puede ver como las tecnologias de web semántica agregaron valor en capas del HTTP y URIs en la web existente, primero permitiendo la expresión ambigua de relaciones con RDF, permitiéndoles compartir el significado con OWL ontologías basadas y finalmente consultar el conocimiento distribuido usando SPARQL. El post tambien enfoca en como puedes tomar ventaja de las ontologías existentes al definir que tus datos son y usan un esquema semántico URI al habilitar tu sitio web a ser tu API. Finalmente el post enfoca como puedes actualizar el contenido de tu web existente usando RDFs y Microformatos entonces con servicios GRDDL puedes automáticamente extraer RDF de tus páginas. A través de la promesa de web semántica de Tim Berners-Lee es todavía a ser realizada, los años de investigación y pensamiento están siendo hechos y empiezan a rendir frutos en términos de soluciones a problemas prácticos de la gente de hoy. La fuerte colaboración de avance en Web 2.0 lidero mas requerimientos para estructuras y codificar los datos disponibles en la red. Con alguna planeación puedes estar en posición de tomar ventaja de las herramientas de la web semántica que te ayudan a suplir esa necesidad.

Recursos

Conseguir productos y tecnologias
  • IBM trial software: Build your next development project with trial software available for download directly from developerWorks.
Discusión --- Saludos.
Secciones: 

Semantificación de Joomla

Este articulo va orientado a integrar joomla a lo que es la web semántica mediante un proyecto llamado Triplify que no es otra cosa incluir un archivo de configuración que significa escribir un número de consultas SQL usado información valida del esquema de base de datos de Joomla. Triplify con la configuración creada sera incluido en el código fuente de Joomla.(o incluido como extensión o como plugin). En enlace del articulo en ingles se los pego a continuación: http://dev.joomla.org/content/view/2343/90/ --

Joomla! semantificación - exponer datos Joomla como RDF y datos enlazados

El último año, Joomla tiene mas de 3 millones de descargas. De este hecho, considera cuantos sitios utilizan joomla! y el volumén de contenido producido diariamente. Entonces, considera como este contenido son datos aislados sin ninguna habilidad de linkear automáticamente este contenidoa otros sitios o ser capaz de reusar datos como mashups. Actualmente, podemos ya reusar los datos con alimentación RSS, but RSS es tan simple expresar la potencialidad explicita entre ellos. de ideas de Triplify, nos proponemos acercar los datos enlazados qu e habilitan usuarios navegar desde los datos relacionados a traves de links RDF. Este link es actuamente una setencia semántica de estos datos y pueden ser publicados por URI, por ejemplo, "el username Ipdanh tiene por nombre Danh Le Phuoc quien tiene su página web con URL y tiene el articulo http://example.com/articled=100 con el titulo `Enlaces semanticos para Joomla" y ve tambien la versión extendida en el articulo http://anotherblogsite.net/blogid=200, etc". Estos enlaces puede ser codificados en fo rmato RDF wue puede estar listos para mashup de datos cruzando los borders de cualquier contenido producido por sistemas como CMS, Webblogs, Lista de correo, Foros, etc, sin requerir esquema interno de datos relevantes. Este proyecto ganará al incrementar enlaces semanticos para Joomla! elementos de bases de datos basado en vocabulario formalizado por FOAF and SIOC. Estos vocabularios están ya integrados a contenidos de muchas plataformas populares como Wordpress, phpBB, Listas de correo, Drupal, etc., por eso jugarán roles como los ejes semanticos para datos enlazados entre esos datos producidos. Siguiendo el acercamiento de Triplify que gana crear "un pequeño plugin para aplicaciones web, que revela la estructura semantica codificada en bases de datos relacionales por hacer contenido de base de datos disponible como RDF" este proyecto creará una extensión Joomla! para mapear elementos de base de datos a vocabularios semanticos y para generar salidas RDF para articulos Joomla. Al hacer la configuración "Triplifizing" mas configurable y amigable, una herramienta de mapeo será generada en este proyecto. Esta herramienta de mapeo es un conjunto de formularios AJAX que activan al desarrollador del sitio a elegir los datos esperados de cada componente por el asistente. Un exportador RDF será creado al exportar datos de elementos de la base de datos especificados en las reglas de mapeo guardados desde las herramientas de mapeo. Además, el usuario final puede explorar este datos RDF por recomendados browsers RDF/SIOC, una herramienta de previsualización para los datos RDF debe ser integrada a esta extensión. Referencias: [1] Linked data : http://LinkedData.org/ [2] Resource Description Framework (RDF) / W3C Semantic Web Activity : http//www.w3.org/RDF/ [3] FOAF project : http://www.foaf-project.org/ [4] SIOC project : http://www.sioc-project.org/ [5] Dublin core : http://dublincore.org/ [6] Geonames : http://www.geonames.org/ [7] http://www.w3.org/2003/01/geo/ [8] Sioc browers : http://rdfs.org/sioc/applications/#browsing [9] Sioc export api :http://www.sioc-project.org/phpapi [10] UserMeta extension : http://jo omlacode.org/gf/project/usermeta/frs/ [11] Exhibit : http://simile.mit.edu/exhibit/ [12] Semantic Web Crawling : A Sitemap exention : http://sw.deri.org/2007/07/sitemapextension/ [13] Draw2d : http://www.draw2d.org/ [14] SKOS : http://www.w3.org/2004/02/skos/ [15] ARC :http://arc.semsol.org/ [16] Dbpedia datasets : http://wiki.dbpedia.org/Datasets [17] Triplify : http://triplify.org/ , and Integrate Triplify into Joomla (http://www.cofundos.org/project.php?id=112) [18] SchemaWeb : http://www.schemaweb.info
Secciones: 

Semantificación de Joomla

Este articulo va orientado a integrar joomla a lo que es la web semántica mediante un proyecto llamado Triplify que no es otra cosa incluir un archivo de configuración que significa escribir un número de consultas SQL usado información valida del esquema de base de datos de Joomla. Triplify con la configuración creada sera incluido en el código fuente de Joomla.(o incluido como extensión o como plugin). En enlace del articulo en ingles se los pego a continuación: http://dev.joomla.org/content/view/2343/90/ --

Joomla! semantificación - exponer datos Joomla como RDF y datos enlazados

El último año, Joomla tiene mas de 3 millones de descargas. De este hecho, considera cuantos sitios utilizan joomla! y el volumén de contenido producido diariamente. Entonces, considera como este contenido son datos aislados sin ninguna habilidad de linkear automáticamente este contenidoa otros sitios o ser capaz de reusar datos como mashups. Actualmente, podemos ya reusar los datos con alimentación RSS, but RSS es tan simple expresar la potencialidad explicita entre ellos. de ideas de Triplify, nos proponemos acercar los datos enlazados qu e habilitan usuarios navegar desde los datos relacionados a traves de links RDF. Este link es actuamente una setencia semántica de estos datos y pueden ser publicados por URI, por ejemplo, "el username Ipdanh tiene por nombre Danh Le Phuoc quien tiene su página web con URL y tiene el articulo http://example.com/articled=100 con el titulo `Enlaces semanticos para Joomla" y ve tambien la versión extendida en el articulo http://anotherblogsite.net/blogid=200, etc". Estos enlaces puede ser codificados en fo rmato RDF wue puede estar listos para mashup de datos cruzando los borders de cualquier contenido producido por sistemas como CMS, Webblogs, Lista de correo, Foros, etc, sin requerir esquema interno de datos relevantes. Este proyecto ganará al incrementar enlaces semanticos para Joomla! elementos de bases de datos basado en vocabulario formalizado por FOAF and SIOC. Estos vocabularios están ya integrados a contenidos de muchas plataformas populares como Wordpress, phpBB, Listas de correo, Drupal, etc., por eso jugarán roles como los ejes semanticos para datos enlazados entre esos datos producidos. Siguiendo el acercamiento de Triplify que gana crear "un pequeño plugin para aplicaciones web, que revela la estructura semantica codificada en bases de datos relacionales por hacer contenido de base de datos disponible como RDF" este proyecto creará una extensión Joomla! para mapear elementos de base de datos a vocabularios semanticos y para generar salidas RDF para articulos Joomla. Al hacer la configuración "Triplifizing" mas configurable y amigable, una herramienta de mapeo será generada en este proyecto. Esta herramienta de mapeo es un conjunto de formularios AJAX que activan al desarrollador del sitio a elegir los datos esperados de cada componente por el asistente. Un exportador RDF será creado al exportar datos de elementos de la base de datos especificados en las reglas de mapeo guardados desde las herramientas de mapeo. Además, el usuario final puede explorar este datos RDF por recomendados browsers RDF/SIOC, una herramienta de previsualización para los datos RDF debe ser integrada a esta extensión. Referencias: [1] Linked data : http://LinkedData.org/ [2] Resource Description Framework (RDF) / W3C Semantic Web Activity : http//www.w3.org/RDF/ [3] FOAF project : http://www.foaf-project.org/ [4] SIOC project : http://www.sioc-project.org/ [5] Dublin core : http://dublincore.org/ [6] Geonames : http://www.geonames.org/ [7] http://www.w3.org/2003/01/geo/ [8] Sioc browers : http://rdfs.org/sioc/applications/#browsing [9] Sioc export api :http://www.sioc-project.org/phpapi [10] UserMeta extension : http://jo omlacode.org/gf/project/usermeta/frs/ [11] Exhibit : http://simile.mit.edu/exhibit/ [12] Semantic Web Crawling : A Sitemap exention : http://sw.deri.org/2007/07/sitemapextension/ [13] Draw2d : http://www.draw2d.org/ [14] SKOS : http://www.w3.org/2004/02/skos/ [15] ARC :http://arc.semsol.org/ [16] Dbpedia datasets : http://wiki.dbpedia.org/Datasets [17] Triplify : http://triplify.org/ , and Integrate Triplify into Joomla (http://www.cofundos.org/project.php?id=112) [18] SchemaWeb : http://www.schemaweb.info
Secciones: 

Cuando Usar diagramas UML

Cuando empezamos a desarrollar un sistema por lo general nos encontramos con la dificultad de no saber cuando utilizar diagramas UML y cuando no hacerlo .. muchos de nosotros de preferencia no lo hacemos pues veamos algunas razones para hacer y no hacerlo según lo dice en su libro "UML para programadores Java" Prentice Hall. No hacer una regla que todo debe ser diagramado. Enorme monto de tiempo en un proyecto puede ser gastado en diagramas que nadie leera.

Cuando utilizar los diagramas

  • Utilizar los diagramas cuando varias personas necesiten entender la estructura de una particular parte del diseño porque todos ellos lo estarán trabajando simultáneamente. Detengase cuando todos ellos esten de acuerdo que lo han entendido.
  • Cuando dos o mas personas esten en desacuerdo con un elemento particular debería ser diseñado, y quieres un consenso del equipo. Pon la discusión dentro de una caja de tiempo para elegir un significado para decidir, como un voto o un juicio imparcial. Detente cuando la decisión haya sido tomada. Borra el diagrama.
  • Cuando quieras jugar con una idea de diseño, y los diagramas pueden ayudarte a entenderlo. Detente cuando hayas conseguido finalizar el punto que querías codificar. Descarta el diagrama.
  • Cuando necesites exponer una estructura de alguna parte del código a alguien mas o a ti mismo. Detente cuando la explicación deberla ser mejor hecha viendo el código.
  • Cuando este cerca al la finalización del proyecto y tus clientes tienen peticiones como parte de un flujo de documentación para otros.

Cuando no utilizar diagramas

  • No dibujar diagramas porque el proceso te lo dice
  • Porque te sientes culpable de no hacerlo o porque piensas que es buen diseño hacerlo. Los buenos diseñadores escriben código y dibujan diagramas solamente cuando es necesario.
  • No dibujar diagramas para crear comprensiva documentación de la fase de diseño priori al código. Los documentos casi no tienen ningún valor y consumen inmensos montos de tiempo.
  • Dibujar diagramas para que otra persona codifique. La verdadera arquitectura del software participa en la codificación de sus diseños, lo pueden poner en la cama y tenerlo hecho.

Epa epa epa pero que hay de la documentación ?

La buena documentación es esencial en cualquier proyecto. Sin esta el equipo se perdería en un mar de código. Por otro lado mucha documentación de la clase equivocada es mala; porque entonces tendras toda esa distracción y papeles engañosos y todavía tendrías el mar de código. La documentación debe ser creada pero prudentemente. A menudo la elección de no documentar es tan importante como un documento. Un protocolo complejo de comunicación debe ser documentado. Un complejo esquema de relación necesita ser documentado. Un complejo framework reusable debe ser documentado. Sin embargo ninguna de estar cosas necesita cientos de paginas de UML. La documentación del software debe ser pequeña y puntual. El valor del documento del software es inversamente proporcional al tamaño. Pondría esta documentación en un wiki o alguna herramienta colaborativa entonces que cualquiera del equipo podría tener acceso a ella, buscar y podría modificarla según la necesidad Esto toma un gran monto de trabajo hacer un documento pequeño pero que el trabajo este bien, la gente leera un documento pequeño a diferencia de un documento de 1000 hojas. -- Saludos y espero les sirva de mucho.
Secciones: 

Cuando Usar diagramas UML

Cuando empezamos a desarrollar un sistema por lo general nos encontramos con la dificultad de no saber cuando utilizar diagramas UML y cuando no hacerlo .. muchos de nosotros de preferencia no lo hacemos pues veamos algunas razones para hacer y no hacerlo según lo dice en su libro "UML para programadores Java" Prentice Hall. No hacer una regla que todo debe ser diagramado. Enorme monto de tiempo en un proyecto puede ser gastado en diagramas que nadie leera.

Cuando utilizar los diagramas

  • Utilizar los diagramas cuando varias personas necesiten entender la estructura de una particular parte del diseño porque todos ellos lo estarán trabajando simultáneamente. Detengase cuando todos ellos esten de acuerdo que lo han entendido.
  • Cuando dos o mas personas esten en desacuerdo con un elemento particular debería ser diseñado, y quieres un consenso del equipo. Pon la discusión dentro de una caja de tiempo para elegir un significado para decidir, como un voto o un juicio imparcial. Detente cuando la decisión haya sido tomada. Borra el diagrama.
  • Cuando quieras jugar con una idea de diseño, y los diagramas pueden ayudarte a entenderlo. Detente cuando hayas conseguido finalizar el punto que querías codificar. Descarta el diagrama.
  • Cuando necesites exponer una estructura de alguna parte del código a alguien mas o a ti mismo. Detente cuando la explicación deberla ser mejor hecha viendo el código.
  • Cuando este cerca al la finalización del proyecto y tus clientes tienen peticiones como parte de un flujo de documentación para otros.

Cuando no utilizar diagramas

  • No dibujar diagramas porque el proceso te lo dice
  • Porque te sientes culpable de no hacerlo o porque piensas que es buen diseño hacerlo. Los buenos diseñadores escriben código y dibujan diagramas solamente cuando es necesario.
  • No dibujar diagramas para crear comprensiva documentación de la fase de diseño priori al código. Los documentos casi no tienen ningún valor y consumen inmensos montos de tiempo.
  • Dibujar diagramas para que otra persona codifique. La verdadera arquitectura del software participa en la codificación de sus diseños, lo pueden poner en la cama y tenerlo hecho.

Epa epa epa pero que hay de la documentación ?

La buena documentación es esencial en cualquier proyecto. Sin esta el equipo se perdería en un mar de código. Por otro lado mucha documentación de la clase equivocada es mala; porque entonces tendras toda esa distracción y papeles engañosos y todavía tendrías el mar de código. La documentación debe ser creada pero prudentemente. A menudo la elección de no documentar es tan importante como un documento. Un protocolo complejo de comunicación debe ser documentado. Un complejo esquema de relación necesita ser documentado. Un complejo framework reusable debe ser documentado. Sin embargo ninguna de estar cosas necesita cientos de paginas de UML. La documentación del software debe ser pequeña y puntual. El valor del documento del software es inversamente proporcional al tamaño. Pondría esta documentación en un wiki o alguna herramienta colaborativa entonces que cualquiera del equipo podría tener acceso a ella, buscar y podría modificarla según la necesidad Esto toma un gran monto de trabajo hacer un documento pequeño pero que el trabajo este bien, la gente leera un documento pequeño a diferencia de un documento de 1000 hojas. -- Saludos y espero les sirva de mucho.
Secciones: 

Liga de Quito 2008...

Campeón de la Libertadores 2008 No soy hincha de la Liga de Quito pero si soy Ecuatoriano, es para mi un placer el saber y presenciar que un equipo Ecuatoriano figura como Campeón por fin en el torneo mas importante de América a nivel de clubes es un logro destacado para nuestro país el demostrar como ha crecido nuestro fútbol en los últimos años que no me vengan a decir que estos últimos mundiales a los que hemos llegado son de suerte o pura casualidad o que solo por la altura de Quito se ha clasificado, ha sido un trabajo constante y una evolucion de los jugadores, ahora si podemos decir que tenemos varias cuotas foraneas para las eliminatorias y de calidad. Cevallos una persona que ha demostrado que solo se necesita de un poco de confianza, y es lo que Liga de Quito, sus directivos y demas le han sabido dar, si decide retirarse lo hara por la puerta grande no como que ya ha cumplido su periodo y que esta viejo como lo dijeron alguna vez en otro equipo. El héroe de este importante triunfo es José Francisco Cevallos al atajar varios disparos a su puerta y sobre todo hacer uso de toda su experiencia en la tanda de penaltis. "Por amor siempre debes decir por donde quiera que tu estes ... Ecuatoriano SOY !!!" En la ciudad de Loja se lo vivio como en todo el Ecuador con las ganas y el aliento respaldando a nuestro representante en la Libertadores, no vamos a caer en envidias y resentimientos en tener tan poca capacidad craneal como para no apoyar a nuestro país, aqui en nuestra ciudad se lo festejo en diferentes lugares como en la pileta en el parque de la Catedral, San Sebastián y en todos los bares de la ciudad. Aquí pongo algunos de los criterios emitidos por lo jugadores de la Liga de Quito: "Todo fue cuestión de meterle ganas y mantener la calma, y sobre todo gracias a Dios": Jofre Guerrón "Liga de Quito un equipo muy humilde que no se cayó nunca": Claudio Bieler "Ya hicimos historia llegando a las semifinales y no nos queríamos quedar con las manos vacías. Este título es para Ecuador que tanto lo necesita": Bieler. "Este titulo va para todo un país": José Cevallos Creo que no olvidaremos por un buen tiempo estos jugadores que cambiaron la historia de nuestro fútbol a nivel mundial.

ARQUERO

José Cevallos (#1) Tapa penales. Da seguridad al equipo por su experiencia.

LATERAL DERECHO

Jairo Campos (#23) Polifuncional. Rinde donde lo pongan.

ZAGUERO POR DERECHA

Renán Calle (#3) Seguro en los cruces.

ZAGUERO POR IZQUIERDA

Norberto Araujo (#3) Rápido en el anticipo y sobrio en el juego aéreo. LATERAL IZQUIERDO Paúl Ambrossi (#4) Da constante salida por ese sector.

VOLANTES DE CONTENCIÓN

Patricio Urrutia (#8 ) El capitán ‘albo’. Ordena la mitad de la cancha con criterio. Administra bien el balón y es goleador, además es quien levanta la Copa Libertadores. Enrique Vera (#20) Se corre toda la cancha sin cansarse. Pega cuando debe.

VOLANTES DE CREACIÓN

Luis Bolaños (#7) Rápido para trasportar el balón. En los cambios de ritmo nadie lo para. Damián Manso (#21) Preciso en los pases profundos. Buena visión del campo de juego.

DELANTEROS

Claudio Bieler Apoya en la marca desde el área rival. Jofre Guerrón (#19) Rápido y fuerte. Necesitan más de un rival para marcarlo. Corre como loco.

DIRECTOR TÉCNICO

Edgardo Bauza El ‘Patón’ llega a su primera final con mucha experiencia en varios países de América del Sur. Persistente en sus ideas hasta las últimas consecuencias. El tiempo le ha dado la razón. --

Saludos y que siga la música.

Secciones: