Modelo de Casos de Uso

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