Traducciones:Esta traducción se concluyó, el 3 de enero de 2001.
Los posibles errores presentes en este documento, debidos a la traducción, son de la responsabilidad del traductor y no son achacables en modo alguno al W3C. Para cualquier comentario sobre la traducción dirigirse a Eva Méndez, Miembro del G2 del SIDAR.
La única versión normativa oficial de este documento es la versión original (en inglés):
http://www.w3.org/TR/REC-rdf-syntax/
REC-rdf-syntax-19990222-es
Copyright
© 1997,1998,1999 W3C (MIT, INRIA, Keio
), Todos los derechos reservados. W3C reponsabilidad
legal, marca
registrada, uso del
documento y aplicación de las reglas de licencia de
software.
| Copyright © de la traducción: 2000, Eva Méndez
Se ha tratado de respetar al máximo el contenido de la especificación original en inglés, adaptando la expresión al español e introduciendo entre [corchetes] algunas palabras (bien en español o en inglés) que ayuden a una mejor comprensión de esta especificación a investigadores e interesados en XML/RDF del dominio lingüístico español. No obstante, puden haberse cometido errores fruto de la traducción; por ello, ha de tenerse en cuenta que la única especificación válida es la que está en inglés en la dirección original del W3C: http://www.w3.org/TR/REC-rdf-syntax/ |
Los miembros del Consorcio WWW (W3C) y otras partes interesadas han revisado este documento y el director lo ha aprobado como Recomendación W3C. Es un documento estable que se utilizará como material de referencia o se citará como referencia normativa en otros documentos. El papel del W3C al elaborar la Recomendación es llamar la atención sobre la especificación y promover un desarrollo generalizado de la misma. Esto enriquece la operatividad e interoperabilidad del Web.
Se puede acceder a la lista de errores conocidos en esta especificación [en inglés]: http://www.w3.org/TR/1999/REC-rdf-syntax-19990222/errata.
Se pueden enviar comentarios a la especificación a <www-rdf-comments@w3.org>. El archivo de comentarios públicos se puede consultar en: http://www.w3.org/Archives/Public/www-rdf-comments.
En un principio la World Wide Web se construyó para el uso humano, y a pesar de que todo en ella era legible por máquina estos datos todavía no son legibles por ésta última. Es muy difícil automatizar cualquier cosa en la Web, debido al volumen de información que contiene, no es posible gestionarla manualmente. La solución que se propone aquí es el uso de metadatos para describir los datos contenidos en la Web. Los metadatos son "datos sobre los datos" (por ejemplo, un catálogo de biblioteca es [un registro] de metadatos, en el sentido de que describen publicaciones) o concretamente en el contexto de esta especificación "datos que describen recursos Web". La distinción entre "datos" y "metadatos" no es incuestionable; es una diferencia creada en primera instancia por una aplicación particular, y muchas veces el mismo recurso se interpretará de ambas formas [como dato y como metadato] simultáneamente.
Resource Description Framework (RDF) [Infraestructura para la Descripción de Recursos] es una base para procesar metadatos; proporciona interoperabilidad entre aplicaciones que intercambian información legible por máquina en la Web. RDF destaca por la facilidad para habilitar el procesamiento automatizado de los recursos Web. RDF puede utilizarse en distintas áreas de aplicación; por ejemplo: en recuperación de recursos para proporcionar mejores prestaciones a los motores de búsqueda, en catalogación para describir el contenido y las relaciones de contenido disponibles en un sitio Web, una página Web, o una biblioteca digital particular, por los agentes de software inteligentes para facilitar el intercambio y para compartir conocimiento; en la calificación de contenido, en la descripción de colecciones de páginas que representan un "documento" lógico individual, para describir los derechos de propiedad intelectual de las páginas web, y para expresar las preferencias de privacidad de un usuario, así como las políticas de privacidad de un sitio Web. RDF junto con las firmas digitales será la clave para construir el "Web de confianza" para el comercio electrónico, la cooperación y otras aplicaciones.
Este documento introduce un modelo para representar metadatos en RDF así como una sintaxis para codificar y transmitir estos metadatos de tal forma que maximicen la interoperabilidad de servidores y clientes web desarrollados independientemente. La sintaxis presentada aquí utiliza el Extensible Markup Language [Lenguaje de Marcado Extensible] (XML): uno de los objetivos de RDF es hacer posible especificar la semántica para las bases de datos en XML de una forma normalizada e interoperable. RDF y XML son complementarios: RDF es un modelo de metadatos y sólo dirige por referencia muchos de los aspectos de codificación que requiere el almacenamiento y transferencia de archivos (tales como internacionalización, conjuntos de caracteres, etc.). Para estos aspectos, RDF cuenta con el soporte de XML. Es importante también entender que esta sintaxis XML es sólo una sintaxis posible para RDF y que pueden surgir formas alternativas para representar el mismo modelo de datos RDF.
El objetivo general de RDF es definir un mecanismo para describir recursos que no cree ninguna asunción sobre un dominio de aplicación particular, ni defina (a priori) la semántica de algún dominio de aplicación. La definición del mecanismo debe ser neutral con respecto al dominio, sin embargo el mecanismo debe ser adecuado para describir información sobre cualquier dominio.
Esta especificación continuará con otros documentos que completarán el marco. Sobre todo, para facilitar la definición de metadatos, RDF contará con un sistema de clasificación muy parecido a los sistemas de programación y modelado orientado a objetos. Una colección de categorías (producida normalmente para un propósito o dominio específico) denominada schema. Las categorías se organizan en una jerarquía, y proporcionan extensibilidad a través de un refinamiento de subcategorías. Así, para crear un esquema ligeramente diferente de uno existente no es necesario "reinventar la rueda" pero se pueden facilitar modificaciones incrementales al esquema base. A través de la compartición del esquema RDF soportará la reutilización de definiciones de metadatos. Gracias a la extensibilidad incremental de RDF, los agentes que procesen metadatos serán capaces de trazar los orígenes del esquema que no conocen con respaldo para conocer el esquema y realizar acciones significativas en los metadatos que no han sido diseñados inicialmente para procesar. La capacidad de compartir y la extensibilidad de RDF permiten a los creadores de metadatos usar múltiples cambios de la categoría de objetos para "mezclar" definiciones, para proporcionar múltiples presentaciones a sus datos, haciendo uso del trabajo de otros. En síntesis, es posible crear objetos específicos de datos basados en diversos esquemas de distintas fuentes (p. ej. "intercalando" diferentes tipos de metadatos). Los esquemas pueden escribirse en RDF; un documento que acompaña a esta especificación [RDFSchema], describe un conjunto de propiedades y clases para describir esquemas RDF.
Como resultado de la reunión de distintas comunidades que están de acuerdo en los principios básicos de la representación y transposición de metadatos, RDF está influido de varias fuentes diferentes. Las principales influencias provienen de la propia Comunidad de Normalización de la Web en forma de metadatos HTML y PICS, la comunidad bibliotecaria, la comunidad de los documentos estructurados en forma de SGML y sobre todo XML, y también de la comunidad de representación del conocimiento (KR). También han contribuido al diseño de RDF otras áreas de la tecnología; incluidos los lenguajes de modelado y programación orientada a objetos, así como las bases de datos. Mientras RDF surge de la comunidad KR [de la representación del conocimiento], la bibliografía relacionada con este campo, advierte que RDF no especifica un mecanismo para el razonamiento. RDF puede definirse como un sistema simple. Un mecanismo de razonamiento debe construirse sobre este sistema de referencia.
El fundamento o base de RDF es un modelo para representar propiedades designadas y valores de propiedades. El modelo RDF se basa en principios perfectamente establecidos de varias comunidades de representación de datos. La propiedades RDF pueden recordar a atributos de recursos y en este sentido corresponden con los tradicionales pares de atributo-valor. Las propiedades RDF representan también la relación entre recursos y por lo tanto, un modelo RDF puede parecer un diagrama entidad-relación. (De forma más precisa, los esquemas RDF —que son objetos específicos de la categoría del modelo de datos RDF — son diagramas ER [Entidad Relación]. En la terminología del diseño orientado a objetos, los recursos corresponden con objetos y las propiedades corresponden con objetos específicos y variables de una categoría.
El modelo de datos de RDF es una forma de sintaxis-neutral para representar expresiones RDF. La representación del modelo de datos se usa para evaluar la equivalencia en significado. Dos expresiones RDF son equivalentes y y sólo si sus representaciones del modelo de datos son las mismas. Esta definición de equivalencia permite algunas variaciones sintácticas en expresiones sin alterar el significado. (Ver Sección 6 para discusión adicional del tema de comparación strings [series de caracteres entendidas como grupos].
El modelo de datos básico consiste en tres tipos de objetos:
| Recursos |
Todas las cosas descritas por expresiones RDF se denominan recursos. Un recursos puede ser una página Web completa; tal como el documento HTML "http://www.w3.org/Overview.html" por ejemplo. Un recurso puede ser una parte de una página Web; p. ej. un elemento HTML o XML específico dentro del documento fuente. Un recurso puede ser también una colección completa de páginas; p. ej. un sitio Web completo. Un recurso puede ser también un objeto que no sea directamente accesible vía Web, p. ej. un libro impreso. Los recursos se designan siempre por URIs más identificadores de anclas opcionales (ver [URI]). Cualquier cosa puede tener un URI; la extensibilidad de URIs permite la introducción de identificadores para cualquier entidad imaginable. |
| Propiedades |
Una propiedad es un aspecto específico, característica, atributo, o relación utilizado para describir un recurso. Cada propiedad tiene un significado específico, define sus valores permitidos, los tipos de recursos que puede describir, y sus relaciones con otras propiedades. Este documento no dirige cómo se expresan las características de las propiedades; para tal información, dirigirse a la especificación del esquema RDF [RDF Schema specification]. |
| Sentencias
[declaraciones, enunciados] |
Un recurso específico junto con una propiedad denominada, más el valor de dicha propiedad para ese recurso es una sentencia RDF [RDF statement]. Estas tres partes individuales de una sentencia se denominan, respectivamente, sujeto, predicado y objeto. El objeto de una sentencia (es decir, el valor de la propiedad) puede ser otro recurso o pude ser un literal; es decir, un recurso (especificado por un URI) o una cadena simple de caracteres [string] u otros tipos de datos primitivos definidos por XML. En términos RDF, un literal puede comprender en su contenido marcado XML pero ya no puede valorarse más por un procesador RDF. Existen varias restricciones sintácticas en cómo se puede expresar el marcado en literales.; ver Sección 2.2.1. |
Los recursos se identifican por un identificador de recursos. Un identificador de recursos es un URI más un identificador opcional de ancla (ver sección 2.2.1.). Para el propósito de esta sección, las propiedades se referirán a través de un nombre simple.
Considerar como ejemplo simple la sentencia:
Ora Lassila es el creador [autor] del recurso http://www.w3.org/Home/Lassila.Esta sentencia comprende las siguientes partes:
Sujeto (Recurso) http://www.w3.org/Home/Lassila Predicado (Propiedad) Creator Objeto (literal) "Ora Lassila"
En este documento podríamos representar gráficamente una sentencia RDF usando gráficos etiquetados (también denominados "diagramas de nodos y arcos"). En estos gráficos, los nodos (dibujados como óvalos) representan recursos y los arcos representan propiedades denominadas. Los nodos que representan cadenas de literales pueden dibujarse como rectángulos. La sentencia citada anteriormente se representaría gráficamente como:
DNota: La dirección de la flecha es importante. El arco siempre empieza en el sujeto y apunta hacia el objeto de la sentencia. Este diagrama simple puede también interpretarse o leerse "http://www.w3.org/Home/Lassila tiene como creador a Ora Lassila", o en general "<sujeto> TIENE <predicado> <objeto>".
Ahora, imaginemos que queremos decir algo más sobre las características del creador de este recurso. Tal declaración en lenguaje natural podría ser:
El individuo cuyo nombre es Ora Lassila, correo electrónico <lassila@w3.org>, es el creador de http://www.w3.org/Home/Lassila.
La intención de esta frase es precisar el valor de la propiedad Creator [Creador] una entidad estructurada. En RDF tal entidad se representa como otro recurso. La sentencia anterior no proporciona un nombre a ese recurso; es anónimo, por ello el gráfico a continuación lo representa como un óvalo vacío:
DNota: correspondiendo con la lectura de la nota anterior, este diagrama puede leerse: "http://www.w3.org/Home/Lassila tiene el creador cualquiera y este cualquiera tiene el nombre Ora Lassila y el correo electrónico lassila@w3.org".
A la entidad estructurada del ejemplo anterior se le puede asignar un único identificador. El diseñador de la aplicación de la base de datos hace la elección del identificador. Continuando con el ejemplo, imagine que un identificador empleado se utiliza como único identificador para un recurso "persona". Los URIs que sirven como única clave para cada empleado (definido por la organización) podría ser entonces algo como: http://www.w3.org/staffId/85740. Ahora podemos escribir dos frases o sentencias:
El modelo RDF para estas frases o sentencias es:El individuo al que se refiere el identificador de empleado id 85740 se llama Ora Lassila y tiene la dirección de correo lassila@w3.org. Ese individuo creó el recurso http://www.w3.org/Home/Lassila
D
Obsérvese que este gráfico es idéntico al anterior con la adición del URI para el recurso que antes era anónimo. Desde el punto de vista de una segunda aplicación que interrogue este modelo, no hay distinción entre la sentencia hecha de forma individual y la sentencia realizada por partes. Sin embargo, algunas aplicaciones necesitarán hacer esta distinción y RDF lo soporta; para más detalles ver Sección 4, Declaraciones sobre Declaraciones.
El modelo de datos RDF proporciona un marco abstracto y conceptual para definir y utilizar metadatos. Necesita también una sintaxis concreta para crear e intercambiar metadatos. Esta especificación de RDF utiliza el [Lenguaje de Marcado eXtensible] Extensible Markup Language [XML] codificado como su sintaxis de intercambio. RDF necesita también la [facilidad de los namespaces XML] XML namespace facility para asociar con precisión cada propiedad con el esquema que define dicha propiedad; ver Sección 2.2.3., Esquemas y Namespaces.
Las descripciones sintácticas en este documento usan la forma de notación Extended Backus-Naur Form [EBNF] como se define en la Sección 6, Notación, de [XML] para describir los elementos sintácticos esenciales en RDF. La EBNF aquí se abrevia [o concentra] para la legibilidad humana, en particular la cursiva "rdf" se usa para representar un prefijo de namespace variable más que la notación BNF más precisa "'<' NSprefix ':...'". La condición es que la propiedad y el tipo de nombres en las etiquetas finales coincidan con los nombres en las etiquetas iniciales correspondientes implicadas en las reglas de XML. Todas la flexibilidades sintácticas de XML están incluidas implícitamente, p. ej. las reglas de espacio en blanco, citar usando tanto comillas simple (') como comillas dobles ("), character escaping, case sensibility, y marcado del lenguaje [language tagging].
Esta especificación define dos sintaxis XML para codificar una instancia [objeto específico de una categoría] de modelo de datos. La sintaxis serializada expresa las capacidades totales del modelo de datos de una forma muy regular. La sintaxis abreviada incluye términos adicionales que proporcionan una forma más compacta para representar un subconjunto del modelo de datos. Los intérpretes de RDF se han anticipado a implementar ambas sintaxis, la serializada completa y la abreviada. Así, los autores [creadores] de metadatos pueden mezclar ambas libremente.
Una sentencia [declaración] RDF rara vez aparece sola; normalmente se darán juntas varias propiedades de un recurso. La sintaxis RDF XML se ha diseñado para dar cabida a esto agrupando múltiples sentencias para el mismo recursos en un elemento Description. El elemento Description denomina, en un atributo about, el recurso para el cual se aplica cada una de las sentencias [o declaraciones]. Si el recurso no existe todavía (es decir, no tiene todavía un identificador de recursos) el elemento Description puede proporcionar el identificador para el recurso usando el atributoID.
La sintaxis serializada RDF básica toma la forma:
[1] RDF ::= ['<rdf:RDF>'] description* ['</rdf:RDF>'] [2] description ::= '<rdf:Description' idAboutAttr? '>' propertyElt* '</rdf:Description>' [3] idAboutAttr ::= idAttr | aboutAttr [4] aboutAttr ::= 'about="' URI-reference '"' [5] idAttr ::= 'ID="' IDsymbol '"' [6] propertyElt ::= '<' propName '>' value '</' propName '>' | '<' propName resourceAttr '/>' [7] propName ::= Qname [8] value ::= description | string [9] resourceAttr ::= 'resource="' URI-reference '"' [10] Qname ::= [ NSprefix ':' ] name [11] URI-reference ::= string, interpreted per [URI] [12] IDsymbol ::= (any legal XML name symbol) [13] name ::= (any legal XML name symbol) [14] NSprefix ::= (any legal XML namespace prefix) [15] string ::= (any XML text, with "<", ">", and "&" escaped)
El elemento RDF es un simple envoltorio que marca los límites en un documento XML entre los que el contenido está dispuesto a ser mapeado a una instancia de modelo de datos RDF. El elemento RDF es opcional si el contenido puede entenderse como RDF desde el contexto de la aplicación.
El elemento Description contiene los elementos sobrantes que posibilitan la creación de sentencias en la instancia [objeto específico de la categoría] del modelo. El elemento Description puede evocarse (con la finalidad de sintaxis RDF básica) simplemente como un lugar donde mantener la identificación de un recuso descrito. Normalmente habrá más de una sentencia [o declaración] sobre un recursos; el elemento Description proporciona una forma de dar el nombre justo de una vez a varias sentencias.
Cuando se especifica el atributo about con Description, la sentencia [declaración] en el elemento Description se refiere al recurso cuyo identificador determina el elemento about. El valor del atributo about se interpreta como una referencia-URI por Sección 4 del [URI]. El identificador de recursos correspondiente se obtiene resolviendo la referencia-URI a la forma absoluta como se especifica mediante [URI]. Si se incluye un fragmento del identificador en la referencia-URI, el identificador de recursos se refiere sólo al subcomponente del recurso que lo contiene, recurso que se identificará a través del correspondiente fragmento ID interno a dicho recurso que lo contiene (ver ancla en [Dexter94]), por otra parte el identificador se refiere al recurso completo especificado por el URI. Un elemento Description sin un atributo about representa un nuevo recurso. Tal recurso podría ser un substituto, o delegado [proxy], para algunos recursos físicos que no tienen un URI reconocible. El valor del atributo ID del elemento Description, en el caso de que se presente, es el ancla id de ese recurso"in-line".
Si otro elemento Description o valor de propiedad necesita referirse a el recurso in-line utilizará el valor del ID de dicho recurso en su propio atributo about. El atributo ID indica la creación de un nuevo recurso y el atributo about se refiere a un recurso existente; por ello tanto el atributo ID como about pueden especificarse en el elemento Description pero no los dos juntos en el mismo elemento. Los valores para cada atributo ID no deben aparecer en más de un atributo ID dentro del mismo documento.
Un único elemento Description puede contener más de un elemento propertyElt con el mismo nombre de propiedad. Cada uno de dichos propertyElt añaden un arco al gráfico. La interpretación de esta representación gráfica se definirá por el diseñador del esquema.
Dentro del elemento propertyElt, el atributo resource especifica que otros recursos son el valor de esta propiedad; es decir, el objeto de la sentencia [o declaración] es otro recurso identificado identificado por un URI preferentemente a la indicación por un literal. El identificador del recurso del objeto se obtiene resolviendo el URI-de referencia del atributo resource de la misma forma que se mencionó anteriormente para el atributo about. Los Strings deben ser XML bien formados; el XML convencional contiene mecanismos de citación y disgregación que pueden usarse si la serie de caracteres [string] contiene secuencias de caracteres (ej. "<" and "&") que transgreden las reglas de buena formación o que podría parecer "marcado". Ver Sección 6. para sintaxis adicional que especifique un valor de propiedad con contenido XML bien formado y que conlleve marcado de tal forma que éste no sea interpretado por RDF.
Los nombres de propiedad pueden asociarse con un esquema. Esto puede hacerse cualificando los nombres de los elementos con un prefijo de namespace que asocie con claridad la definición de propiedad con el esquema RDF correspondiente o declarando un namespace por defecto como se expresa en [NAMESPACES].
El ejemplo de la frase de la sección 2.1.1
Ora Lassila es el creador [autor] del recurso http://www.w3.org/Home/Lassila.se representa en RDF/XML:
<rdf:RDF> <rdf:Description about="http://www.w3.org/Home/Lassila"> <s:Creator>Ora Lassila</s:Creator> </rdf:Description> </rdf:RDF>
Aquí el prefijo del namespace 's' se refiere a un prefijo específico elegido por el autor de esta expresión RDF y definido en una declaración XML del namespace como ésta:
xmlns:s="http://description.org/schema/"
Esta declaración del namespace podría incluirse normalmente como un atributo XML en el elemento rdf:RDF pero también puede incluirse con un elemento Description específico o incluso una expresión propertyElt concreta. El URI del nombre del namespace, en la declaración del namespace, es un identificador único universal para un esquema particular que la persona que define los metadatos [este autor de los metadatos] utiliza para definir el uso de la propiedad Creator. Otros esquemas pueden definir igualmente la propiedad denominada Creator y las dos propiedades se diferenciarán gracias a sus identificadores de esquema. Nótese también que un esquema normalmente define también varias propiedades; una única declaración de namespace será suficiente para crear un amplio vocabulario de propiedades que podrán usarse.
El documento XML completo que contiene la descripción citada anteriormente, podría ser:
<?xml version="1.0"?> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:s="http://description.org/schema/"> <rdf:Description about="http://www.w3.org/Home/Lassila"> <s:Creator>Ora Lassila</s:Creator> </rdf:Description> </rdf:RDF>
Utilizando la sintaxis de namespace definida por defecto en [NAMESPACES] para el propio namespace de RDF, este documento podría expresarse también así:
<?xml version="1.0"?> <RDF xmlns="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:s="http://description.org/schema/"> <Description about="http://www.w3.org/Home/Lassila"> <s:Creator>Ora Lassila</s:Creator> </Description> </RDF>
Además, la declaración de namespace puede asociarse con un elemento Description concreto e incluso un elemento propertyElt particular como en este ejemplo:
<?xml version="1.0"?> <RDF xmlns="http://www.w3.org/1999/02/22-rdf-syntax-ns#"> <Description about="http://www.w3.org/Home/Lassila"> <s:Creator xmlns:s="http://description.org/schema/">Ora Lassila</s:Creator> </Description> </RDF>Como las declaraciones de namespace XML pueden anidarse, el ejemplo anterior puede además condersarse así:
<?xml version="1.0"?> <RDF xmlns="http://www.w3.org/1999/02/22-rdf-syntax-ns#"> <Description about="http://www.w3.org/Home/Lassila"> <Creator xmlns="http://description.org/schema/">Ora Lassila</Creator> </Description> </RDF>
Sin embargo, las expresiones demasiado condensadas como ésta deben evitarse cuando la codificación RDF/XML se escribe a mano o se edita en un editor de texto plano. Aunque no son ambiguas, la posibilidad de error es mayor que si se los prefijos explícitos se usan de manera consistente. Nótese que un fragmento RDF/XML que se realiza para insertarse en otro documento debe declarar todos los namespaces que utiliza de tal forma que sea completamente independiente. Para una mejor legibilidad, los ejemplos utilizados en el resto de esta sección omiten la declaración del namespace para no complicar [oscurecer] los aspectos específicos que se ilustran.
Aunque la sintaxis serializada muestra la estructura de un modelo RDF más claro, normalmente es mejor utilizar una forma XML más compacta. Esto se lleva a cabo a través de la sintaxis abraviada de RDF. Como valor añadido, la sintaxis abreviada permite a los documentos seguir DTDs de XML bien estructuradas que se interpretan como modelos RDF.
Se definen tres formas de abreviación para la sintaxis básica serializada. La primera se puede utilizar para propiedades no repetidas dentro de un elemento Description donde los valores de dichar propiedades son literales. En este caso, las propiedades se pueden expresar como atributos XML del elemento Description. El ejemplo anterior se convierte pues en:
<rdf:RDF> <rdf:Description about="http://www.w3.org/Home/Lassila" s:Creator="Ora Lassila" /> </rdf:RDF>
Nótese que desde que el elemento Description no tiene otro contenido desde que la propiedad Creator se escribe en forma de atributo XML, la sintaxis de elemento vación de XML se emplea para omitir la etiqueta final de Description.
Aquí se presenta otro ejemplo del uso de esta misma forma abreviada:
<rdf:RDF> <rdf:Description about="http://www.w3.org"> <s:Publisher>World Wide Web Consortium</s:Publisher> <s:Title>W3C Home Page</s:Title> <s:Date>1998-10-03T02:27</s:Date> </rdf:Description> </rdf:RDF>
<rdf:RDF> <rdf:Description about="http://www.w3.org" s:Publisher="World Wide Web Consortium" s:Title="W3C Home Page" s:Date="1998-10-03T02:27"/> </rdf:RDF>
Nótese que a pesar de que estas dos expresiones RDF son equivalentes, deben tratarse de forma diferente por distintos motores de procesamiento. En particular, si estas dos expresiones estuviesen embebidas en un documento HTML el comportamiento por defecto de un navegador que no reconozca RDF sería presentar los valores de las propiedades en el primer caso y en el segundo caso debería presentarse de forma no textual (o al menos un carácter de espacio en blanco).
La segunda forma abreviada trabaja sobre elementos Description. Esta forma abreviada puede emplearse para sentencias específicas donde el objeto de la declaración es otro recurso y el valor de cualquier propiedad dada "in-line" para este segundo recurso son strings (cadenas de caracteres manipuladas como grupo). En este caso se usa una transformación similar de elementos XML que se nombran como atributos XML: las propiedades del recurso en el elemento Description anidado puede escribirse como atributos XML del elemento propertyElt en el que se comprende Description.
La frase del segundo ejemplo de la Sección 2.1.1
se escribe en RDF/XML utilizando la forma serializada explícita como:El individuo al que se refiere el identificador de empleado id 85740 se llama Ora Lassila y tiene la dirección de correo lassila@w3.org. Ese individuo creó el recurso http://www.w3.org/Home/Lassila
<rdf:RDF> <rdf:Description about="http://www.w3.org/Home/Lassila"> <s:Creator rdf:resource="http://www.w3.org/staffId/85740"/> </rdf:Description> <rdf:Description about="http://www.w3.org/staffId/85740"> <v:Name>Ora Lassila</v:Name> <v:Email>lassila@w3.org</v:Email> </rdf:Description> </rdf:RDF>
De esta forma se evidencia al lector que se están describiendo dos recursos separados pero lo que está menos claro es que el segundo recurso se use en la primera descripción. Esta misma expresión podría escribirse de la forma que se señala a continuación para mostrar esta relación más obvia. Nótese que para la máquina, no habría diferencia:
<rdf:RDF> <rdf:Description about="http://www.w3.org/Home/Lassila"> <s:Creator> <rdf:Description about="http://www.w3.org/staffId/85740"> <v:Name>Ora Lassila</v:Name> <v:Email>lassila@w3.org</v:Email> </rdf:Description> </s:Creator> </rdf:Description> </rdf:RDF>
Utilizando esta segunda sintaxis abreviada, el elemento interior Description y las expresiones de las propiedades que contiene pueden escribirse como atributos del elemento Creatort:
<rdf:RDF> <rdf:Description about="http://www.w3.org/Home/Lassila"> <s:Creator rdf:resource="http://www.w3.org/staffId/85740" v:Name="Ora Lassila" v:Email="lassila@w3.org" /> </rdf:Description> </rdf:RDF>
Cuando usamos esta forma abreviada, el atributo about del elemento anidado Description se convierte en un atributo de resource en el elemento propertyElt, de igual forma que el recurso designado por el URI es en ambos casos el valor de la propiedad Creator. Es simplemente una cuestión de preferencia [de la persona que asigna los metadatos] la elección de una de las tres formas señaladas que se usará en la fuente RDF. Todas producen los mismos modelos RDF internos.
Nota: El lector observador que haya analizado el resto de este documento comprobará que existen algunas relaciones adicionales representadas por el elemento Description para conservar la agrupación sintáctica específica de las sentencias [o declaraciones]. Por lo tanto las tres formas señaladas son ligeramente diferentes aunque sin importancia para la discusión que se plantea en esta sección. Estas diferencias serán importantes sólo cuando se realicen sentencias de alto nivel como se describe en la Sección 4.
La tercera forma de sintaxis abreviada básica se aplica a el caso común de un elemento Description que contenga un propiedad type (para el significado de type, ver Section 4.1). En este caso, el tipo de recurso definido en el esquema que corresponde al valor de la propiedad type puede utilizarse directamente como un nombre de elemento. Por ejemplo, utilizando el fragmento RDF anterior si queremos añadir que el recurso http://www.w3.org/staffId/85740 representa una instancia [objeto específico de la categoría] de una persona, podríamos escribirlo en una sintaxis serializada completa, así:
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:s="http://description.org/schema/"> <rdf:Description about="http://www.w3.org/Home/Lassila"> <s:Creator> <rdf:Description about="http://www.w3.org/staffId/85740"> <rdf:type resource="http://description.org/schema/Person"/> <v:Name>Ora Lassila</v:Name> <v:Email>lassila@w3.org</v:Email> </rdf:Description> </s:Creator> </rdf:Description> </rdf:RDF>y utilizando la tercera forma abreviada, así:
<rdf:RDF> <rdf:Description about="http://www.w3.org/Home/Lassila"> <s:Creator> <s:Person about="http://www.w3.org/staffId/85740"> <v:Name>Ora Lassila</v:Name> <v:Email>lassila@w3.org</v:Email> </s:Person> </s:Creator> </rdf:Description> </rdf:RDF>
La EBNF para la sintaxis abreviada sustituye las producciones [2] y [6] de la grámatica para la sintaxis serializa básica, de la siguiente forma:
[2a] description ::= '<rdf:Description' idAboutAttr? propAttr* '/>' | '<rdf:Description' idAboutAttr? propAttr* '>' propertyElt* '</rdf:Description>' | typedNode [6a] propertyElt ::= '<' propName '>' value '</' propName '>' | '<' propName resourceAttr? propAttr* '/>' [16] propAttr ::= propName '="' string '"' (with embedded quotes escaped) [17] typedNode ::= '<' typeName idAboutAttr? propAttr* '/>' | '<' typeName idAboutAttr? propAttr* '>' property* '</' typeName '>'
Cuando escribimos una frase en lenguaje natural utilizamos palabras que encierran la intención de transmitir un significado inequívoco. Ese significado es fundamental para entender el enunciado y, en el caso de aplicaciones de RDF es crucial para establecer que el procesamiento correcto se dé como se esperaba. Es muy importante que tanto el escritor como el lector de una sentencia [declaración] entiendan el mismo significado para los términos utilizados, tales como Creator, approvedBy, Copyright, etc. o resultará una gran confusión. En un medio a escala global como es le World Wide Web no es suficiente confiar en el entendimiento cultural de conceptos tales como la "autoría de una página" ["creatorship"]; conviene ser lo más preciso posible.
En RDF el significado se expresa a través de un esquema. Podemos pensar en un esquema como en una especie de diccionario. Un esquema define los términos que se utilizarán en una sentencia [declaración] RDF y le otorgará significados específicos. Con RDF pueden utilizar una gran variedad de formas de esquema, incluyendo una forma específica definida en un documento aparte [RDFSchema] que tiene algunas características específicas para ayudar a la automatización de tareas usando RDF.
Un esquema es un sitio donde se documentan [se explican] las definiciones y restricciones de uso de las propiedades. Para evitar confusiones entre definiciones independientes --y posiblemente conflictivas-- del mismo término, RDF utiliza la facilidad de los namespace de XML. Los namespaces ["espacios de nombre"] son simplemente una forma de asociar el uso específico de una palabra en el contexto del diccionario (esquema) en que se puede encontrar una definición determinada. En RDF, cada predicado utilizado en una sentencia [declaración] debe ser identificado con un sólo namespace, o esquema. Sin embargo un elemento Description puede contener sentencias con predicados de varios esquemas. Ejemplos donde las descripciones RDF utilizan más de un esquema aparecen en la Sección 7.
Muchas veces el valor de una propiedad es algo que tiene información contextual adicional que se considera "parte de" dicho valor. En otras palabras, es necesario cualificar [o distinguir] los valores de las propiedades. Ejemplos de tales distinciones incluyen la denominación de una unidad de medida, un vocabulario restringido particular, u otros comentarios. Para algunos usos resulta apropiado utilizar el valor de la propiedad sin identificadores o calificadores. Por ejemplo, en la frase " el precio de aquel lápiz es 75 centavos de dólar" en la mayoría de los casos es suficiente decir simplemente "el precio de aquél lápiz es 75".
En el modelo RDF un valor de propiedad cualificada es simplemente otra instancia de un valor estructurado. El objeto de la sentencia original es este valor estructurado y los calificadores [identificadores] son más propiedades de dicho recurso. El principal valor que se cualificará se dará como el valor de la propiedad value del recurso en cuestión. Para un ejemplo del uso de la propiedad value, ver Section 7.3. Relaciones no-binarias.
Normalmente es necesario referirse a una colección de recursos, por ejemplo, para expresar que un trabajo se creó por más de una persona, o para enumerar los estudiantes de un curso, o los módulos de un software en un paquete. Los contenedores RDF se usan para mantener tales listas de recursos o literales.
Nota: Las definiciones de Bag y Sequence permiten explícitamente duplicar valores. RDF no define un concepto puntual de Set, que podría ser un Bag sin duplicados, porque la esencia de RDF no impone un mecanismo de ejecución en el caso de que se violen estas restricciones. En un trabajo futuro en torno a la esencia de RDF pueden definirse tales facilidades.
Para representar colecciones de recursos, RDF utiliza un recurso adicional que identifica la colección específica (una instancia [objeto específico de una categoría] de una colección, en la terminología del modelado de objetos). Este recurso pude declararse como una instancia de uno de los tipos objetos contenedores definidos arriba. La propiedad type, definida a continuación, se utiliza para hacer esta declaración. La relación de pertenencia entre estos recursos contenedores y los recursos que pertenecen a la colección se defina por un conjunto de propiedades definidas expresamente con este propósito. Estas propiedades [de filiación] se denominan simplemente "_1", "_2", "_3", etc. Los recursos contenedores pueden tener otras propiedades añadidas a las propiedades de pertenencia. y la propiedad type. Cualquiera de tales sentencias adicionales describe el contenedor, ver Sección 3.3, Referentes Distributivos, para la profundizar en sentencias sobre cada uno de los miembros.
Un uso común de los contenedores es como valor de una propiedad. Cuando se usa de esta forma, la sentencia tiene, a pesar de todo, un único objeto de declaración, sin tener en cuenta el número de miembros que tenga en el contenedor; el propio recurso contenedor es entonces, el objeto de la sentencia [o declaración].
Por ejemplo, para representar la sentencia.
Los estudiantes que cursan la asignatura 6.001 son Amy, Tim, John, Mary, y Sue.el modelo RDF es
D
Los contenedores Bag no son equivalentes para propiedades repetidas del mismo tipo; ver Sección 3.5. para profundizar en la diferencia. Los autores decidirán en cada caso el principio en que una (propiedad repetida de la sentencia o un Bag) es más apropiado de usar.
La frase:
El código fuente para X11 puede encontrarse en ftp.x.org, ftp.cs.purdue.edu o en ftp.eu.net.se modela en RDF así:
D
Se utilizan con frecuencia contenedores alternativos en combinación con el lenguaje de marcado. Un trabajo cuyo título se ha traducido en varias lenguas podría tener su propiedad Title apuntandoa un contenedor alternativo que mantenga cada una de las variantes idiomáticas.
[18] container ::= sequence | bag | alternative [19] sequence ::= '<rdf:Seq' idAttr? '>' member* '</rdf:Seq>' [20] bag ::= '<rdf:Bag' idAttr? '>' member* '</rdf:Bag>' [21] alternative ::= '<rdf:Alt' idAttr? '>' member+ '</rdf:Alt>' [22] member ::= referencedItem | inlineItem [23] referencedItem ::= '<rdf:li' resourceAttr '/>' [24] inlineItem ::= '<rdf:li>' value '</rdf:li>'Los contenedores pueden usarse en todos los casos en que se permita un elemento Description:
[1a] RDF ::= '<rdf:RDF>' obj* '</rdf:RDF>' [8a] value ::= obj | string [25] obj ::= description | container
Nótese como RDF/XML utiliza li como elemento de conveniencia para evitar que tenga cada miembro un número explícito. El elemento li asigna las propiedades _1, _2, y así si es necesario. El nombre del elemento "li se eligió para que fuera mnemotécnico con el término "list item" del HTML.
Se necesita un cotenedor Alt para tener al menos un miembro. Este miembro se identificará con la propiedad _1 y es el valor por defecto o preferido.
Nota: La especificación del esquema RDF [RDFSCHEMA] también define un mecanismo para declarar subclases adicionales de estos tipos de contenedores, el cuyo caso la producción 18] se extiende a la inclusión de nombres de estas subclases definidas. También existe una sintaxis para escribir valores literales en forma de atributo; ver la gramática completa en la Sección 6.
Los estudiantes que cursan la asignatura 6.001 son Amy, Tim, John, Mary, y Sue.se escribe en RDF/XML así
<rdf:RDF> <rdf:Description about="http://mycollege.edu/courses/6.001"> <s:students> <rdf:Bag> <rdf:li resource="http://mycollege.edu/students/Amy"/> <rdf:li resource="http://mycollege.edu/students/Tim"/> <rdf:li resource="http://mycollege.edu/students/John"/> <rdf:li resource="http://mycollege.edu/students/Mary"/> <rdf:li resource="http://mycollege.edu/students/Sue"/> </rdf:Bag> </s:students> </rdf:Description> </rdf:RDF>
En este caso, teniendo en cuenta que el valor de la propiedad "students", se expresa como un Bag el orden dado no tiene significado el orden dado aquí para el URI de cada estudiante.
El modelo para la frase
El código fuente para X11 puede encontrarse en ftp.x.org, ftp.cs.purdue.edu o en ftp.eu.net.se escribe en RDF/XML así:
<rdf:RDF> <rdf:Description about="http://x.org/packages/X11"> <s:DistributionSite> <rdf:Alt> <rdf:li resource="ftp://ftp.x.org"/> <rdf:li resource="ftp://ftp.cs.purdue.edu"/> <rdf:li resource="ftp://ftp.eu.net"/> </rdf:Alt> </s:DistributionSite> </rdf:Description> </rdf:RDF>
Aquí, cualquiera de los ítems enumerados en el valor del contenedor para "DistributionSite" es un valor aceptable sin tener en cuenta a los otros ítems.
Las estructuras de contenedores han dado lugar a una cuestión relativa a las sentencias [o declaraciones]: cuando una sentencia se hace refiriéndose a una colección, ¿qué "cosa" describe la sentencia? O en otras palabras, ¿a qué objetos se refiere la sentencia?¿La sentencia describe al propio contenedor o describe a los miembros de dicho contenedor? El objeto descrito (en la sintaxis XML indicada por el atributo about) se denomina en RDF referente.
El siguiente ejemplo:
<rdf:Bag ID="pages"> <rdf:li resource="http://foo.org/foo.html" /> <rdf:li resource="http://bar.org/bar.html" /> </rdf:Bag> <rdf:Description about="#pages"> <s:Creator>Ora Lassila</s:Creator> </rdf:Description>
expresa que "Ora Lassila" es el creador de las páginas Bag. Sin embargo no dice nada sobre las páginas individuales, de los miembros del Bag. El referente del elemento Description es el contenedor (Bag), no sus miembros. Alguna vez, a alguien se le podría ocurrir escribir una sentencia sobre cada uno de los objetos contenidos individualmente, en vez del propio contenedor. Para expresar que "Ora Lassila" es el creador de cada una de las páginas, se necesita un tipo distinto de referente, uno que distribuya a los miembros del contenedor. El referente en RDF se expresa usando el atributo aboutEach:
[3a] idAboutAttr ::= idAttr | aboutAttr | aboutEachAttr [26] aboutEachAttr ::= 'aboutEach="' URI-reference '"'Como ejemplo, si escribiéramos
<rdf:Description aboutEach="#pages"> <s:Creator>Ora Lassila</s:Creator> </rdf:Description>
obtendríamos el significado deseado. Llamaríamos al nuevo tipo de referente un referente distributivo. Los referentes distributivos nos permiten "compartir estructura" en un RDF Description. Por ejemplo, cuando escribimos varias Descriptions que todas tienen un número común de partes de sentencia (predicados y objetos) las partes comunes pueden compartirse entre todos los [elementos] Descriptions, dando, posiblemente, como resultado metadatos que se mantienen mejor y que ocupan menos espacio. El valor de un atributo aboutEach debe ser un contenedor. Usar un referente distributivo en un contenedor es lo mismo que hacer todas las sentencias sobre cada uno de los miembros de forma individual.
No se ha definido una representación gráfica explícita de los referentes distributivos. En cambio, en términos de elaboración de sentencias, los referentes distributivos se expanden en sentencias individuales sobre los miembros del contenedor (internamente, las implementaciones son libres de retener información sobre los referentes distributivos --para ahorrar espacio, por ejemplo-- mientras cualquier función de interrogación trabaja como si todas las sentencias se hiciesen individualmente). Así, en relación con los recursos "foo" y "bar", el ejemplo anterior es equivalente a
<rdf:Description about="http://foo.org/foo.html"> <s:Creator>Ora Lassila</s:Creator> </rdf:Description> <rdf:Description about="http://bar.org/bar.html"> <s:Creator>Ora Lassila</s:Creator> </rdf:Description>
Un uso muy frecuente de los metadatos es hacer sentencias sobre "todas las páginas en mi sitio Web", o "todas las páginas en esta parte de mi sitio Web". En muchos casos es poco práctico e incluso no recomendable intentar enumerar cada uno de los recursos explícitamente e identificarlo como miembro de un contenedor. Por consiguiente RDF tiene un segundo tipo de referente distributivo. El segundo tipo de referente distributivo es una sintaxis abreviada [taquigráfica] que representa una instancia de un Bag cuyos miembros son, por definición, todos los recursos cuyos identificadores comienzan con un string [serie de caracteres manipulados como un grupo] específico:
[26a] aboutEachAttr ::= 'aboutEach="' URI-reference '"' | 'aboutEachPrefix="' string '"'
El atributo aboutEachPrefix pone de manifiesto que hay un Bag cuyos miembros son recursos de los que, as su vez, los identificadores de recursos resueltos totalmente comienzan con el string de caracteres dado como el valor del atributo. La sentencia en una Description que tiene el atributo aboutEachPrefix se refiere a cada uno de los miembros de ese contenedor.
Por ejemplo, si los dos recursos http://foo.org/doc/page1 y http://foo.org/doc/page2 existen, podemos decir que cada uno de ellos tiene una propiedad de copyright, escribiendo:
<rdf:Description aboutEachPrefix="http://foo.org/doc"> <s:Copyright>© 1998, The Foo Organization</s:Copyright> </rdf:Description>
Si estos son los dos únicos recursos cuyas URIs comienzan con tal string, la [expresión] anterior es equivalente a estas dos alternativas:
<rdf:Description about="http://foo.org/doc/page1"> <s:Copyright>© 1998, The Foo Organization</s:Copyright> </rdf:Description> <rdf:Description about="http://foo.org/doc/page2"> <s:Copyright>© 1998, The Foo Organization</s:Copyright> </rdf:Description>y
<rdf:Description aboutEach="#docpages"> <s:Copyright>© 1998, The Foo Organization</s:Copyright> </rdf:Description> <rdf:Bag ID="docpages"> <rdf:li resource="http://foo.org/doc/page1"/> <rdf:li resource="http://foo.org/doc/page2"/> </rdf:Bag>
Un recurso puede tener múltiples sentencias con el mismo predicado( es decir, que usan la misma propiedad). Esto no es lo mismo que tener una única sentencias cuyo objeto es un contenedor que contiene diversos miembros. La elección de cuál usar en una circunstancia particular está en parte determinado por la persona que diseña el esquema y en parte por la persona que escribe la sentencia RDF específica.
Sue ha escrito "Anthology of Time", "Zoological Reasoning", "Gravitational Reflections".Es decir, hay tres recursos cada uno de los cuales se escribió de forma independiente por el mismo escritor.
DEn este ejemplo no hay una relación manifiesta entre las publicaciones, a parte de que fue la misma persona quien las escribió.
Por otra parte, la frase
El comité de Fred, Wilma, and Dino aprobó la resolución.
dice que los tres miembros del comité de manera general votaron de una cierta forma, no es necesario afirmar que cada miembro del comité votó en favor de la cláusula. Sería incorrecto modelar esta sentencia como tres sentencias separadas de tipo "approvedBy" una para cada miembro del comité, para afirmar el voto de cada miembro individual. Mejor dicho, es mejor modelarlo como una única sentencia de tipo "approvedBy" cuyo objeto es un Bag que contiene las identidades de los miembros del comité.
D
La elección de qué representación usar, el contenedor Bag
o propiedades repetidas, viene determinada por la persona que crea [asigna]
los metadatos después de considerar el esquema. Si, p. ej., en el ejemplo
anterior de las publicaciones quisiéramos decir que esas eran el conjunto
completo de publicaciones, el esquema debería incluir una propiedad denominada
publications. El valor de la propiedad publications
sería un Bag que enumerara todos los trabajos de la escritora
Sue.
Además de hacer sentencias sobre los recursos Web, RDF puede usarse para crear sentencias sobre otras declaraciones RDF; nos referiremos a éstas como sentencias de alto nivel [higher-order statements]. Para realizar declaraciones sobre otras declaraciones, tenemos que construir un modelo de la sentencia original; este modelo es un nuevo recurso al que podemos anexar propiedades adicionales.
Las sentencias se hacen sobre los recursos. Un modelo de una sentencia es el recurso que necesitamos para poder hacer una nueva declaración (una sentencia de alto nivel) sobre la declaración modelada.
Por ejemplo, consideremos la frase:
Ora Lassila es el creador [autor] del recurso http://www.w3.org/Home/Lassila.RDF estimaría esta sentencia como un hecho. Si, en lugar de eso, escribimos la frase:
Ralph Swick dice que Ora Lassila el creador [autor] del recurso http://www.w3.org/Home/Lassila.
no hemos dicho nada sobre el recurso http://www.w3.org/Home/Lassila; en cambio, hemos expresado el hecho sobre la afirmación que hizo Ralph. Para expresar este hecho en RDF, tenemos que modelar la declaración original como un recurso con cuatro propiedades. Este proceso se denomina formalmente "reification" [transformación de algo abstracto en concreto] en el contexto de la Representación del Conocimiento. Un modelo de sentencia se denomina "reified statement" [sentencia transformada de lo abstracto a lo concreto].
RDF define las siguientes propiedades para modelar sentencias:
Un nuevo recurso con las cuatro propiedades anteriores representa la sentencia original y puede tanto usarse como objeto de otras declaraciones como tener una sentencia adicional sobre él. El recurso con estas cuatro propiedades no es un substituto de la sentencia original, es un modelo de la declaración. Una sentencia [declaración] y sus correspondientes sentencias transformadas [de lo abstracto a lo concreto, reified] existe independientemente sin las otras. La representación gráfica RDF se presenta para contener el hecho de la sentencia si y sólo si dicha sentencia se presenta en forma gráfica, sin considerar si la sentencia correspondiente transformada está presente.
Para modelar el ejemplo anterior, podemos adjuntar otra propiedad a la sentencia transformada (es decir, "attributedTo") con un valor apropiado (en este caso "Ralph Swick"). Utilizando la sintaxis de nivel básico RDF/XML, podría escribirse así:
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:a="http://description.org/schema/"> <rdf:Description> <rdf:subject resource="http://www.w3.org/Home/Lassila" /> <rdf:predicate resource="http://description.org/schema/Creator" /> <rdf:object>Ora Lassila</rdf:object> <rdf:type resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#Statement" /> <a:attributedTo>Ralph Swick</a:attributedTo> </rdf:Description> </rdf:RDF>
La figura 8 representa esto gráficamente. Sintácticamente es más bien poco concisa [o poco prolija]; en la Sección 4.2. presentamos unas abreviaturas [taquigrafía] para hacer sentencias sobre sentencias [declaraciones sobre declaraciones RDF]
D
La reification [transformación de algo abstracto en algo concreto] se necesita también para representar explícitamente en el modelo la sentencia de agrupación implícita en el elemento Description. El modelo gráfico RDF no necesita una construcción especial para los elementos Description; dado que los Descriptions son en realidad colecciones de sentencias, se usa un contenedor Bag para indicar que un conjunto de sentencias que provienen del mismo elemento (sintáctico) Description. Cada sentencia dentro de un Description se transforma [reified] y cada una de las sentencias transformadas es miembro del Bag que representa dicha Description. Como ejemplo de esto, este fragmento RDF:
<rdf:RDF> <rdf:Description about="http://www.w3.org/Home/Lassila" bagID="D_001"> <s:Creator>Ora Lassila</s:Creator> <s:Title>Ora's Home Page</s:Title> </rdf:Description> </rdf:RDF>resultaría en el gráfico de la figura 9.
DNótese el nuevo atributo bagID. Este atributo especifica el recurso id del recurso contenedor:
[2b] description ::= '<rdf:Description' idAboutAttr? bagIDAttr? propAttr* '/>' | '<rdf:Description' idAboutAttr? bagIDAttr? propAttr* '>' propertyElt* '</rdf:Description>' [27] bagIDAttr ::= 'bagID="' IDsymbol '"'
BagID e ID no deben confundirse. ID especifica el identificador de un recurso in-line cuyas propiedades se detallan más ampliamente en la descripción [elemento Description]. BagID especifica la identificación del recurso contenedor cuyos miembros son sentencias transformadas [de lo abstracto a lo concreto] sobre otro recurso. Un elemento Description puede tener ambos atributos ID y bagID.
Dado que añadir un bagID a un elemento Description conlleva incluir en el modelo un Bag de la sentencia transformada [de lo abstracto a lo concreto] de Description, podemos usar esta como una abreviatura sintáctica cuando hagamos sentencias sobre sentencias. Por ejemplo, se queremos decir que Ralph afirma que Ora es el creador de http://www.w3.org/Home/Lassila y que el título de dicho recurso es "Ora's Home Page", simplemente podemos añadir al ejemplo anterior:
<rdf:Description aboutEach="#D_001"> <a:attributedTo>Ralph Swick</a:attributedTo> </rdf:Description>
Nótese que este ejemplo de la taquigrafía [abreviatura] incluye hechos adicionales en el modelo no representados en el ejemplo de la figura 8. El uso de esta abreviatura expresa hechos sobre las afirmaciones de Ralph y también hechos sobre la home page de Ora.
D
Se remite al lector a la Sección 5 ("Modelo Formal") de esta especificación para un tratamiento formal de las sentencias de alto nivel [higher-order statements] y la transformación de lo abstracto a lo concreto [reification].
Esta especificación presenta tres representaciones del modelo de datos; como 3-tuplas (triples), como gráfico, y en XML. Estas representaciones tienen un significado equivalente. El mapeo entre las representaciones que se utilizan en esta especificación no tienen pretenden de forzar de ninguna manera la representación interna usada en la implementación.
El modelo de datos de RDF se define formalmente como sigue:
Podemos ver un conjunto de sentencias (miembros de Statements) como un gráfico directamente etiquetado: cada recurso y literal es un vértice, un triple {p, s, o} es un arco de s hasta o etiquetado por p. Esto se ilustra en la figura 11.
DEsto puede leerse bien como:
o es el valor de p para so como (de derecha a izquierda)
la p de s es oPor ejemplo, la frase:
Ora Lassila es el creador [autor] del recurso http://www.w3.org/Home/Lassilase representaría gráficamente como se presenta a continuación:
D{creator, [http://www.w3.org/Home/Lassila], "Ora Lassila"}La notación [I] denota el recurso identificado por el URI I y las comillas denotan un literal.
Utilizando los triples, podemos explicar qué sentencias están transformadas (como se presentó en la Sección 4). Dada una sentencia
{type, [X], [RDF:Statement]}
{predicate, [X], [creator]}
{subject, [X], [http://www.w3.org/Home/Lassila]}
{object, [X], "Ora Lassila"}
Desde el punto de vista de un procesador RDF, los hechos (es decir, las sentencias o statements) son triples que son miembros de Statements. Por lo tanto, la sentencia original permanece como un hecho a pesar de que se transforme [de lo abstracto a lo concreto], dado que el triple que representa la sentencia original permanece en Statements. Sencillamente hemos añadido cuatro triples más.
La propiedad denominada "type" se define para proporcionar la tipografía primigenia. La definición formal de type es:
|
|
El recurso r en la definición anterior se llama sentencia transformada [reified statement]. Cuando un recurso representa una sentencia transformada; es decir, que tiene una propiedad RDF:type con un valor de RDF:Statement, entonces dicho recurso puede tener exactamente una propiedad RDF:subject, una propiedad RDF:object, y una propiedad RDF:predicate.
Como se describe en la sección 3, normalmente es necesario representar una colección de recursos o literales, por ejemplo para declarar que una propiedad tiene una secuencia ordenada de valores. RDF define tres tipos de colecciones: listas ordenadas, denominadas Sequences, listas desordenadas, denominadas Bags, y listas que representan alternativas para el valor (único) de una propiedad, denominadas Alternatives.
Formalmente, estos tres tipos de colecciones se definen por:
|
Para representar una colección c, crear un triple {RDF:type, c, t} donde t es una de los tres tipos de colecciones RDF:Seq, RDF:Bag, o RDF:Alt. Los triples restantes {RDF:_1, c, r1}, ..., {RDF:_n, c, rn}, ... apuntan hacia cada uno de los miembros rn de la colección. Para una colección individual el recurso puede ser como mucho un triple cuyo predicado es cualquier elemento dado de Ord debe usarse en una secuencia que comience con RDF:_1. Para recursos que son objetos específicos de una categoría [instances] del tipo de colección RDF:Alt, debe ser exactamente un triple cuyo predicado es: RDF:_1 y que es el valor por defecto para recursos alternativos (esto es, debe tener siempre al menos una alternativa).
La BNF [Backus-Naur Form] para RDF se reproduce aquí para completar las secciones previas. También se da aquí la interpretación precisa de la gramática formal en términos del modelo formal. Las características sintácticas heredadas de XML no se reproducen ahora. Esto incluye todas las restricciones relativas a los documentos bien formados, el uso del espacio en blanco al rededor de los atributos y el '=', así como el uso tanto de las comillas simples como dobles en torno a los valores de los atributos. Esta sección está dirigida a los implementadores que están construyendo herramientas que lean e interpreten la sintaxis RDF/XML.
A continuación, donde se usen las palabras clave: "SHOULD" (deber), "MUST" (tener que), y "MUST NOT" (no tener que) se debe interpretar como se describe en RFC 2119 [RFC2119]. No obstante, para una mayor legibilidad, estas palabras no aparecen en mayúsculas en esta especificación.
[6.1] RDF ::= ['<rdf:RDF>'] obj* ['</rdf:RDF>'] [6.2] obj ::= description | container [6.3] description ::= '<rdf:Description' idAboutAttr? bagIdAttr? propAttr* '/>' | '<rdf:Description' idAboutAttr? bagIdAttr? propAttr* '>' propertyElt* '</rdf:Description>' | typedNode [6.4] container ::= sequence | bag | alternative [6.5] idAboutAttr ::= idAttr | aboutAttr | aboutEachAttr [6.6] idAttr ::= ' ID="' IDsymbol '"' [6.7] aboutAttr ::= ' about="' URI-reference '"' [6.8] aboutEachAttr ::= ' aboutEach="' URI-reference '"' | ' aboutEachPrefix="' string '"' [6.9] bagIdAttr ::= ' bagID="' IDsymbol '"' [6.10] propAttr ::= typeAttr | propName '="' string '"' (with embedded quotes escaped) [6.11] typeAttr ::= ' type="' URI-reference '"' [6.12] propertyElt ::= '<' propName idAttr? '>' value '</' propName '>' | '<' propName idAttr? parseLiteral '>' literal '</' propName '>' | '<' propName idAttr? parseResource '>' propertyElt* '</' propName '>' | '<' propName idRefAttr? bagIdAttr? propAttr* '/>' [6.13] typedNode ::= '<' typeName idAboutAttr? bagIdAttr? propAttr* '/>' | '<' typeName idAboutAttr? bagIdAttr? propAttr* '>' propertyElt* '</' typeName '>' [6.14] propName ::= Qname [6.15] typeName ::= Qname [6.16] idRefAttr ::= idAttr | resourceAttr [6.17] value ::= obj | string [6.18] resourceAttr ::= ' resource="' URI-reference '"' [6.19] Qname ::= [ NSprefix ':' ] name [6.20] URI-reference ::= string, interpreted per [URI] [6.21] IDsymbol ::= (any legal XML name symbol) [6.22] name ::= (any legal XML name symbol) [6.23] NSprefix ::= (any legal XML namespace prefix) [6.24] string ::= (any XML text, with "<", ">", and "&" escaped) [6.25] sequence ::= '<rdf:Seq' idAttr? '>' member* '</rdf:Seq>' | '<rdf:Seq' idAttr? memberAttr* '/>' [6.26] bag ::= '<rdf:Bag' idAttr? '>' member* '</rdf:Bag>' | '<rdf:Bag' idAttr? memberAttr* '/>' [6.27] alternative ::= '<rdf:Alt' idAttr? '>' member+ '</rdf:Alt>' | '<rdf:Alt' idAttr? memberAttr? '/>' [6.28] member ::= referencedItem | inlineItem [6.29] referencedItem ::= '<rdf:li' resourceAttr '/>' [6.30] inlineItem ::= '<rdf:li' '>' value </rdf:li>' | '<rdf:li' parseLiteral '>' literal </rdf:li>' | '<rdf:li' parseResource '>' propertyElt* </rdf:li>' [6.31] memberAttr ::= ' rdf:_n="' string '"' (where n is an integer) [6.32] parseLiteral ::= ' parseType="Literal"' [6.33] parseResource ::= ' parseType="Resource"' [6.34] literal ::= (any well-formed XML)
El namespace formal para las propiedades y clases definidas en
esta especificación es
http://www.w3.org/1999/02/22-rdf-syntax-ns#.
Cuando un procesador RDF encuentra un elemento o nombre de atributo XML que está
declarado para constituir un namespace cuyo nombre comience por la
cadena "http://www.w3.org/TR/REC-rdf-syntax" y el
procesador no reconozca la semántica de dicho nombre, necesita saltar (es decir,
no generar tuplas para él) el elemento XML entero, incluyendo su contenido, cuyo
nombre no esté reconocido o que tenga un atributo cuyo nombre no se
reconozca.
Cada propertyElt E contenido por un elemento Description tiene como resultado la creación de un triple {p,r,v} donde:
p es la expansión del nombre de la etiqueta del namespace apto (Identificador Genérico) de E. Esta expansión se genera a través de la concatenación de nombres de namespace dados en una declaración de namespace con el LocalPart del nombre aceptado.
Si E es un elemento vacío (sin contenido), v es el recurso cuyo identificador se da gracias al atributo resource de E. Si el contenido de E no es marcado XML o si parseType="Literal" se especifica en la etiqueta inicial de E, entonces v es el contenido de E (un literal). Por otra parte, el contenido de E debe ser otra descripción [Description] o un contenedor y v es el recurso nombrado por el (posiblemente implícito) ID o about de dicho [elemento] Description o contenedor.
El atributo parseType cambia la interpretación del contenido del elemento. El atributo parseType debe tener uno de los valores 'Literal' o 'Recurso'. El valor es diferente en mayúsculas o minúsculas. El valor 'Literal' especifica que el contenido del elemento se tratará como literal RDF/XML; esto es, el contenido no debe interpretarse por un procesador RDF. El valor 'Recurso' especifica que dicho contenido del elemento debe tratarse como si fuera el contenido de un elemento Description. Otros valores de parseType se reservan para especificación futura por RDF. Con RDF 1.0 otros valores deben tratarse como un 'Literal' idéntico. En todos los casos, el contenido de un elemento que tiene un atributo parseType debe ser XML bien formado. El contenido de un elemento que tiene un atributo parseType="Resource" debe además corresponder con la producción para el contenido de un elemento Description.
El Grupo de trabajo dedicado al Modelo y la Sintaxis de RDF agradece que el mecanismo parseType='Literal' sea una solución a nivel mínimo para los requisitos necesarios para expresar una sentencia RDF con un valor que tenga marcado XML. Complejidades adicionales de XML tales como canonización de espacios en blanco no están bien definidas todavía. En el trabajo futuro del W3C esperamos resolver dicho problema de una manera uniforme para todas las aplicaciones basadas en XML. Las versiones futuras de RDF heredarán este trabajo y pueden extenderlo al mismo tiempo que lleguemos a un mayor entendimiento a través de la aplicación en experiencias ulteriores.
Las referencias URI ser resuelven en un identificador de recursos, primero resolviendo la referencia URI en forma absoluta como se especifica en [URI] utilizando el URI base del documento en el cual aparece la sentencia RDF. Si un identificador de fragmento se incluye en la referencia URI, el identificador de recursos se refiere sólo a un subcomponente del recurso contenedor; este subcomponente se identifica a través del identificador de ancla interno hacia el recurso que lo contiene y el alcance del subcomponente se define a través del identificador de fragmento en conjunción con el tipo de contenido del recurso que lo contiene, por otra parte el identificador del recurso se refiere al ítem completo especificado por el URI.
Nota: A pesar de que los caracteres no-ASCII no están permitidos en el [URI], [XML] especifica una convención para evitar incompatibilidades innecesarias en la sintaxis URI extendida. Los implementadores de RDF están sensibilizados para evitar más incompatibilidades y utilizan la convención XML para los identificadores del sistema. Particularmente, aquellos caracteres no-ASCII en un URI están representados en UTF-8 como uno o más bytes, de tal forma que estos bytes se solucionan con el "mecanismo de escapatoria" [escaping mechanism] de URI (es decir, convirtiendo cada byte en %HH, donde HH es la notación hexadecimal del valor del byte).
El elemento Description en sí mismo es una instancia [objeto específico de una categoría] de un recurso Bag. Los miembros de este Bag son los recursos que corresponden con la reification [transformación de algo abstracto en algo concreto] de cada una de las sentencias en Description. Si el atributo bagID se especifica, su valor es el identificador de ese Bag, incluso si el Bag es anónimo.
Cuando se especifica about con Description, la sentencia en el [elemento] Description se refiere al recurso nombrado en el about. Un elemento Description sin un atributo about representa un recurso in-line. Este recurso in-line tiene un identificador de recurso formado utilizando el valor de la base URI del documento que contiene la sentencia RDF más un identificador de ancla igual al valor del atributo ID del elemento Description, en su caso. Cuando otro [elemento] Description o valor de propiedad se refiere al recurso in-line utilizará el valor del ID en un atributo about. Cuando el otro Description se refiere al Bag del recurso que corresponde a la sentencia que transforma algo abstracto en algo concreto [reified] se utilizará el valor de bagID en un atributo about. Tanto ID como about pueden especificarse en el elemento Description pero no juntos en el mismo elemento. Los valores para cada atributo ID y bagID no deben aparecer en más de uno de tales atributos dentro de un documento ni pueden [aparecer] el mismo valor usarse en un ID y un bagID dentro de un documento individual.
Cuando se especifica aboutEach con Description, la sentencia en [el elemento] Description se refiere a cada uno de los miembros del contenedor denominado aboutEach. El triples {p,r,v} representado con cada propertyElt E contenido, como se ha descrito anteriormente, se duplican para cada r que es miembro del contenedor.
Cuando se especifica aboutEachPrefix con [el elemento] Description, la sentencia en el Description se refiere a cada uno de los miembros de un contenedor Bag anónimo. Los miembros de ese contenedor Bag son todos los recursos cuyo identificador de recursos en forma absoluta comienza con la cadena de caracteres dada como valor del aboutEachPrefix.La forma absoluta del identificador de recursos se produce a través de la resolución del URI de acuerdo con el algoritmo en la Sección 5.2. Resolviendo Referencias Relativas a Forma Absoluta, en [URI]. El triple {p,r,v} representado por cada propertyElt E tal como se ha descrito anteriormente, se duplican para cada uno de los miembros del contenedor.
Seq, Bag, y Alt representan, cada uno, una instancia [objeto específico de una categoría] de un tipo de recurso contenedor Sequence, Bag, o Alternative, respectivamente. Se crea un triple {RDF:type,c,t} donde c es el recurso que compendia y t es uno de RDF:Seq, RDF:Bag, o RDF:Alt. Los miembro de la colección se denotan por li. Cada elemento E li corresponde a un miembro de la colección y resulta de la creación de un triple {p,c,v} donde:
p se asigna paulatinamente de acuerdo con el orden (XML) de apariencia léxica de cada miembro que empieza con "RDF:_1" para cada contenedor.
c es el recurso que recopila. El atributo ID, en el caso de que se especifique, proporciona el identificador del fragmento URI para c.
(Misma regla 3 anterior) Si E es un elemento vacío (sin contenido), v es el recurso cuyo identificador se da gracias al atributo resource de E. Si el contenido de E no es marcado XML o si parseType="Literal" se especifica en la etiqueta inicial de E, entonces v es el contenido de E (un literal). Por otra parte, el contenido de E debe ser otra descripción [Description] o un contenedor y v es el recurso nombrado por el (posiblemente implícito) ID o about de dicho [elemento] Description o contenedor.
El URI identifica (después de resuelto) el recurso objeto, es decir, el recurso al cual se aplica Description o el recurso que se incluye en el contenedor. El atributo bagID en un elemento Description y el atributo ID en un elemento contenedor permiten que [el elemento] Description o el contenedor sean referenciados por otros Descriptions. El ID en un elemento contenedor es el nombre que se usa en un atributo resource en un elemento propiedad para hacer a la colección el valor de dicha propiedad.
Dentro de propertyElt (producción [6.12]), el URI utilizado en un atributo resource identifica (después de resuelto) el recurso que es objeto de la sentencia (es decir, el valor de dicha propiedad). El valor del atributo ID, si aparece especificado, es el identificador para el recurso que representa la reification [transformación de lo abstracto en concreto] de la sentencia. Si una expresión RDF (esto es, contenido con marcado RDF/XML) se especifica como un valor de propiedad el objeto es el recurso dado por el atributo about de la Description contenida o el (posiblemente implicado) ID de la Description contenida o el recurso contenedor. Los Strings deben ser XML bien formado; el contenido normal y los mecanismos de escape en XML pueden usarse si la cadena de caracteres contiene secuencias de carácter (p. ej. "<" y "&") que violan las reglas de la buena formación o que de lo contrario podrían parecer marcado. El atributo parseType="Literal" especifica que el contenido del elemento es un literal RDF. Cualquier marcado que sea parte de ese contenido se incluye como parte del literal y no es interpretado por RDF.
Se recomienda que los nombres de las propiedades estén siempre cualificados con un prefijo de namespace para conectar de forma inequívoca la definición de la propiedad con el esquema correspondiente.
En tanto que está definido por XML, el repertorio de caracteres de un string [o conjunto de caracteres] es ISO/IEC 10646 [ISO10646]. Un string RDF actual, tanto en un documento XML o en otra representación del modelo de datos RDF, puede almacenarse usando una codificación directa de ISO/IEC 10646 o una codificación que pueda mapearse a ISO/IEC 10646. El lenguaje de etiquetas [marcado] es parte del valor del string; se aplica a secuencias de caracteres dentro de un string RDF y no tiene una manifestación explícita en el modelo de datos.
Se estima que dos strings RDF son iguales si sus representaciones ISO/IEC 10646 coinciden. Cada aplicación RDF debe especificarse con una de las definiciones siguientes de "coincidencia" que utilice:
Nota: El W3C I18N WG está trabajando en una definición para la coincidencia de identidad de las secuencias de caracteres [string identity matching]. Esta definición se basará, probablemente, en las equivalencias canónicas según el estándar Unicode y en el principio de normalización uniforme antigua [early uniform normalization]. Los usuarios de RDF no deben confiar en cualquier aplicación que coincida utilizando los equivalentes canónicos, pero debe intentar asegurarse de que sus datos están en la forma normalizada de acuerdo con las próximas definiciones.
Esta especificación no establece un mecanismo para determinar la equivalencia entre los literales que contiene el marcado, ni tampoco se garantiza la existencia de un mecanismo tal.
El atributo xml:lang pude usarse como se define en [XML] para asociar un idioma con el valor de la propiedad. No hay una representación del modelo de datos específica para xml:lang (es decir, no añade triples al modelo de datos); el idioma de un literal se considera en RDF como una parte del literal. Una aplicación puede ignorar el marcado de idioma de un string. Todas las aplicaciones RDF deben especificar si el idioma de marcado en los literales es significativo o no; esto es, si se considera o no el idioma cuando se realiza la comprobación [matchig] de literales u otro proceso.
Los atributos cuyos nombres empiezan con "xmlns" son declaraciones de namespace y no representan triples en el modelo de datos. No existe una representación de modelo de datos específico para cada declaración de namespace.
Cada propiedad y valor expresados en forma de atributos XML por procedimiento [6.3] y [6.10] es equivalente a la misma propiedad y valor expresados como contenido XML del [elemento] Description correspondiente de acuerdo al procedimiento [6.12]. Específicamente, cada atributo A XML con una etiqueta de inicio Description en vez de los atributos ID, about, aboutEach, aboutEachPrefix, bagID, xml:lang, o cualquier atributo que inicie con los caracteres xmlns da como resultado la creación de un triple {p,r,v} donde:
p es la expansión del nombre del atributo del namespace cualificado de A. Esta expansión se genera a través de la concatenación del nombre del namespace dado en una declaración de namespace con el LocalPart del nombre cualificado y de esta forma resolviendo este URI de acuerdo con el algoritmo de la Sección 5.2., Resolviendo Referencias Relativas a Forma Absoluta, en [URI].
r es el recurso cuyo identificador de recurso se expresa por el valor del atributo about, resuelto como se especificó anteriormente, o cuyo id del ancla se expresa por el valor del atributo ID de la descripción o es un miembro de la colección especificada por un aboutEach o un atributo aboutEachPrefix.
v es el valor del atributo de A (un literal).
Gramaticalmente, la elaboración [6.11] es precisamente un caso especial de la producción del propName [6.10]. El valor del atributo type se interpreta como un URI de referencia y se expande de la misma forma que el valor del atributo resource El uso de [6.11] es equivalente a usar rdf:type como un