Modelo de Casos de Uso Formato breve Edición de QNames La aplicación permitira al usuario el ingreso de QNames para ser utilizados en cualquier parte donde ingresar un URI sea necesario. De este modo el usuario podrá ingresar el URI que desea completo o ingresarlo utilizando el QName. El usuario podrá editar los QNames a utilizar (crear, modificar y borrar). Para realizar cualquiera de estas operaciones sobre los QName, se deben identificar por medio de prefijo. La información de los QNames es la siguiente: Prefijo. URI asociado con el prefijo. Anotaciones sobre el QName. Además, inicialmente se debe contar con algunos QNames por omisión que son bastantes comunes como: Prefijo rdf rdfs dc Namespace http://www.w3.org/1999/02/22-rdf-syntax-ns# http://www.w3.org/2000/01/rdf-schema# http://purl.org/dc/elements/1.1/ Anotación Términos básicos de RDF. Términos de RDFS Terminos para describir información muy usada. Ingreso de Resources El usuario puede crear un Resource (Sujeto, Propiedad y Objeto son Resources) en un modelo indicando un URIref. El usuario debe indicar el URIref del Resource y la aplicación lo ingresara. Este URIref tambien se puede ingresar utilizando QNames. Ingreso de Statements La aplicación permitirá ingresar statements sobre los Resources ingresados previamente. Se debe indicar el Resource sobre el cual se desea decir algo. Luego se debe indicar el valor del URIref de la propiedad y del objeto. La propiedad de la aserción debe escogerse de uno de los Resources previamente ingresados. Si el Object de la aserción es un Resource, este debe ser previamente ingresado. También como Object de la aserción se puede ingresar un valor literal. En la creación de los Statements, los Objects que son los valores de los Predicates deben soportar typed literals. Los datatypes a soportar son: XMLLiteral. Define contenido XML como valor del literal. XMLSchema datatypes: o Boolean. o Date. o Double. o Float o Long. o Int. Además como Object de la aserción tambien se puede ingresar un blank node. Sobre este blank node se pueden realizar futuras aserciones, como lo define el modelo. Esta lista puede ser modificada posteriormente. (Revisar soporte de JENA) El usuario podrá también ingresar un Resource de tipo Container. Los tipos de Container son: BAG para una colección no ordenada. ALT para una colección no ordenada que representa alternativas. SEQ para una colección de objetos ordenada. A un Resource de tipo Container entonces se le pueden agregar Resources y luego recuperarlos, remover elementos y consultar sobre sus nodos y su tamaño. Se podrá utilizar el vocabulario de RDF junto con los definidos por RDFSchema y OWL. //**Revisar bien la funcionalidad que se va a realizar con RDFSchema y OWL Para la utilización de modelos de ontologías, es decir, el uso de RDFSchema o de OWL se debe tomar en cuenta las posibilidades que estos brindan para ofrecer al usuario. Es decir que si el usuario escoge crear una ontologia utilizando RDFSchema, solo deben estar disponibles cosas como subclase, sub-properties, domain y range. Pero si en lugar de este se escogiera OWL, herramientas como disjointness deben estar disponibles. ( buscar reasoner capabilities en inference documentation ). Cuando se use OWL, se debe tambien indicar si se desean importar documentos dentro de la ontologia ya que este lenguaje lo permite. Tambien se puede indicar que se cree un modelo sin tomar en cuenta los imports de este. Tambien se puede ser más selecto indicando que URIS no se quieren cargar. Al ingresar Resource (OntResource), se pueden especificar información sobre la version del recurso, algun comentario, una marca (label), etc. (Mayor información en Jena Ontology API, The generic ontology type). Se pueden eliminar resources completamente de una ontologia, lo que implica que se retira de todos los statements donde aparezca como subject o object. Al ingresar nodos de tipo properties utilizando un lenguaje como OWL se pueden especificar propiedades como funcionales, transitivas, simetricas, inversamente funcional.**/ Guardado y Recuperación de Modelos La aplicación permitirá guardar los modelos creados por el usuario en un archivo con el formato RDF/XML (REVISAR LO DE LOS OTROS LENGUAJES). La aplicación también permitirá recuperar modelos guardados en un archivo con el formato RDF/XML. El usuario debe especificar el archivo que contiene el modelo. La aplicación permitirá trabajar con modelos en XML especificados por un URL. Navegación de modelos La aplicación permitira visualizar todos los Resources que tienen propiedades en el modelo. Sobre cada uno de los Resources, se podrán ver todas las propiedades del mismo especificadas en el modelo. La aplicación permitirá ver todos los statements realizados sobre un modelo predeterminado. Estos se podrán ver en notación RDF/XML y N-Triples. ( Notación gráfica pendiente). Búsqueda en modelos La aplicación permitirá al usuario realizar búsqueda con cualquier combinación en los campos de un Statement. Por ejemplo, si el usuario especifica únicamente el Subject de un Statement, encontrara todos los Statements que contengan el Subject que específico el usuario. Si además especificara el Predicate del Statement, como resultado de la consulta obtendrá todos los Statements que contengan como Subject y Predicate los valores especificados por el usuario. Por ejemplo: Si los siguientes Statements han sido introducidos: http://algo/GabrielLozano http://www.w3.org/2001/vcard-rdf/3.0#N “Gabriel” http://algo/GabrielLozano http://www.w3.org/2001/vcard-rdf/3.0#FN “Gabriel Lozano” Entonces, si se realiza la búsqueda por los Staments con “http://algo/GabrielLozano” como Subject y http://www.w3.org/2001/vcard-rdf/3.0#N como Predicate, se obtendrá como resultado el primer Statement de los introducidos. Además, la aplicación permitirá hacer búsquedas anidadas. Por ejemplo, supongamos que tenemos los siguientes Statements (no validos, pero simplificados para mejorar su visualización): X Y A B X Y A B X Y FN FN FN FN G G G G F F Gabriel Lozano Rene Bareño. Leonardo Lozano. Marcela Lozano. Gabriel Rene Leonardo Marcela Lozano Bareño A B F F Lozano Lozano Con X, Y, A y B como URI de los Subjects, FN, G y F ( Full Name, Given y Family) URI de los Predicates y lo demás como los valores literales de los Predicates. Ahora, supongamos que queremos saber los nombres de las personas que pertenezcan a la Familia Lozano. Para esto necesitaremos una búsqueda anidada. Primero debemos seleccionar las personas de la Familia Lozano. Una consulta de estas se puede ver de la siguiente forma: ?x FN Lozano Con esto obtenemos todas los URI de las personas que pertenecen a la familia Lozano. Ahora, sobre estos obtenemos sus nombres. Esta consulta se puede ver de la siguiente forma: ?x G ?y De esta forma obtendríamos los nombres de todas las personas que pertenezcan a la familia Lozano. Toda la consulta se puede ver de la siguiente forma: ?x FN Lozano && ?x G ?y Además, las búsquedas se pueden filtrar sobre los valores de las propiedades encontradas. Por ejemplo, si se desea buscar Personas que tengan una edad mayor a 24 años la consulta se puede ver de la siguiente forma: ?x edad ?y && ?y >= 24 Además, se pueden filtrar los resultados utilizando expresiones regulares. (PENDIENTE REVISAR ESTE PUNTO Y DEJAR CLARO QUE TIPOS DE FILTRADO SE PUEDEN LLEVAR A CABO. ) Grafos representantes de modelos Seria bueno poder representar en grafos el RDF, y ver su representación al menos en XML. Para los grafos los URIRefs se representan como óvalos y los literales como cuadrados. En los grafos se deben representar los blank nodes. Los grafos se pueden mostrar con relaciones directas o no directas de acuerdo a las jerarquias especificadas con lenguajes como RDFSchema u OWL. (ver Jena Ontology API the generis ontology type: OntResource) Representación de sentencias usando tripletas El programa debe permitir la representación de las sentencias de RDF utilizando el formato de tripletas, en donde cada sentencia es representada por sujeto, predicado y objeto, en ese orden. Cada tripleta corresponde a un arco en la representación con grafos. La representación de una tripleta requiere que cada URIRef sea descrita completamente encerrada en < y >.Se debe revisar si se implementa la notación abreviada que sustituye un XML qualified name (QName) sin < > como una abreviatura para una URIRef completa[1]. Se deben poder usar prefijos para QNames conocidos[2]. Representación de modelos en RDF/XML El programa debe poder crear modelos RDF y verlos representados según la sintaxis RDF/XML. Tomar en cuenta el uso de XML Entibies como mecanismo de abreviación. En la sintaxis de RDF/XML se deben tomar en cuenta el uso de containers como baq, seq y alt. Creación de shortcuts ( PENDIENTE ) La herramienta permite al usuario crear shortcuts para namespaces comunes, que se puedan utilizar en todas las tareas de la herramienta, serian como un tipo de constantes. Creación y edición de vocabularios (modelos con rdfschema y owl) La aplicación debe permitir la creación de vocabularios. A su vez, debe permitir la edición de estos y la navegación para su posterior uso. Se debe permitir importar y exportar estos vocabularios. Normalmente un namespace común es definido para un conjunto de términos que constituyen un vocabulario. Se puede pensar en crear una pagina Web con la URL de la URIRef del vocabulario definido para describir este vocabulario. Descripción de clases con RDFSchema La aplicación debe permitir la descripción de clases de objetos con XMLSchema. Utilización de otros recursos de RDF La aplicación debe permitir el uso de containers, del tipo bag, seq y alt. Tambien el uso de listas que permitan describir un conjunto finito de ítems en un grupo, a diferencia de los containers. El uso de RDF reification también debe ser permitido, el cual describe los propios statements. Entonces si uno realiza statements y se desea una funcionalidad adicional como la de dar información de los statements, sería apropiado que cuando se generan statements el usuario este plenamente identificado. Tambien se puede salvar la fecha en que el statement fue realizado. La aplicación puede tener un mecanismo para asociar URI´s a statements unicos de tal forma que pueda hacer aserciones sobre estos. Creación de vocabularios La aplicación debe por medio del uso de RDFSChema poder especificar vocabularios con las siguientes características: 1. Especificación de clases. 2. Especificación de jerarquías. 3. Descripción de propiedades. Esto a su vez consta de: a. Descripción del rango de una propiedad. b. Descripción del dominio de una propiedad. c. Especificación de jerarquías de propiedades. 4. fdfd Creación de plantillas También deben existir plantillas con modelos predeterminados que permitan llevar a cabo fácilmente esta tarea. Entre estas están: Creación de información sobre páginas Web (Se puede usar el vocabulario DC). Creación de noticias utilizando RSS. Ayuda de Procesos Edición de modelos Undo/redo, copy/paste, etc.. Formato extendido Caso de Uso: 1 Crear un Modelo. -------------------------------------------------INFORMACION DE CARACTERISTICAS Objetivo en el contexto: el usuario desea crear un nuevo modelo u ontología. Alcance: aplicación Nivel: tarea primaria. Precondiciones: si se esta editando un modelo, y no se han guardado los cambios estos deben ser guardados. No se debe estar editando ningún otro modelo, de ser así, este se debe cerrar. Condición Final de Éxito: la aplicación carga en memoria un nuevo modelo para trabajar con un nombre transitorio. La Aplicación indica el repositorio sobre el cual se esta trabajando. Condición Final de Fallo: el sistema no creo un nuevo modelo en memoria, el usuario no puede trabajar sobre un nuevo modelo. Actor Primario: usuario de la aplicación. Disparador: llega una nueva solicitud para crear un nuevo modelo o al inicio de la aplicación. ---------------------------------------ESCENARIO PRINCIPAL DE SUCESO 1. El Usuario indica a la aplicación su deseo de crear un nuevo modelo. 2. La Aplicación verifica que si se esta trabajando en algún modelo, este modelo esté guardado. 3. La Aplicación crea un nuevo modelo y le da un nombre transitorio para identificarlo. 4. El Usuario puede comenzar a editarlo. ---------------------EXTENSIONES 1a. O se da inicio a la aplicación. Se pasa directamente al paso 3. 3a . El modelo sobre el que se esta trabajando ha sido modificado y no ha sido guardado. 3a 1. El Sistema pregunta al Usuario si desea guardar el modelo. 3a 2. Si el Usuario responde que si, el Sistema guarda el modelo (caso de uso 2) y continua con la creación de un nuevo modelo. Si el Usuario cancela la operación de guardar el modelo, el caso de uso de crear un nuevo modelo termina. --------------------------CALENDARIO Fecha de Realización: Primera iteración fase de elaboración. (Fecha estimada de terminación, Agosto 25) Caso de Uso: 2 Guardar un modelo. -------------------------------------------------INFORMACION DE CARACTERISTICAS Objetivo en el contexto: el Usuario desea guardar un modelo sobre el cual esta trabajando. Alcance: aplicación. Nivel: tarea primaria. Precondiciones: un modelo ha sido creado y no ha sido guardado o sus cambios no han sido guardados. Condición Final de Éxito: el modelo ha sido guardado en donde el usuario deseaba. Posteriormente los cambios en el modelo se guardaran en este archivo. La Aplicación indica el repositorio sobre el cual se está trabajando. Condición Final de Fallo: el modelo no ha sido guardado donde el usuario deseaba. Actor Primario: usuario de la aplicación. Disparador: llega una solicitud por parte del usuario para guardar el modelo o se va a cerrar la aplicación y no se han guardado cambios en el modelo o se va o se va a crear un nuevo modelo o se va a cargar un nuevo modelo. ---------------------------------------ESCENARIO PRINCIPAL DE SUCESO 1. La Aplicación guarda el modelo en el repositorio que tiene configurado. 2. El Usuario continúa trabajando en la edición del modelo. ---------------------EXTENSIONES 1 a. El modelo no ha sido guardado por primera vez. 1. La Aplicación pregunta por la localización y el formato del repositorio a donde se va a guardar el modelo. 2. La Aplicación valida que no exista un repositorio con los mismos datos ingresados por el usuario. De ser así, debe consultar al usuario si desea sobrescribir el repositorio o cambiar los datos. Si lo sobrescribe, guarda el modelo con los datos inicialmente ingresados por el usuario. Si desea cambiar los datos, se activa el caso de uso 3: Guardar un modelo en un repositorio diferente. -------------------REQUERIMIENTOS ESPECIALES 1 a. El formato en el que el modelo puede ser escrito: RDF/XML (por omisión), N-3 y N-triples. ---------------------OPEN ISSUES El usuario debe especificar el formato al abrir el modelo o la aplicación debe intentar con todos los disponibles? --------------------------CALENDARIO Fecha de Realización: Primera iteración fase de elaboración. (Fecha estimada de terminación, Agosto 25) Caso de Uso: 3 Guardar un modelo en un repositorio diferente. -------------------------------------------------INFORMACION DE CARACTERISTICAS Objetivo en el contexto: el Usuario desea guardar un modelo sobre el cual esta trabajando con distintos parámetros, como ubicación, formato, nombre o cualquier combinación de estos. Alcance: aplicación. Nivel: tarea primaria. Precondiciones: un modelo ha sido creado, se esta trabajando sobre el y ha sido previamente guardado. Condición Final de Éxito: el modelo ha sido guardado como el Usuario deseaba. Posteriormente los cambios en el modelo se guardaran en este repositorio. La Aplicación indica el repositorio sobre el cual se esta trabajando. Condición Final de Fallo: el modelo no ha sido guardado como el Usuario deseaba. La aplicación continúa trabajando sobre el repositorio inicial. Actor Primario: Usuario de la aplicación. Disparador: llega una solicitud por parte del usuario para guardar el modelo en una ubicación, formato o nombre diferente. ---------------------------------------ESCENARIO PRINCIPAL DE SUCESO 1. El Usuario hace saber a la aplicación su deseo de guardar el modelo en el que viene trabajando con distintos parámetros a los que se esta actualmente guardando el modelo como su ubicación, formato, nombre o cualquier combinación de estos. 2. La Aplicación pide al usuario los nuevos parámetros con los que debe guardar el modelo. 3. El Usuario ingresa los parámetros que indican como quiere guardar el modelo. 4. La Aplicación valida los datos. La Aplicación guarda el modelo según lo desea el Usuario. Los siguientes cambios en el modelo serán almacenados en el nuevo repositorio configurado. ---------------------EXTENSIONES 3 a. El Usuario cancela la operación. El Caso de Uso termina. 4 a. Los valores para almacenar el modelo corresponden a un repositorio ya existente. 1. La Aplicación consulta al Usuario sobre la siguiente acción. El Usuario puede sobrescribir el repositorio o escoger nuevos datos. Si escoge sobrescribir, se guarda el modelo con los parámetros ingresados por el Usuario. De no ser así, se vuelve al paso 2. -------------------REQUERIMIENTOS ESPECIALES ---------------------OPEN ISSUES Que se debe validar de los datos ingresados por el usuario?. Por ejemplo, longitud o caracteres del nombre del archivo? Como se consideran 2 repositorios iguales? Son iguales aunque tengan un formato diferente? --------------------------CALENDARIO Fecha de Realización: Primera iteración fase de elaboración. (Fecha estimada de terminación, Agosto 25) Caso de Uso: 4 Cargar un Modelo. -------------------------------------------------INFORMACION DE CARACTERISTICAS Objetivo en el Contexto: El Usuario desea utilizar un modelo sobre el cual anteriormente estuvo trabajando y guardo en un repositorio. Alcance: aplicación. Nivel: tarea principal Precondiciones: ninguna. Condición Final de Éxito: el modelo ha sido cargado y los eventuales cambios serán guardados en el repositorio asociado a este. La Aplicación indica el repositorio sobre el cual se esta trabajando. Condición Final de Fallo: el modelo no pudo ser cargado. Actor Primario: Usuario de la aplicación. Disparador: el Usuario indica su deseo de cargar un modelo. ---------------------------------------FLUJO BASICO DE EVENTOS 1. El Usuario indica su deseo de cargar un modelo. 2. La aplicación pide los datos al Usuario sobre el repositorio donde se encuentra el modelo. 3. El Usuario ingresa los valores del repositorio asociado con el modelo que el Usuario desea cargar. 4. La Aplicación carga el modelo y permite seguir trabajando sobre el, guardando los cambios en el repositorio asociado. ---------------------EXTENSIONES 3 a. El Usuario cancela la operación. El Caso de Uso debe finalizar. ---------------------------OPEN ISSUES (opcional) Como abre el archivo, sin saber en que formato este? Debe revisar todos y obtener el formato o el usuario debe ingresar una opción con el formato asociado al archivo? O se debe guardar solo en un formato determinado? --------------------------CALENDARIO Fecha de Realización: Primera iteración fase de elaboración. (Fecha estimada de terminación, Agosto 25) Caso de Uso: 5 Ingresar Statements -------------------------------------------------INFORMACION DE CARACTERISTICAS Objetivo en el Contexto: El Usuario desea ingresar Statements en el modelo que va a crear. Alcance: aplicación. Nivel: tarea primaria. Precondiciones: un modelo debe estar listo para recibir Statements. Condición Final de Éxito: El Statement es agregado al modelo sobre el cual se esta trabajando. Condición Final de Fallo: el Statement no pudo ser agregado al modelo sobre el cual se esta trabajando. Actor Primario: el Usuario de la aplicación. Disparador: El Usuario hace saber a la aplicación su deseo de ingresar un Statement sobre el modelo que esta trabajando. ---------------------------------------FLUJO BASICO DE EVENTOS 1. El Usuario ingresa el URI del Subject que lo identifica. 2. El Usuario ingresa el Predicate del Statement, ingresando el URI que lo identifica o escogiendo uno de los predeterminados. 3. El Usuario ingresa el valor del Object del Statement, el cual puede ser un Literal o puede ser otro Resource. Si es otro Resource, el usuario debe indicar el URI que lo identifica, si este no es un Blank Node. 4. La Aplicación recibe el Statement y lo ingresa en el modelo. ---------------------EXTENSIONES 2 a. El usuario desea un predeterminado. 1. La aplicación le enseña al usuario una lista de las Properties que puede utilizar en el Statement. 2. El usuario selecciona un valor de la lista. 3 a. El usuario ingresa un Literal y desea configurarlo con un tipo. El usuario selecciona uno de los tipos que la aplicación proporciona, como XMLLiteral, Bolean, Date, Double, etc… ---------------------OPEN ISSUES (optional) Que valores predeterminados de las Properties puede escoger el usuario y como se indexaran? Si el valor de un Object es un Blank Node, como se debe manejar? Que typed lyterals tendrá la herramienta? Se deben validar estos typed lyterals? --------------------------CALENDARIO Fecha de Realizacion: segunda iteracion fase de elaboración. (Fecha estimada: Sept 5 ). Referencias