MXPA05006260A

MXPA05006260A - Sistemas y metodos para extensiones y herencia para unidades de informacion manejables a traves de un sistema de interfaz de sistemas de componentes fisicos de computacion y programas y sistemas de programacion.

Info

Publication number: MXPA05006260A
Application number: MXPA05006260A
Authority: MX
Inventors: M Spiro Peter
Original assignee: Microsoft Corp
Priority date: 2003-08-21
Filing date: 2004-07-29
Publication date: 2005-08-19
Also published as: AU2004271531A1; EP1604310A4; CA2815867C; JP2007503051A; JP4580390B2; CA2815562C; CN1871598A; CN1871598B; IL168666A; KR101022936B1; CA2815867A1; KR20060057524A; CA2815562A1; NO20052052D0; TWI337310B; WO2005024666A2; CA2506337A1; TW200513874A; CA2506337C; BRPI0406512A

Abstract

Al modelar objetos de aplicacion del mundo real con estructuras complejas, conductas y operaciones descritas a traves de un esquema se refuerza mediante el sistema de componentes fisicos de computo y programas y sistemas de programacion, diversas modalidades de la presente invencion proporcionan una funcionalidad rica en subclasificacion (3602, 3604, 3606, 6322, 3624, 3626, 3642, 3644) al extender elementos usando extensiones que proporcionan estructuras de datos adicionales a las estructuras de los tipos de elementos existentes; las extensiones son instancias muy clasificadas que no pueden existir de manera independiente y deben anexarse a un elemento o a un elemento anidado; las extensiones tambien tienen la intencion de resolver problemas de clasificacion multiples al habilitar el traslapo del tipo de instancias.

Description

SISTEMAS Y MÉTODOS PARA EXTENSIONES Y HERENCIA PARA UNIDADES DE INFORMACIÓN MANEJABLES A TRAVÉS DE UN SISTEMA DE INTERFAZ DE SISTEMAS DE COMPONENTES FÍSICOS DE COMPUTACIÓN Y PROGRAMAS Y SISTEMAS DE PROGRAMACIÓN REFERENCIA CRUZADA CON SOLICITUDES RELACIONADAS Esta solicitud reclama prioridad a la solicitud de patente EE.UU. No. 10/693,574 (caso No. MSFT-2847) presentada el 24 de octubre de 2003, titulada "SISTEMAS Y MÉTODOS PARA EXTENSIONES Y HERENCIA PARA UNIDADES DE INFORMACIÓN MANEJABLES A TRAVÉS DE UN SISTEMA DE INTERFAZ DE SISTEMAS DE COMPONENTES FÍSICOS DE COMPUTACIÓN Y PROGRAMAS Y SISTEMAS DE PROGRAMACIÓN", solicitud de patente EE.UU. No. 10/646,580 (caso No. MSFT-2735), presentada el 21 de agosto de 2003, titulada "SISTEMAS Y MÉTODOS PARA MODELAR DATOS EN UNA PLATAFORMA DE ALMACENAMIENTO BASADA EN ELEMENTOS"; y la solicitud internacional No. PCT/US03/26, 144 (caso No. MSFT-2779) presentada el 21 de agosto de 2003, titulada "SISTEMAS Y MÉTODOS PARA MODELAR DATOS EN UNA PLATAFORMA DE ALMACENAMIENTO BASADA EN ELEMENTOS"; el contenido de las cuales se incorporan a la presente por referencia.

Esta solicitud se relaciona en cuanto a la materia de las invenciones descritas en las siguientes solicitudes comúnmente asignadas, el contenido de las cuales se incorporan a la presente por referencia en esta solicitud por completo (y se resumen parcialmente en la presente por comodidad): La solicitud de patente EE.UU. No. 10/647,058 (caso No. MSFT-1748), presentada el 21 de agosto de 2003, titulada "MÉTODOS Y SISTEMAS PARA REPRESENTAR UNIDADES DE INFORMACIÓN MANEJABLES MEDIANTE UN SISTEMA DE INTERFAZ DE COMPONENTES FÍSICOS DE COMPUTACIÓN Y PROGRAMAS Y SISTEMAS DE PROGRAMACIÓN CON DEPENDENCIA DE LA REPRESENTACIÓN FÍSICA"; la solicitud de patente de EE.UU. No. 10/646,941 (caso No. MSFT-1749), presentada el 21 de agosto de 2003, titulada "SISTEMAS Y MÉTODOS PARA SEPARAR UNIDADES DE INFORMACIÓN MANEJABLES A TRAVÉS DE UN SISTEMA DE INTERFAZ DE COMPONENTES FÍSICOS DE COMPUTACIÓN DE PROGRAMAS Y SISTEMAS DE PROGRAMACIÓN DE SU ORGANIZACIÓN FÍSICA"; solicitud de patente EE.UU. No. 10/646,940 (caso No. MSFT-1750), presentada el 21 de agosto de 2003, titulada "SISTEMAS Y MÉTODOS PARA LA IMPLEMENTACIÓN DE UN ESQUEMA BASE PARA LA ORGANIZACIÓN DE UNIDADES DE INFORMACIÓN MANEJABLES A TRAVÉS DE UN SISTEMA DE INTERFAZ DE COMPONENTES FÍSICOS DE COMPUTACIÓN Y PROGRAMAS Y SISTEMAS DE PROGRAMACIÓN"; solicitud de patente de EE.UU. NO. 10/646,632 (caso No. MSFT-1751), presentada el 21 de agosto de 2003, titulada "SISTEMAS Y MÉTODOS PARA LA IMPLEMENTACIÓN DE UN ESQUEMA CENTRAL PARA PROVEER UNA ESTRUCTURA DE ALTO NIVEL PARA ORGANIZAR UNIDADES DE INFORMACIÓN MANEJABLES A TRAVÉS DE UN SISTEMA DE INTERFAZ DE COMPONENTES FÍSICOS DE COMPUTACIÓN Y PROGRAMAS Y SISTEMAS DE PROGRAMACIÓN"; solicitud de patente de EE.UU. No. 10/646,645 (caso No. MSFT-1752), presentada el 21 de agosto de 2003, titulada "SISTEMAS Y MÉTODOS PARA REPRESENTAR RELACIONES ENTRE UNIDADES DE INFORMACIÓN MANEJABLES A TRAVÉS DE UN SISTEMA DE INTERFAZ DE COMPONENTES FÍSICOS DE COMPUTACIÓN DE PROGRAMAS Y SISTEMAS DE PROGRAMACIÓN"; solicitud de patente de EE.UU. No. 10/646,575 (caso No. MSFT-2733), presentada el 21 de agosto de 2003, titulada "SISTEMAS Y MÉTODOS PARA CONECTAR PROGRAMAS DE APLICACIÓN CON UNA PLATAFORMA DE ALMACENAMIENTO BASADA EN ELEMENTOS"; solicitud de patente de EE.UU. No. 10/646,646 (caso No. MSFT-2734), presentada el 21 de agosto de 2003, titulada "PLATAFORMA DE ALMACENAMIENTO PARA ORGANIZAR, BUSCAR Y COMPARTIR DATOS"; solicitud de patente de EE.UU. No. 10/692,779 (caso No. MSFT-2829), presentada el 24 de octubre de 2003, titulada "SISTEMAS Y MÉTODOS PARA I MPLEMENTAR UN ESQUEMA DE IMÁGENES DIGITALES PARA ORGANIZAR UNIDADES DE INFORMACIÓN MANEJABLES A TRAVÉS DE UN SISTEMA DE INTERFAZ DE COMPONENTES FÍSICOS DE COMPUTACIÓN Y PROGRAMAS Y SISTEMAS DE PROGRAMACIÓN"; solicitud de patente de EE.UU. No. 10/692,515 (No. de Caso MSFT-2844), presentada el 24 de octubre de 2003, titulada "SISTEMAS Y MÉTODOS PARA PROVEER SERVICIOS DE SINCRONIZACIÓN PARA UNIDADES DE INFORMACIÓN MANEJABLES A TRAVÉS DE UN SISTEMA DE INTERFAZ DE COMPONENTES FÍSICOS DE COMPUTACIÓN Y PROGRAMAS Y SISTEMAS DE PROGRAMACIÓN"; solicitud de patente de EE.UU. No. 10/692,508 (No. de caso MSFT-2845), presentada en conjunto con la presente titulada "SISTEMAS Y MÉTODOS PARA PROVEER SERVICIOS DE SINCRONIZACIÓN JERÁRQUICA Y RELACIONAL PARA UNIDADES DE INFORMACIÓN MANEJABLES A TRAVÉS DE UN SISTEMA DE INTERFAZ DE COMPONENTES FÍSICOS DE COMPUTACIÓN DE PROGRAMAS Y SISTEMAS DE PROGRAMACIÓN"; y la solicitud de patente de EE.UU. No. 10/693,362 (No. de caso MSFT-2846), presentada el 24 de octubre de 2003, titulada "SISTEMAS Y MÉTODOS PARA LA IMPLEMENTACIÓN DE ESQUEMAS DE SINCRONIZACIÓN PARA UNIDADES DE INFORMACIÓN MANEJABLES A TRAVÉS DE UN SISTEMA DE I NTERFAZ DE COMPONENTES FÍSICOS DE COMPUTACIÓN Y PROGRAMAS Y SISTEMAS DE PROGRAMACIÓN". Campo de la Invención La presente invención se refiere en general al campo del almacenamiento de información y a la recuperación y, en particular, a una plataforma de almacenamiento activa para organizar, buscar y compartir diferentes tipos de datos en un sistema computarizado. Varias modalidades de la presente invención se dirigen al uso de métodos de extensión y herencia utilizados por un sistema de interfaz de componentes físicos de computación y programas y sistemas de programación para manejar datos. Antecedentes de la Invención La capacidad de los discos individuales ha presentado un crecimiento del setenta por ciento (70%) por año durante ia última década. La ley de Moore predijo de manera precisa los enormes beneficios de la potencia de una unidad de procesamiento central (CPU) que se ha presentado con el paso de los años. Las tecnologías cableadas e inalámbricas han proporcionado una enorme conectividad y ancho de banda. Asumiendo que las tendencias actuales continúen, dentro de algunos años una computadora portátil promedio poseerá aproximadamente un Terabyte (TB) de almacenamiento y contiene millones de archivos, y las unidades de 500 Gigabytes (GB) serán más comunes.

Los consumidores usan sus computadoras principalmente para la comunicación y la organización de información personal, ya sea que ésta sea de datos del estilo de un administrador de información personal (PI ) tradicional o de medios como fotografías o música digital. La cantidad de contenido digital, y la capacidad de almacenamiento de bytes sin procesar, ha aumentado en gran medida. Sin embargo, los métodos disponibles con los que cuentan los consumidores para organizar y unificar estos datos no ha seguido el paso. Los trabajadores intelectuales invierten una enorme cantidad de tiempo en la administración de la información y para compartirla, y algunos estudios estiman que los trabajadores intelectuales invierten entre el 15 y el 25% de su tiempo en actividades relacionadas con la información sin producir. Otros estudios estiman que un trabajador intelectual típico invierte cerca de 2.5 horas diarias buscando información. Los desabolladores y los departamentos de la tecnología de información (TI) invierten cantidades importantes de tiempo y dinero en la construcción de sus propios almacenes de datos para abstracciones de almacenamiento común y representar tales cosas como personas, lugares, horarios y eventos. No sólo ocasiona trabajo duplicado, también crea islas de datos comunes sin mecanismos para una búsqueda común o para compartir datos. Tan sólo considere cuántas libretas de direcciones pueden existir actualmente en una computadora que se ejecuta bajo un sistema operativo Windows de Microsoft. Diversas aplicaciones, como cliente de correo electrónico y programas de finanzas personales, guardan libretas de direcciones individuales y tienen poca información compartida entre las aplicaciones de los datos de las libretas de direcciones que cada programa mantiene de manera individual. En consecuencia, un programa de finanzas (como Microsoft Money) no comparte direcciones para los beneficiarios con las direcciones que se mantienen en una carpeta de contactos de correo electrónico (como el de Microsoft Outlook). De hecho, muchos usuarios tienen múltiples dispositivos y sincronizan de manera lógica sus datos personales entre estos y a través de una amplia variedad de fuentes adicionales, entre estos teléfonos celulares con servicios comerciales como MSN y AOL. Sin embargo, la colaboración de los documentos compartidos se logra en gran medida anexando documentos a mensajes de correo electrónico, esto es, de manera manual e ineficiente. Una razón para esta falta de colaboración es que los enfoques tradicionales a la organización de la información en sistemas de cómputo se han centrado en el uso de sistemas basados en archivo-carpeta-directorio ("sistemas de carpetas") para organizar pluralidades de archivos en jerarquías de directorios de carpeta con base en una abstracción de la organización física del medio de almacenamiento que se usa para almacenar los archivos. El sistema operativo Multics, desarrollado durante 1960, puede recibir el crédito de ser el pionero en el uso de archivos, carpetas y directorios para administrar unidades de datos que se pueden almacenar en un nivel de sistema operativo. Específicamente, Multics usaba direcciones simbólicas dentro de una jerarquía de archivos (de esta manera presentaba la idea de una ruta de archivos) en donde las direcciones físicas de los archivos no eran transparentes al usuario (aplicaciones y usuarios finales). Este sistema de archivos era completamente indiferente al formato de archivos de cualquier archivo individual y las relaciones entre los archivos se consideraban irrelevantes en el nivel de sistema operativo (esto es, diferente a la ubicación del archivo dentro de la jerarquía). Desde la llegada de Multics, los datos que se pueden almacenar se han organizado en archivos, carpetas y directorios en el nivel de sistema operativo. Estos archivos en general incluyen la jerarquía de archivos en sí mismos (el "directorio") representado en un archivo especial que se mantiene mediante el sistema de archivos. Este directorio, en su momento, mantiene una lista de entradas que corresponden a todos los otros archivos dentro del directorio y las ubicaciones nodales de dichos archivos en la jerarquía (en la presente se hace referencia a esto como carpeta). Esto se ha mantenido como el diseño de última generación durante aproximadamente cuarenta años. Sin embargo, al proveer una representación razonable de información que reside en el sistema de almacenamiento físico de la computadora, un sistema de archivos no obstante es una abstracción de dicho sistema de almacenamiento físico, y por lo tanto la utilización de los archivos requiere un nivel de interpretación entre lo que el usuario manipula (unidades que tienen contexto, características y relaciones con otras unidades) y lo que provee el sistema operativo (archivos, carpetas y directorios). En consecuencia, los usuarios (aplicaciones y/o usuarios finales) que no otra tiene opción más que forzar las unidades de información en una estructura de sistemas de archivos, incluso cuando lo hacen de una manera ineficiente, inconsistente o indeseable. Adicionalmente, los sistemas de archivos existentes saben poco sobre la estructura de los datos almacenados en los archivos individuales, y debido a esto, la mayoría de la información permanece bloqueada en archivos a los que sólo se puede tener acceso (y es comprensible) a través de las aplicaciones sobre las que se escribieron. En consecuencia, esta falta de descripción esquemática de información y mecanismos para administrar la información, conduce a la creación de silos de datos con una baja capacidad de compartir datos entre los silos individuales. Por ejemplo, muchos usuarios de computadoras personales (PC) tiene más de cinco diferentes almacenes que contienen información sobre las personas con las que interactúan en algún nivel, por ejemplo, contactos de Outlook, direcciones de una cuenta en línea, una libreta de direcciones de Windows, beneficiarios de Quicken y una lista de amigos para su mensajero instantáneo, debido a que los archivos de esta organización presentan un reto importante para los usuarios de una computadora personal. Debido a que la mayoría de los sistemas de archivos existentes utilizan una metáfora de carpetas alojadas para organizar archivos y carpetas, como el número de archivos aumenta, el esfuerzo necesario para mantener un esquema de organización que sea flexible y eficiente se convierte en un asunto desalentador. En situaciones como ésta, sería muy útil contar con diversas clasificaciones para un solo archivo; sin embargo, es difícil y complicado mantener el uso de enlaces físicos o enlaces lógicos en los sistemas de archivos existentes. En el pasado se han realizado diversos intentos para solucionar los inconvenientes de estos sistemas de archivos que no han tenido un resultado satisfactorio. Algunos de estos intentos anteriores han involucrado el uso de una memoria que está dirigida al contenido para proveer un mecanismo en donde se puede acceder a los datos a través del contenido, en lugar de una dirección física. Sin embargo, estos esfuerzos han probado que no son satisfactorios, ya que, aunque una memoria que puede dirigirse al contenido ha probado ser útil para un uso en pequeña escala por dispositivos como memorias intermedias y unidades de administración de memoria, el uso en gran escala para dispositivos como medios de almacenamiento físico no ha sido posible por diversas razones, y de esta manera, una solución como ésta no existe. Se han hecho otros intentos que usan sistemas de bases de datos orientados por objetos (OODB), pero estos intentos, mientras presentan fuertes características de bases de datos y buenas representaciones que no se refieren a archivos, no son efectivos en el manejo de representaciones de archivos y no pueden replicar la velocidad, eficiencia y simplicidad de la estructura jerárquica basada en archivos y carpetas en el nivel de un sistema de interfaz de componentes físicos de computación y programas y sistemas de computación. Otros esfuerzos como los que se han intentado para el uso de SmallTalk (y otros derivados), probaron ser algo efectivos en el manejo de archivos y representaciones diferentes de archivos, pero carecieron de las características de bases de datos necesarias para organizar y utilizar de manera eficiente las relaciones que existen entre los diversos archivos de datos, y de esta manera la eficiencia general de dichos sistemas fue inaceptable. Otros intentos de usar BeOS (y otra investigación de sistemas operativos como tales) probaron ser inadecuados en el manejo de las representaciones diferentes de archivos, el mismo inconveniente central de los sistemas de archivos tradicionales, a pesar de poder representar de manera adecuada archivos mientras provee algunas características de bases de datos necesarias. La tecnología de las bases de datos es otra área en la técnica en donde existen retos similares. Por ejemplo, aunque el modelo de base de datos de relación ha sido un gran éxito comercial, entre los vendedores de programas y sistemas de computación independientes (ISV) reales generalmente ejecutan una pequeña porción de la funcionalidad disponible en los productos de programas y sistemas de programación de la base de datos relacional (por ejemplo el servidor SQL de Microsoft). En su lugar, la mayor parte de la interacción de una aplicación con un producto como tal es en la forma simple de "obtener" y "colocar". Aunque existe un número de razones evidentemente fáciles para esto, como puede ser una plataforma o una base de datos agnóstica, una razón clave que con frecuencia no se observa es que la base de datos no necesariamente provee las abstracciones exactas que necesita en realidad un vendedor de aplicaciones comerciales principal. Por ejemplo, mientras el mundo real sabe que los "elementos", como "cliente" o "solicitudes" (junto con "elementos de línea" incrustados en una solicitud como elementos dentro y de sí mismos), las bases de datos relaciónales sólo se refieren a tablas y filas. En consecuencia, aunque la aplicación pueda desear tener aspectos de consistencia, bloqueo, seguridad y/o se active en el nivel de elemento (por nombrar alguno), las bases de datos en general proporcionan estas características sólo en un nivel de tabla/ fila. Aunque esto puede funcionar bien si cada elemento se correlaciona con una sola fila en una tabla en la base de datos, en el caso de una solicitud con múltiples elementos en la línea puede haber razones con un elemento que se correlaciona realmente con diversas tablas y, cuando éste es el caso, el sistema de base de datos relaciónales simples no proporciona las abstracciones correctas. En consecuencia, una aplicación debe construir una lógica en la parte superior de la base de datos para proveer estas abstracciones lógicas. En otras palabras, el modelo relacional básico no provee una plataforma suficiente para el almacenamiento de datos en los que las aplicaciones de niveles superiores pueden desarrollarse fácilmente debido a que el modelo relacional básico requiere un nivel indirecto entre la aplicación y el sistema de almacenamiento, en donde la estructura semántica de los datos sólo puede ser visible en la aplicación en algunas circunstancias. Aunque algunos vendedores de bases de datos están consiguiendo un nivel superior de funcionalidad en sus productos, por ejemplo al proveer capacidades relaciónales de objetos, los nuevos modelos organizacionales y similares, ninguno ha logrado proveer la clase de solución completa necesaria, en donde una solución completa real es la que proporciona tanto abstracciones de modelo de datos útiles (por ejemplo "elemento", "extensiones", "relaciones", etc.) para abstracciones de dominio útil (por ejemplo "persona", "ubicaciones", "evento", etc.). En vista de las deficiencias mencionadas en el almacenamiento de datos existentes y en la tecnología de bases de datos, existe la necesidad de una nueva plataforma de almacenamiento que provea una capacidad mejorada para organizar, buscar y compartir todos los tipos de datos en un sistema de cómputo, una plataforma de almacenamiento que extiende y amplía la plataforma de datos más allá de los sistemas de los archivos existentes y los sistemas de las bases de datos, y que está diseñada para almacenar todo tipo de datos. La presente invención, junto con las invenciones relacionadas incorporadas por referencia anteriormente en la presente, satisface esta necesidad. En particular, la presente invención proporciona métodos de extensiones y herencias para objetos manipulados por un sistema de interfaz de componentes físicos de computación y programas y sistemas de programación.

Sumario de la Invención La siguiente descripción breve proporciona una descripción general de diversos aspectos de la invención descrito dentro del contexto de las invenciones relacionadas incorporadas por referencia en párrafos anteriores en la presente (las "invenciones relacionadas"). Esta breve descripción no tiene la intención de proveer una descripción completa de todos los aspectos importantes de la invención, tampoco de definir el alcance de la invención. En su lugar, esta breve descripción tiene la intención de servir como una introducción a la descripción detallada y las figuras a continuación. La presente invención, así como las invenciones relacionadas, están dirigidas colectivamente a una plataforma de almacenamiento para organizar, buscar y compartir datos. La plataforma de almacenamiento de la presente invención extiende y amplía el concepto de almacenamiento de datos más allá de los sistemas de archivos existentes y los sistemas de base de datos existentes, y está diseñada para almacenar todo tipo de datos, incluyendo datos estructurados, no estructurados o semiestructurados. La plataforma de almacenamiento de la presente invención comprende un almacén de datos implementado en un motor de una base de datos. El motor de la base de datos comprende un motor de base de datos relacional con extensiones relaciónales por objeto. El almacén de datos implementa un modelo de datos que da soporte a la organización, búsqueda, compartir, sincronización y seguridad de datos. Los tipos específicos de datos se escriben en esquemas y la plataforma proporciona un mecanismo para extender el conjunto de esquemas y definir nuevos tipos de datos (esencialmente subtipos de los tipos básicos que proporcionan los esquemas). Una capacidad de sincronización facilita compartir los datos entre los usuarios de los sistemas. Las capacidades similares a un sistema de archivos se proveen y permiten la hiperoperación del almacén de datos con los sistemas de archivos existentes sin limitar dichos sistemas de archivos tradicionales. Un mecanismo de seguimiento de cambios proporciona la capacidad de dar seguimiento a los cambios en el almacén de datos. La plataforma de almacenamiento además comprende un conjunto de interfaces de programas de aplicación que permite que las aplicaciones accedan a todas las capacidades mencionadas de la plataforma de almacenamiento y para acceder a los datos descritos en los esquemas. El modelo de datos implementado por el almacén de datos define unidades del almacenamiento de datos en términos de elementos y relaciones. Un elemento es una unidad de datos que puede almacenarse en un almacén de datos y puede comprender uno o más elementos y relaciones.

Uno de estos elementos es por ejemplo un tipo que comprende uno o más campos (también denominado en la presente como propiedad). Una relación es un enlace entre dos elementos. (Como se usa en la presente, estos y otros términos específicos pueden mostrarse en mayúsculas para diferenciarlos de otros términos usados en cercanía, sin embargo, no hay intención alguna de distinguir entre un término en mayúsculas, por ejemplo "Elemento", y el mismo término cuando se muestra en minúsculas, por ejemplo "elemento", y no debe hacerse o implicar distinción alguna.) El sistema de cómputo además comprende una pluralidad de Elementos en donde cada Elemento constituye una unidad de información que puede almacenarse de manera discreta y que puede manipularse a través de un sistema de interfaz de componentes físicos de computación y programas y sistemas de programación; una pluralidad de carpetas de elementos que constituye una estructura de organización de dichos elementos; y un sistema de interfaz de componentes físicos de computación y programas y sistemas de programación para manipular una pluralidad de elementos y en donde cada elemento pertenece al menos a una carpeta de elementos y puede pertenecer a más de una carpeta de elementos. Un elemento o algunos valores de propiedad del elemento se pueden calcular de manera dinámica contrario a lo derivado de un almacén persistente. En otras palabras, el sistema de interfaz de componentes físicos de computación y programas y sistemas de programación no requiere que el elemento sea almacenado y algunas operaciones están soportadas, por ejemplo la capacidad de enumerar el conjunto actual de elementos o la capacidad de recuperar un elemento dado su identificador (que se describe con mayor precisión en las secciones que describen la interfaz de programación de la aplicación (API) de la plataforma de almacenamiento, por ejemplo, un elemento puede ser la ubicación actual de un teléfono celular o la lectura de la temperatura de en un termómetro. El sistema de interfaz de componentes físicos de computación y programas y sistemas de programación puede manipular una pluralidad de elementos y además puede comprender elementos interconectados a través de una pluralidad de relaciones manejadas a través del sistema de interfaz de componentes físicos de computación y programas y sistemas de programación. Un sistema de interfaz de componentes físicos de computación y programas y sistemas de programación para el sistema de cómputo además comprende un esquema central para definir un conjunto de elementos centrales en donde -dicho sistema de interfaz de componentes físicos de computación y programas y sistemas de programación comprende y procesa de manera directa de una manera predecible y predeterminada. Para manipular una pluralidad de elementos, el sistema de cómputo interconecta dichos elementos con una pluralidad de relaciones y administra dichas relaciones en el nivel del sistema de interfaz de componentes físicos de computación y programas y sistemas de programación. La API de la plataforma de almacenamiento proporciona las clases de datos para cada elemento, la extensión del elemento y relación definida en el conjunto de esquemas de la plataforma de almacenamiento. Además, la interfaz de programación de la aplicación proporciona un conjunto de clases de estructura principal que define un conjunto común de conducta para las clases de datos y, junto con las clases de datos proveen el modelo de programación básico para la API de la plataforma de almacenamiento. La API de la plataforma de almacenamiento proporciona un modelo de consulta simplificado que permite que los programadores de la aplicación formen consultas con base en varias propiedades de los elementos del almacén de datos, en una manera que aisla al programador de la aplicación de los detalles del lenguaje de consulta del motor de la base de datos subyacente. La API de la plataforma del almacenamiento también recolecta los cambios que se hicieron a un elemento mediante un programa de aplicación y después los organiza en las actualizaciones correctas requeridas por el motor de la base de datos (o cualquier tipo de motor de almacenamiento) en donde se implementa el almacén de datos. Esto permite que los programadores de la aplicación hagan cambios en un elemento dentro de la memoria, y dejan la complejidad de las actualizaciones del almacén de datos a la API. A través de esta fundación de almacenamiento común y datos en esquema, la plataforma de almacenamiento de la presente invención habilita un desarrollo de aplicación más eficiente para los clientes, trabajadores intelectuales y las empresas. Ofrece una interfaz de programación de la aplicación rica y extensible que no sólo pone disponibles las capacidades inherentes en este modelo de datos, también involucra y extiende el sistema de archivos existentes y los métodos de acceso a la base de datos. Dentro de la visión de esta estructura general de las invenciones interreiacionadas (descritas detalladamente en la sección II de la descripción detallada), la presente invención está dirigida específicamente al uso de extensiones para extender la funcionalidad del elemento y los tipos de propiedades, así como al uso de la herencia para facilitar la organización y compartir de una manera eficiente entre los elementos relacionados (descritos con detalle en la sección III de la descripción detallada). Otras características y utilidades de la invención serán evidentes a partir de la siguiente descripción detallada de la invención y los dibujos anexos. Breve Descripción de las Figuras La breve descripción mencionada, así como la siguiente descripción detallada de la invención se comprende de mejor manera al leerse en conjunto con los dibujos anexos. Con el objetivo de ¡lustrar la invención, se muestra en los dibujos modalidades ejemplares de diversos aspectos de la invención; sin embargo, la invención no está limitada los métodos específicos y a las modalidades descritas. En los dibujos: La figura 1 es un diagrama de bloques que representa un sistema de cómputo en donde los aspectos de la presente invención pueden incorporarse; La figura 2 es un diagrama de bloques que ilustra un sistema de cómputo dividido en tres grupos de componentes: el componente de ios componentes físicos de computación, el componente del sistema de interfaz de los componentes físicos de computación y programas y sistemas de programación, y el componente de programas de la aplicación; La figura 2A ilustra la estructura jerárquica basada en árbol tradicional para los archivos agrupados en carpetas en un directorio en un sistema operativo basado en archivos; La figura 3 es un diagrama de bloques que ilustra una plataforma de almacenamiento; La figura 4 ilustra la relación estructural entre los elementos, las carpetas de los elementos y sus categorías; La figura 5A es un diagrama de bloques que ilustra la estructura de un elemento; La figura 5B es un diagrama de bloques que ilustra los tipos de propiedad complejas de un elemento de la figura 5A; La figura 5C es un diagrama de bloques que ¡lustra el elemento de "ubicación" en donde sus tipos complejos se describen adicionalmente (se enumeran explícitamente); La figura 6A ilustra un elemento como un su tipo de un elemento que se encuentra en el esquema base; La figura 6B es un diagrama de bloques que ilustra el elemento de su tipo de la figura 6A en donde sus tipos heredados se enumeran explícitamente (además de sus propiedades inmediatas); La figura 7 es un diagrama de bloques que ilustra el esquema base que incluye sus dos tipos de clases de nivel superior, el elemento y la propiedad base (Item y PropertyBase) y los tipos de esquema base adicionales derivados de estos; La figura 8A es un diagrama de bloques que ilustra los elementos en el esquema central; La figura 8B es un diagrama de bloques que ilustra los tipos de propiedad en el esquema central; La figura 9 es un diagrama de bloques que ilustra una carpeta del elemento, sus elementos miembros y las relaciones de interconexión entre la carpeta del elemento y sus elementos miembros; La figura 10 es un diagrama de bloques que ilustra una categoría (la cual, nuevamente, es un elemento en sí mismo), sus elementos miembros y las relaciones de interconexión entre la categoría y sus elementos miembros; La figura 11 es un diagrama que ilustra una jerarquía del tipo de referencia del modelo de datos de la plataforma de almacenamiento; La figura 12 es un diagrama que ilustra la manera en que se clasifican las relaciones; La figura 13 es un diagrama que ilustra un mecanismo de notificación; La figura 14 es un diagrama que ilustra un ejemplo en donde dos transacciones insertan un nuevo registro en el mismo árbol B; La figura 15 ilustra un proceso de detección de cambio de datos; La figura 16 ilustra un árbol del directorio ejemplar; La figura 17 muestra un ejemplo en donde una carpeta existente de un sistema de archivos basado en un directorio se mueve en el almacén de datos de la plataforma de almacenamiento; La figura 18 ilustra el concepto de las carpetas de contención; La figura 19 ilustra la arquitectura básica de la API de la plataforma de almacenamiento; La figura 20 representa esquemáticamente los diversos componentes de la pila de API de la plataforma de almacenamiento; La figura 21A es una representación pictórica de un esquema de elementos de contacto ejemplar; La figura 21B es una representación pictórica de los elementos para el esquema de elementos de contactos ejemplar de la figura 21A; La figura 22 ilustra la estructura del tiempo de ejecución de la API de la plataforma de almacenamiento; La figura 23 ilustra la ejecución de una operación para buscar todo (FindAIl); La figura 24 ilustra el proceso mediante el cual las clases de la API de la plataforma de almacenamiento se generan desde el esquema de la plataforma de almacenamiento; La figura 25 ¡lustra un esquema en el que se basa un archivo de la API; La figura 26 es un diagrama que ilustra un formato de máscara de acceso que se usa para objetivos de seguridad de los datos; La figura 27 (partes a, b y c) ¡lustra una región de seguridad protegida de manera idéntica forjada de una región de seguridad existente; La figura 28 es un diagrama que ilustra el concepto de un formulario de búsqueda de un elemento; La figura 29 es un diagrama que ilustra una jerarquía de elementos ejemplar; La figura 30A ilustra una interfaz "interfaz 1" como un conducto a través del cual se comunican los segmentos del código primero y segundo; La figura 30B ilustra una interfaz que comprende los objetos de interfaz 11 y 12 que permiten que los segmentos de código primero y segundo de un sistema se comuniquen a través del medio M; La figura 31A ilustra la manera en que la función provista por la interfaz "interfaz 1" se puede subdividir para convertir las comunicaciones de la interfaz en interfaces múltiples, interfaz A, interfaz 1B, interfaz 1C; La figura 31B ilustra la manera en que la función provista por la interfaz 11 se puede subdividir en múltiples interfaces HA, I1B, I1C; La figura 32A ilustra una situación en donde la precisión del parámetro sin significado se puede ignorar al reemplazar con un parámetro arbitrario; La figura 32b ilustra una situación en donde una interfaz se reemplaza a través de una interfaz sustituto que se define para ignorar o añadir parámetros a una interfaz; La figura 33A ¡lustra una situación en donde los segmentos del código primero y segundo se fusionan en un módulo que los contiene a ambos; La figura 33B ilustra una situación en donde una parte o toda una interfaz se puede escribir en línea en otra interfaz para formar una interfaz fusionada; La figura 34A ilustra la manera en que una o más piezas de la programación intermedia puede convertir las comunicaciones en la primera interfaz para que se ajuste a una o más interfaces diferentes; La figura 34B ilustra la manera en que un segmento de código se puede introducir con una interfaz para recibir comunicaciones de una interfaz, y transmitir la funcionalidad a una segunda y a una tercera interfaces; La figura 35A ilustra la manera en que un compilador justo a tiempo (JIT) puede convertir las comunicaciones de un segmento de código a otro segmento de código; La figura 35B ilustra un método JIT para volver a escribir de manera dinámica una o más interfaces que se puede aplicar a un factor dinámico o de otra manera modificar dicha interfaz; La figura 36 ilustra una serie de elementos interrelacionados y un subconjunto de sus relaciones; La figura 37A ilustra el inconveniente de la subclasificación estándar de un elemento para objetivos específicos de la aplicación; La figura 37B ¡lustra una solución parcial a los problemas de la subclasificación estándar; y La figura 37C ilustra una modalidad de la presente invención para extender un elemento con una extensión que es diferente y separada del mismo contacto; y de esta manera permite una funcionalidad de clasificación múltiple. Descripción Detallada de la Invención ÍNDICE I. INTRODUCCIÓN 32 A. ENTORNO DE CÓMPUTO EJEMPLAR 33 B. ALMACENAMIENTO TRADICIONAL BASADO EN ARCHIVOS 43 II. PLATAFORMA DE ALMACENAMIENTO DE WINFS PARA ORGANIZAR, BUSCAR Y COMPARTIR DATOS 47 C. GLOSARIO 47 D. DESCRIPCIÓN GENERAL DE LA PLATAFORMA DE ALMACENAMIENTO 49 E. MODELO DE DATOS 53 1. Elementos 56 2. Identificación de elementos 54 3. Carpetas y categorías del elemento 55 4. Esquemas 69 a) Esquema base 69 b) Esquema central 71 . Relaciones 75 a) Declaración de relación 77 b) Relaciones de propiedad 79 c) Relaciones de incrustación 81 d) Relaciones de referencia 83 e) Reglas y restricciones 84 f) Orden de las relaciones 85 6. Capacidad de extensión 96 a) Extensiones del elemento 98 b) Extensión de los tipos de elementos anidados ....104 MOTOR DE LA BASE DE DATOS 106 1. Impiementación del almacén de datos usando UDT 109 2. Correlación de elementos 111 3. Correlación de extensiones 113 4. Correlación de elementos anidados 114 . Identidad del objeto 114 6. Denominación de objetos de SQL 115 7. Denominación de columnas 116 8. Formularios de búsqueda 117 a) Elemento 119 (1) Formulario maestro de búsqueda de elementos 119 (2) Formularios de búsqueda de elementos por tipo 120 b) Extensiones del elemento 121 (1) Formulario maestro de búsqueda de extensiones 121 (2) Formularios de búsqueda de extensión por tipo 122 c) Elementos anidados 122 d) Relaciones 123 (1) Formulario maestro de búsqueda de relaciones 123 (2) Formularios de búsqueda de instancias de relación 123 e) 124 9. Actualizaciones 124 . Seguimiento de cambios y lápidas 126 a) Seguimiento de cambios 126 (1) Seguimiento de cambios en formularios "maestros"de búsqueda 127 (2) Seguimiento de cambios en formularios de búsqueda "por tipo" 128 b) Lápidas 129 (1) Lápidas de elementos 129 (2) Lápidas de extensiones 130 (3) Lápida de relaciones 131 (4) Limpieza de lápidas 132 11. Funciones e interfaces de programas de aplicación (API) de ayuda 132 a) Función [System. Storage].Getltem 133 b) Función [System. Storage].GetExtension 133 c) Función [System. Storage].GetRelationship 133 12. Metadatos 133 a) Metadatos de esquemas 134 b) Metadatos de instancias 134 SEGURIDAD 134 SEGUIMIENTOS DE CAMBIOS Y NOTIFICACIONES.. 136 SINCRONIZACIÓN 137 1. Sincronización de plataforma de almacenamiento - Plataforma de almacenamiento 138 a) Aplicaciones de control de sincronización (Sync) 140 b) Anotación de esquemas 141 c) Configuración de sincronización (Sync) 143 (1) Correlaciones de las carpetas de comunidad.. 144 (2) Perfiles 146 (3) Programaciones 148 d) Manejo de conflictos 149 (1) Detección de conflictos 149 (a) Conflictos basados en conocimientos 149 (b) Conflictos basados en restricciones 150 (2) Procesamiento de conflictos 151 (a) Resolución automática de conflictos 152 (b) Registro de conflictos 154 (c) Inspección y resolución de conflictos 154 (d) Convergencia de réplicas y propagación de resoluciones de conflictos 155 2. Sincronización de almacenes de datos diferentes de la plataforma de almacenamiento 156 a) Servicios de sincronización 157 (1) Enumeración de cambios 158 (2) Aplicación de cambios 160 (3) Resolución de conflictos 161 b) Implementación del adaptador 161 3. Seguridad 162 4. Capacidad dé gestión 163 J. INTEROPERABILIDAD CON EL SISTEMA DE ARCHIVOS TRADICIONAL 16 K. INTERFACES DE PROGRAMAS DE APLICACIÓN DE LA PLATAFORMA DE ALMACENAMIENTO 166 III. EXTENSIONES Y HERENCIA 180 A. TIPOS DE SISTEMAS 182 B. TIPOS DE FAMILIAS 190 1. Tipos de elementos anidados 190 2. Tipos de elementos 191 3. Tipos de relaciones 192 a) Semántica de las relaciones 194 b) Reglas y restricciones de las relaciones 198 4. Tipos de extensiones 200 C. FUNCIONALIDAD MEJORADA 202 1. Herencia 202 2. Extensiones 204 IV. CONCLUSIÓN 205 I. INTRODUCCIÓN La materia de objeto de la presente invención se describe de manera específica para cubrir los requerimientos establecidos por ley. Sin embargo, la descripción en sí misma no tiene la intención de limitar el alcance de esta patente. En su lugar, los inventores han contemplado que la materia que se reclama también se puede representar de otras maneras, para que incluya diferentes pasos o combinaciones de pasos, similares a los descritos en este documento, en conjunto con otras tecnologías presentes o futuras. Adicionalmente, aunque el término "paso" se puede usar en la presente para connotar diferentes elementos de los métodos que se emplean, el término no debe interpretarse con una implicación de un orden particular entre varios pasos descritos en la presente a menos y con la excepción de que el orden de los pasos individuales se describa de manera explícita.

A. ENTORNO DE CÓMPUTO EJEMPLAR Diversas modalidades de la presente invención se pueden ejecutar en una computadora. La figura 1 y el análisis a continuación tienen la intención de proveer una descripción breve y general de un entorno de cómputo adecuado en donde la invención se puede implementar. Aunque no se requiere, diversos aspectos de la invención se pueden describir en el contexto general de las instrucciones ejecutables a través de una computadora, por ejemplo módulos de programa, ejecutados por una computadora, como estaciones de trabajo cliente o un servidor. En general, los módulos de programa incluyen rutinas, programas, objetos, componentes, estructuras de datos y similares que realizan tareas particulares o implementan tipos de datos abstractos. Adicionalmente, la invención se puede practicar con otras configuraciones de sistemas de cómputo, incluyendo dispositivos portátiles, sistemas con procesadores múltiples, aparatos electrónicos programables por el consumidor o basados en microprocesadores, computadoras personales conectadas en red, minicomputadoras, computadoras de estructura principal y similares. La invención también se puede practicar en entornos de cómputo distribuido, en donde las tareas se realizan a través de dispositivos de procesamiento remoto que se enlazan a través de una red de comunicaciones. En un entorno de cómputo distribuido, los módulos de programa se pueden ubicar en dispositivos de almacenamiento de memoria local o remota. Como se muestra en la figura 1, un sistema de cómputo de objetivo general ejemplar incluye una computadora personal 20 convencional o similar, que incluye una unidad de procesamiento 21, una memoria del sistema 22 y una barra de distribución del sistema 23 que acopla varios componentes del sistema, incluyendo la memoria del sistema a la unidad de procesamiento 21. La barra de distribución del sistema 23 puede ser cualquiera de diversos tipos de estructuras de barras de distribución, incluyendo una barra de distribución de memoria o controlador de memoria, una barra de distribución periférica y una barra de distribución local que usa cualquiera de una variedad de arquitecturas. La memoria del sistema incluye una memoria de sólo lectura (ROM) 24 y una memoria de acceso aleatorio (RAM) 25. Un sistema básico de entradas y salidas (BIOS) 26, que contiene las rutinas básicas que ayudan a transferir información entre los elementos dentro de una computadora personal 20, por ejemplo durante el arranque, que se almacena en la memoria de sólo lectura (ROM) 24. La computadora personal 20 además puede incluir una unidad de disco duro 27 para leer y escribir en un disco duro, no se muestra, una unidad de disco magnético 28 para leer o escribir en un disco magnético extraíble 29, y una unidad de disco óptico 30 para leer o escribir en un disco óptico extraíble 31, por ejemplo un CD-ROM u otro medio óptico. La unidad de disco duro 27, la unidad de disco magnético 28 y la unidad de disco óptico 30 se conectan a la barra de distribución del sistema 23 a través de una interfaz de disco duro 32, una interfaz de unidad de disco magnético 33 y una interfaz de unidad óptica 34, respectivamente. Las unidades y sus medios legibles a través de una computadora asociados proporcionan un almacenamiento permanente de las instrucciones legibles a través de una computadora, estructuras de datos, módulos de programas y otros datos de la computadora personal 20. Aunque el entorno ejemplar que se describe en la presente emplea una unidad de disco duro, un disco magnético extraíble 29 y un disco óptico extraíble 31, debe ser evidente para los expertos en la técnica que otros tipos de medios legibles por computadora que puedan almacenar datos accesibles a través de una computadora, como casetes magnéticos, tarjetas de memoria intermedia, discos de video digital, cartuchos de Bernoulli, memorias de acceso aleatorio (RAM), memorias de sólo lectura (ROM) y similares también se pueden usar en el entorno operativo ejemplar. De igual manera, el entorno operativo ejemplar también puede incluir muchos tipos de dispositivos de supervisión como sensores de calor y sistemas de alarma de seguridad o de fuego, y otras fuentes de información.

Diversos módulos de programa se pueden almacenar en el disco duro, en el disco magnético 29, en el disco óptico 31, en la ROM 24 o en la RAM 25, incluyendo un sistema operativo 35, uno o más programas de aplicación 36, otros módulos de programa 37 y datos de programa 38. Un usuario puede introducir comandos e información en la computadora personal 20 a través de dispositivos de entrada como un teclado 40 o un dispositivo puntero 42. Otros dispositivos de entrada (no se muestran) pueden incluir un micrófono, una palanca de mando, una almohadilla de juegos, una antena parabólica, un digitalizador o similar. Estos y otros dispositivos de entrada con frecuencia se conectan a la unidad de procesamiento 21 a través de una interfaz 46 de un puerto en serie que se acopla a la barra de distribución del sistema, pero puede estar conectado a través de otras interfaces, por ejemplo un puerto paralelo, un puerto de juegos o una barra de distribución en serie universal (USB). Un monitor 47 u otro tipo de dispositivo de visualización también se conecta a la barra de distribución del sistema 23 a través de una interfaz, por ejemplo un adaptador de video 48. Además del monitor 47, las computadoras personales típicamente incluyen otros dispositivos de salida periférica (no se muestran), por ejemplo altavoces e impresoras. El sistema ejemplar de la figura 1, también incluye un adaptador principal 55, una barra de distribución e interfaz del sistema de cómputo pequeño (SCSI) 56, y un dispositivo de almacenamiento externo 52 conectado a la barra de distribución SCSI 56. La computadora personal 20 puede funcionar en un entorno conectado en red usando conexiones lógicas a una o más computadoras remotas, por ejemplo una computadora remota 49. La computadora remota 49 puede ser otra computadora personal como un servidor, un enrutador, una computadora personal en red, un dispositivo cliente u otro nodo de red común, y típicamente incluye varios o todos los elementos descritos anteriormente con relación a la computadora personal, aunque sólo un dispositivo de almacenamiento de memoria 50 se ha ilustrado en la figura 1. Las conexiones lógicas que se ilustran en la figura 1 incluyen una red de área local (LAN) 51 y una red de área extensa (WAN) 52, dichos entornos conectados en red son lugares comunes en oficinas, en redes de cómputo de toda una empresa, redes internas así como en Internet. Cuando se usa en un entorno conectado en red en una red de área local, la computadora personal 20 se conecta a la red de área local 51 a través de una interfaz de red o adaptador 53. Cuando se usa en un entorno conectado en red en una red de área extensa, la computadora personal 20 típicamente incluye un módem 54 u otros medios para establecer comunicaciones sobre la red de área extensa 52, por ejemplo Internet. El módem 54, que puede ser interno o externo, se conecta a la barra de distribución del sistema 23 a través de una interfaz de un puerto en serie 46. En un entorno conectado en red, los módulos de programa que se ilustran con relación a la computadora personal 20, o porciones de ésta, se pueden almacenar en el dispositivo de almacenamiento de memoria remota. Será evidente que las conexiones en red que se muestran son ejemplares y que otros medios para establecer un enlace de comunicación entre las computadoras también se pueden usar. Como se ilustra en el diagrama de bloques de la figura 2, un sistema de cómputo 200 se puede dividir a groso modo en tres grupos de componentes: el componente de los componentes físicos de computación 202, el componente del sistema de la interfaz de componentes físicos de computación y programas y sistemas de programación 204 y el componente de programas de aplicaciones 206 (también denominado como el "componente del usuario" o "componente de programas y sistemas de programación" en algunos contextos de la presente). En diversas modalidades de un sistema de cómputo 200 haciendo referencia nuevamente a la figura 1, el componente de los componentes físicos de computación 202 puede comprender la unidad de procesamiento central (CPU) 21, la memoria (tanto la memoria de sólo lectura 24, como la memoria de acceso aleatorio 25), el sistema básico de entradas y salidas (BIOS) 26, y diversos dispositivos de entradas/ salidas (1/ O) como un teclado 40, un ratón 42, un monitor 47 y/o una impresora (no se muestra), entre otras cosas. El componte de los componentes físicos de computación 202 comprende la infraestructura física básica para el sistema de cómputo 200. El componente 206 de los programas de aplicaciones comprende varios programas de programas y sistemas de programación que incluyen sin limitarse a esto, compiladores, sistemas de bases de datos, procesadores de palabras, programas de negocios, videojuegos, etc. Los programas de aplicación proporcionan los medios mediante los cuales los recursos de la computadora se utilizan para resolver problemas, proveer soluciones y procesar datos para diversos usuarios (máquinas, otros sistemas de cómputo, y/o usuarios finales). El componente 204 del sistema de interfaz de los componentes físicos de computación y programas y sistemas de programación comprende (y, en algunas modalidades, puede consistir únicamente de) un sistema operativo que en sí mismo comprende, en la mayoría de los casos, una cubierta y un núcleo. Un "sistema operativo" (OS) es un programa especial que actúa como un intermediario entre los programas de aplicación y los componentes físicos de computación de la computadora. El componente 204 del sistema de interfaz de los componentes físicos de computación y de programas y sistemas de programación también pueden comprender un administrador de máquina virtual (VMM), un tiempo de ejecución de lenguaje común (CLR) o su equivalente funcional, una máquina virtual Java (JVM) o su equivalente funcional, u otro componente de programas y sistemas de programación en lugar de o además del sistema operativo en un sistema de cómputo. El objetivo de un sistema de interfaz de los componentes físicos de computación y los programas y sistemas de programación es proveer un entorno en donde un usuario pueda ejecutar programas de aplicación. El objetivo de cualquier sistema de interfaz de los componentes físicos de computación y los programas y sistemas de programación es hacer un uso cómodo del sistema de cómputo, así como utilizar los componentes físicos de cómputo de una manera eficiente. El sistema de interfaz de los componentes físicos de computación y los programas y sistemas de programación generalmente se cargan en un sistema de cómputo al inicio y después se administra todos los programas de aplicación en el sistema de cómputo. Los programas de aplicación interactúan con el sistema de interfaz de los componentes físicos de computación y los programas y sistemas de programación al solicitar los servicios a través de una interfaz del programa de aplicación (API). Algunos programas de aplicación permiten que los usuarios finales interactúen con el sistema de interfaz de los componentes físicos de computación y los programas y sistemas de programación a través de una interfaz de usuario como una interfaz de lenguaje de comandos o una interfaz gráfica del usuario (GUI). Un sistema de interfaz de los componentes físicos de computación y los programas y sistemas de programación tradicionalmente realizan una variedad de servicios para las aplicaciones. En un sistema de interfaz de los componentes físicos de computación y programas y sistemas de programación de tareas múltiples en donde diversos programas se pueden ejecutar al mismo tiempo, el sistema de interfaz de los componentes físicos de computación y programas y sistemas de programación determina qué aplicaciones deben ejecutarse en qué orden y cuánto tiempo se debe permitir a cada aplicación antes de cambiar a cada aplicación para que tome su turno. El sistema de interfaz de los componentes físicos de computación y los programas y sistemas de programación también administran la manera de compartir la memoria interna entre múltiples aplicaciones y maneja la entrada y salida hacia y desde los dispositivos de los componentes físicos de computación anexados como discos duros, impresoras, puertos de marcación. El sistema de interfaz de los componentes físicos de computación y los programas y sistemas de programación también envían mensajes a cada aplicación (y, en algunos casos, al usuario final) observando el estado de las operaciones y los errores que pueden haberse presentado. El sistema de interfaz de los componentes físicos de computación y los programas y sistemas de programación también puede descargar la administración de las tareas en lote (por ejemplo, la impresión) de manera que la aplicación que inicia se libera de este trabajo y puede reanudar otro proceso y/o operaciones. Las computadoras que pueden proveer un procesamiento paralelo, un sistema de interfaz de los componentes físicos de computación y los programas y sistemas de programación también administran la división de un programa de manera que se ejecuta en más de un procesador a la vez. Una cubierta del sistema de interfaz de los componentes físicos de computación y los programas y sistemas de programación (denominada simplemente en la presente como "cubierta") es una interfaz interactiva del usuario final con un sistema de interfaz de los componentes físicos de computación y los programas y sistemas de programación (una cubierta también se puede denominar como un "intérprete de comando" o, en un sistema operativo, una "cubierta del sistema operativo"). Una cubierta es la capa externa del sistema de interfaz de los componentes físicos de computación y los programas y sistemas de programación que se puede tener acceso directamente a través de los programas de la aplicación y/o los usuarios finales. En contraste a una cubierta, un núcleo es una capa interna del sistema de interfaz y los componentes físicos de computación y los programas y sistemas de programación que interactúan directamente con los componentes físicos de computación. Aunque se prevé que diversas modalidades de la presente invención estén bien adecuadas para los sistemas computarizados, nada de este documento tiene la intención de limitar la invención a dichas modalidades. Por el contrario, como se usa en la presente, el término "sistema de cómputo" tiene la intención de incluir cualquiera y todos los dispositivos capaces de almacenar y procesar información y/o capaces de usar la información almacenada para controlar la conducta o la ejecución del dispositivo en sí mismo, sin tomar en cuenta si dichos dispositivos son electrónicos, mecánicos, lógicos o virtuales por naturaleza. B. ALMACENAMIENTO TRADICIONAL BASADO EN ARCHIVOS En la mayoría de los sistemas de cómputo actualmente, los "archivos" son unidades de información que pueden incluir el sistema de interfaz de componentes físicos de computación y programas y sistemas de programación, así como programas de aplicación, conjuntos de datos, etc. En todos los sistemas de interfaz de componentes físicos de computación y programas y sistemas de programación modernos (Windows, Unix, Linux, Macintosh, sistemas de máquinas virtuales, etc.), los archivos son unidades de información básica discretas (que pueden almacenarse y recuperarse), por ejemplo, datos, programas, etc. que se pueden manipular a través del sistema de interfaz de los componentes físicos de computación y los programas y sistemas de programación. Los grupos de archivos generalmente se organizan "carpetas". En Microsoft Windows, en el sistema operativo de Macintosh, y otros sistemas de interfaz de los componentes físicos de computación y de programas y sistemas de programación, una carpeta es una colección de archivos que se pueden recuperar, mover y de otra manera manipular como unidades únicas de información. Estas carpetas, en su momento, se organizan en una disposición jerárquica basada en un árbol denominada "directorio" (que se analiza con mayor detalle en la presente en párrafos posteriores). En algunos otros sistemas de interfaz de componentes físicos de computación y programas y sistemas de programación, por ejemplo DOS, z/OS y la mayoría de los sistemas operativos que se basan en Unix, los términos "directorio" y/o "carpeta" son intercambiables, y en los primeros sistemas de cómputo Apple (por ejemplo, el sistema Apple No. lie) usaba el término "catálogo" en lugar de directorio; sin embargo, como se usa en la presente, todos estos términos se consideran sinónimos y son intercambiables y tienen la intención de incluir todos los términos equivalentes y las referencias a las estructuras de almacenamiento de información jerárquica y sus componentes de carpetas y archivos. Tradicionalmente, un directorio (es decir un directorio de carpetas) es una estructura jerárquica basada en árbol, en donde los archivos se agrupan en carpetas y las carpetas, en su momento, se disponen de conformidad con las ubicaciones nodales relativas que comprenden el árbol del directorio. Por ejemplo, como se ilustra en la figura 2, una carpeta basada en un sistema de archivos que se basa en DOS (o "directorio de raíz") 212, puede comprender una pluralidad de carpetas 214, cada una de las cuales además puede comprender carpetas adicionales (como "subcarpetas" de esa carpeta particular) 216, y cada una de estas también puede comprender carpetas adicionales 218 de manera infinita. Cada una de estas carpetas puede tener uno o más archivos 220, aunque, en el nivel de sistema de interfaz de los componentes físicos de computación y los programas y sistemas de programación, los archivos individuales de una carpeta no tienen nada en común además de su ubicación en la jerarquía de árbol. No es de sorprenderse que este enfoque de organización de archivos en jerarquías de carpetas refleja de manera indirecta la organización física de los medios de almacenamiento típico que se usa para almacenar estos archivos (por ejemplo, discos duros, discos flexibles, CD-ROM, etc.). Además de lo anterior, cada carpeta es un contenedor de sus subcarpetas y sus archivos, esto es, cada carpeta contiene sus propias subcarpetas y archivos. Por ejemplo, cuando una carpeta se borra a través del sistema de interfaz de los componentes físicos de computación y los programas y sistemas de programación, dichas subcarpetas de la carpeta y sus archivos también se borran (lo que, en el caso de cada subcarpeta, nada más incluye sus propias subcarpetas y archivos de manera recurrente). De igual manera, cada archivo pertenece generalmente sólo a una carpeta y, aunque una carpeta se pueda copiar y la copia se ubique en una carpeta diferente, la copia de un archivo es en sí misma una unidad diferente y separada que no tiene una conexión directa con el original (por ejemplo, los cambios en el archivo original no se reflejan en el archivo de copia y en el nivel del sistema de interfaz de los componentes físicos de computación y los programas y sistemas de programación). A este respecto, los archivos y las carpetas por lo tanto son característicamente "físicos" en naturaleza, ya que las carpetas son los contenedores físicos y los archivos reciben un trato de elementos discretos físicos separados dentro de estos contenedores.

II. PLATAFORMA DE ALMACENAMIENTO DE WINFS PARA ORGANIZAR, BUSCAR Y COMPARTIR DATOS La presente invención, en conjunto con las invenciones relacionadas incorporadas a la presente por referencia como se analizaron anteriormente en la presente está dirigida a una plataforma de almacenamiento para organizar, buscar y compartir datos. La plataforma de almacenamiento de la presente invención extiende y amplía la plataforma de datos más allá de los tipos de los sistemas de archivos existentes y los sistemas de bases de datos analizados anteriormente, y está diseñada para que sea el almacén de todos los tipos de datos, incluyendo nuevas formas de datos denominados elementos. C. GLOSARIO Como se usa en la presente y en las reivindicaciones, los siguientes términos tienen los siguientes significados: • Un "elemento" es una unidad de información que puede almacenarse a la que se puede tener acceso a través de un sistema de interfaz de los componentes físicos de computación y programas y sistemas de programación que, a diferencia de un archivo simple, es un objeto que tiene un conjunto básico de propiedades que están soportadas de manera común a través de todos los objetos expuestos para un usuario final a través de la cubierta del sistema de interfaz de los componentes físicos de computación y los programas y sistemas de programación. Los elementos también tienen propiedades y relaciones que están soportadas comúnmente a través de todos los tipos de elementos que incluyen características que permiten la introducción de nuevas propiedades y relaciones (como se analiza con mayor detalle posteriormente en la presente). • Un "sistema operativo" (OS) es un programa especial que actúa como un intermediario entre los programas de aplicación y componentes físicos de computación. Un sistema operativo comprende, en la mayoría de los casos, una cubierta y un núcleo. • Un sistema de interfaz de los componentes físicos de computación y de programas y sistemas de programación" es una combinación de programas y sistemas de programación o una combinación de los programas y sistemas de programación y los componentes físicos de computación, que funciona como la interfaz entre los componentes físicos de computación subyacentes de un sistema de cómputo y las aplicaciones que se ejecutan en el sistema de cómputo. Un sistema de interfaz de los componentes físicos de computación y los programas y sistemas de programación comprenden típicamente (y, en algunas modalidades, únicamente pueden consistir en) un sistema operativo. Un sistema de interfaz de los componentes físicos de computación y de programas y sistemas de programación también pueden comprender un administrador de máquina virtual (VMM), un tiempo de ejecución de lenguaje común (CLR) o su equivalente funcional, una máquina virtual Java (JVM) o su equivalente funcional, u otros componentes de programas y sistemas de programación tales o además del sistema operativo en un sistema de cómputo. El objetivo del sistema de interfaz de los componentes físicos de computación y los programas y sistemas de programación es proveer un entorno en donde un usuario pueda ejecutar programas de aplicación. El objetivo de cualquier sistema de interfaz de componentes físicos de computación y programas y sistemas de programación es hacer que el sistema de cómputo sea cómodo en su uso, así como utilizar los componentes de cómputo de una manera eficiente. D. DESCRIPCIÓN GENERAL DE LA PLATAFORMA DE ALMACENAMIENTO Haciendo referencia a la figura 3, una plataforma de almacenamiento 300, comprende un almacén de datos 302 ¡mplementado en un motor de una base de datos 314. En una modalidad, el motor de la base de datos comprende un motor de base de datos de relación con extensiones relaciónales de objeto. En una modalidad, el motor 314 de la base de datos relacional comprende el motor de base de datos relaciona! del servidor SQL de Microsoft. El almacén de datos 302 implementa un modelo de datos 304 que soporta la organización, búsqueda, asignación múltiple, sincronización y seguridad de los datos. Los tipos específicos de los datos se describen en esquemas, como los esquemas 340 y la plataforma de almacenamiento 300 proporcionan herramientas 346 para desplegar los esquemas así como para extender esos esquemas, como se describe con mayor detalle a continuación. Un mecanismo de seguimiento de cambios 306 que se implementa dentro del almacén de datos 302 proporciona la capacidad de dar seguimiento a los cambios en el almacén de datos. El almacén de datos 302 también proporciona capacidades de seguridad 308 y una capacidad de promoción/ degradación 310, ambos de éstos se analizan con mayor detalle a continuación, el almacén de datos 302 también proporciona un conjunto de interfaces de programación de la aplicación 312 para exponer las capacidades del almacén de datos 302 a otros componentes de la plataforma de almacenamiento y programas de aplicación (por ejemplo, los programas de aplicación 350a, 350b y 350c) que utilizan la plataforma de almacenamiento. La plataforma de almacenamiento de la presente invención adicionalmente comprende interfaces de programación de aplicación (API) 322, que habilita los programas de aplicación, por ejemplo los programas de aplicación 350a, 350b y 350c, para acceder a todas las capacidades anteriores de la plataforma de almacenamiento y para acceder a los datos descritos en los esquemas. La plataforma de almacenamiento de la API 322 se puede usar a través de los programas de aplicación en combinación con otras API, por ejemplo la API de la OLEDB 324 y la API de Win32 de Microsoft Windows. La plataforma de almacenamiento 300 de la presente invención puede proveer una variedad de servicios 328 a los programas de aplicación, incluyendo un servicio de sincronización 330 que facilita compartir los datos de entre usuarios o sistemas, por ejemplo el servicio de sincronización 330 puede habilitar la interoperabilidad con otros almacenes de datos 340 que tengan el mismo formato que el almacén de datos 302, así como acceder a almacenes de datos 342 que tienen otros formatos. La plataforma de almacenamiento 300 también provee capacidades del sistema de archivos que permiten la interoperabilidad del almacén de datos 302 con los sistemas de archivos existentes, por ejemplo el sistema de archivos NTFS de Windows 318. En al menos algunas modalidades, la plataforma de almacenamiento 320 también puede proveer programas de aplicación con capacidades adicionales para habilitar que los datos se cumplan y para habilitar la interacción con otros sistemas. Estas capacidades se pueden representar en la forma de servicios adicionales 328, por ejemplo un servicio de un agente de información 334 y un servicio de notificación 332, así como en la forma de otras utilidades 336. Al menos en algunas modalidades, la plataforma de almacenamiento se representa en, o forma una parte integral de, el sistema de interfaz de los componentes físicos de cómputo y los programas y sistemas de programación de un sistema de cómputo. Por ejemplo, y sin limitante alguna, la plataforma de almacenamiento de la presente invención se puede representar o puede formar parte integral de un sistema operativo, un administrador de una máquina virtual (VMM), un tiempo de ejecución de lenguaje común (CLR) o su equivalente funcional, o una máquina virtual Java (JVM) o su equivalente funcional. A través de este fundamento de almacenamiento común y datos en esquemas, la plataforma de almacenamiento de la presente invención habilita un desarrollo de la aplicación más eficiente para los consumidores, trabajadores intelectuales y las empresas. Ofrece un área de superficie de programación extensible que no sólo pone disponibles las capacidades inherentes en su modelo de datos, también involucra y extiende los métodos de acceso basado en datos y sistemas de archivos existentes. En la descripción a continuación así como en algunas figuras, la plataforma de almacenamiento 300 de la presente invención se puede denominar como un "WinFS". Sin embargo, el uso de este nombre para referirse a la plataforma de almacenamiento únicamente es por comodidad de la descripción y no tiene la intención de limitarse en ningún sentido. E. MODELO DE DATOS El almacén de datos 302 de la_ plataforma de almacenamiento 300 de la presente invención implementa un modelo de datos que da soporte a la organización, búsqueda, asignación múltiple, sincronización y seguridad de los datos que residen en el almacén. En el modelo de datos de la presente invención, un "elemento" es la unidad fundamental de la información de almacenamiento. El modelo de datos proporciona un mecanismo para aclarar los elementos y las extensiones de los elementos y para establecer relaciones entre los elementos y para organizar los elementos en las carpetas de elementos y en categorías, como se describe con mayor detalle a continuación. El modelo de datos depende de dos mecanismos primitivos, Tipo y Relaciones. Los tipos son estructuras que proveen un formato que rige la forma de un ejemplo del tipo. El formato se expresa como un conjunto ordenado de propiedades. Una propiedad es un nombre para un valor o conjunto de valores de un tipo determinado. Por ejemplo, un tipo DirecciónPostalenEEUU debe tener las propiedades de calle, ciudad, código postal, estado, en donde la calle, la ciudad y el estado son del tipo de cadena y el código postal es del tipo Int32. el valor para calle puede tener múltiples valores (es decir, un conjunto de valores) lo que permite que la dirección tenga más de un valor para la propiedad Calle. El sistema define ciertos tipos primitivos que se pueden usar en la construcción de otros tipos, entre estos se incluye cadena, binario, booleano, único, doble, byte, fecha, hora, decimal y GUID. Las propiedades de un tipo se pueden definir usando cualquiera de los tipos primitivos o (con algunas restricciones que se observan a continuación) cualquiera de los tipos construidos. Por ejemplo, un tipo de ubicación se puede definir que tiene propiedades coordenadas y dirección en donde la propiedad dirección es del tipo DirecciónPostalenEEUU como se describió anteriormente. Las propiedades también pueden ser requeridas o bien opcionales. Las relaciones pueden ser declaradas y representar una correlación entre los conjuntos de ejemplos de dos tipos. Por ejemplo, puede haber una relación declarada entre el tipo de persona y el tipo de ubicación denominada Viveen, lo que define las personas que habitan en una ubicación. La relación tiene un nombre, dos puntos de extremo, a saber un punto de extremo fuente y un punto de extremo objetivo. Las relaciones también pueden tener un conjunto ordenado de propiedades. Ambos puntos de extremo, fuente y objetivo, tienen un nombre y un tipo. Por ejemplo, la relación Viveen tiene una fuente denominada ocupante del tipo de persona y un objetivo denominado Morada del tipo de ubicación y además tiene propiedades como fecha de inicio y fecha de término que indican el periodo durante el cual el ocupante habitó dicha morada. Observe que una persona puede habitar diferentes moradas con el paso del tiempo y una morada puede tener múltiples ocupantes, de manera que el lugar más seguro para colocar la fecha de inicio y fecha de término es en la misma relación. Las relaciones definen una correlación entre los ejemplos que se obligan a través de los tipos determinados como los tipos de puntos de extremo. Por ejemplo, en la relación Viveen no puede ser una relación en la que un automóvil sea un ocupante debido a que un automóvil no es una persona. El modelo de datos permite la definición de una relación del subtipo-supertipo entre los tipos. La relación subtipo-supertipo también conocida como la relación tipo de base se define de una manera tal que si el tipo A es un tipo de base de tipo B será el caso en que todos los ejemplos de bebé también sean un ejemplo de haz. Otra manera de expresar esto es que cada ejemplo que se ajusta a B debe también ajustarse a A. si, por ejemplo, A tiene un nombre de propiedad de tipo cadena mientras que B tiene una propiedad de edad del tipo Int16, lo que sigue es que cualquier ejemplo de B debe tener un nombre y una edad. La jerarquía del tipo se puede concebir como un árbol con un solo supertipo en la raíz. Las ramas desde la raíz proveen subtipos de primer nivel, las ramas en este nivel proveen los subtipos de segundo nivel, etc. hacia los subtipos hacia los extremos que en sí mismos no tienen ningún subtipo. El árbol no está obligado a ser uniforme con detalle, ni tampoco puede contener ningún ciclo. Para un tipo determinado puede haber cero subtipos o muchos subtipos y cero o un supertipo. Un ejemplo determinado puede ajustarse cuando mucho a un tipo junto con los supertipos de ese tipo. Para explicarlo de otra manera, para un ejemplo determinado en cualquier nivel en el árbol, el ejemplo puede ajustarse cuando mucho a un subtipo en ese nivel. Se dice que un tipo es abstracto si los ejemplos del tipo también deben ser ejemplos de un subtipo del tipo. 1. Elementos Un elemento es una unidad de una información que puede almacenarse que, a diferencia de un archivo simple, es un objeto que tiene un conjunto básico de propiedades que están soportadas comúnmente a través de todos los objetos expuestos para un usuario final o programa de aplicación a través de la plataforma de almacenamiento. Los elementos también tienen propiedades y relaciones que son comunes y están soportadas a través de todos los tipos de elementos, incluyendo características que permiten nuevas propiedades y relaciones para que sean introducidas, como se analiza a continuación. Los elementos son los objetos para las operaciones comunes, por ejemplo copiar, eliminar, mover, abrir, imprimir, respaldar, restaurar, duplicar, etc. Los elementos son las unidades que se pueden almacenar y recuperar y todas las formas de información que se puede almacenar manipuladas a través de la plataforma de almacenamiento existe como elementos, propiedades de elementos o relaciones entre los elementos, cada uno de los cuales se analiza con mayor detalle en la presente a continuación. Los elementos tienen la intención de representar unidades del mundo real y comprensibles fácilmente de datos similares a contactos, personas, servicios, ubicaciones, documentos (de todas las clases), etc. La figura 5A es un diagrama de bloques que ilustra la estructura de un elemento. El nombre incondicional del elemento es "ubicación". El nombre calificado del elemento es "núcleo. ubicación" que indica que esta estructura del elemento se define como un tipo específico del elemento en el esquema de núcleo (el esquema de núcleo se analiza con mayor detalle posteriormente en la presente). El elemento ubicación tiene una pluralidad de propiedades que incluyen DireccionesElectrónicas, RegiónMetropolitana, Barrio y DireccionesPostales. El tipo específico de propiedad para cada uno se indica inmediatamente después del nombre de la propiedad y se separa del nombre de la propiedad a través de: (":"). A la derecha del nombre del tipo, el número de valores permitidos para dicho tipo de propiedad se indica entre ("[]") en donde un asterisco ("*") a la derecha de los dos puntos (":") indica un número no especificado y/o no limitado (muchos). Un "número uno" a la derecha de los dos puntos indica que puede haber cuando mucho un valor. Un cero ("0") a la izquierda de los dos puntos indica que la propiedad es opcional (puede no tener un valor). Un "1" a la izquierda de los dos puntos indica que puede haber al menos un valor (se requiere la propiedad). Barrio y Región etropoIitana ambos son del tipo "nvarchar" (o su equivalente) que son tipo de datos predefinidos o "tipo simple" (y en la presente se denota por la falta de mayúsculas). Sin embargo, las DireccionesElectrónicas y Direccionespostales son propiedades de los tipos definidos o "tipo complejo" (como se observa en la presente por el uso de mayúsculas) de los tipos DirecciónElectrónica y DirecciónPostal, respectivamente. Un tipo complejo es el tipo que se deriva de uno o más tipos de datos simples y/o de otros tipos complejos. Los tipos complejos para las propiedades en un elemento también constituye "elementos anidados" ya que los detalles del tipo complejo se anidan en el elemento inmediato para definir sus propiedades, y la información que pertenece a estos tipos complejos se mantiene con el elemento que tiene estas propiedades (dentro de los limites del elemento, como se analiza posteriormente en la presente). Estos conceptos de plastificación ya se conocen y son evidentes para los expertos en la técnica. La figura 5B es un diagrama de bloques que ilustra los tipos de propiedad compleja y DirecciónPostal y DirecciónElectrónica. El tipo de propiedad DirecciónPostal define que un elemento del tipo de propiedad DirecciónPostal se puede esperar que tenga valores de 0 ó 1 para Ciudad, 0 ó 1 para los valores CódigodePaís, 0 ó 1 para los valores AltodeCorreo y cualquier número (de 0 a muchos) de TiposdeDirecciónPostal, etc. De esta manera, la forma de los datos para la propiedad particular en un elemento se define en la presente. El tipo de propiedad Direcciónelectrónica se define de manera similar como se muestra. Aunque se usa de manera opcional en la presente esta aplicación, otra manera de representar los tipos complejos en el elemento Ubicación es dibujar el elemento con las propiedades individuales de cada tipo complejo enumerado en éste. La figura 5C es un diagrama de bloques que ilustra el elemento Ubicación en donde sus tipos complejos se describen adicionalmente. Sin embargo, debe comprenderse que esta representación alternativa del elemento Ubicación en esta figura 5C es para el elemento exactamente igual que se ilustra en la figura 5A. la plataforma de almacenamiento de la presente invención también permite la subclasificación en donde un tipo de propiedad puede ser un subtipo de otro (en donde el tipo de propiedad hereda las propiedades de otros, el tipo de propiedad de origen). Los elementos similares pero diferentes de las propiedades y sus tipos de propiedades, representan de manera inherente sus propios tipos de elementos que también pueden ser sujetos de su clasificación. En otras palabras, la plataforma de almacenamiento en diversas modalidades de la presente invención permite que un elemento sea un subtipo de otro elemento (en donde el elemento hereda las propiedades de otro, del elemento origen). Adicionalmente, para diversas modalidades de la presente invención, cada elemento de un subtipo del tipo de elemento "Elemento" que es el primer tipo de elemento de fundación encontrado en el esquema base (el esquema base también se analiza con detalle posteriormente en la presente). La figura 6A ilustra un elemento, el elemento ubicación en este ejemplo, como un subtipo del tipo de elemento y Elemento que se encuentra en el esquema base. En esta figura, la flecha indica que el elemento ubicación (como todos los otros elementos) es un subtipo de un tipo de elemento Elemento. El tipo de elemento Elemento, como el elemento de fundación desde el cual se derivan todos los demás elementos, tiene un número de propiedades importantes como pueden ser una identificadordelelemento y diversas etiquetasdetiempo, y de esta manera define las propiedades estándar de todos los elementos en un sistema operativo. En esta figura, estas propiedades del tipo de elemento Elemento se heredan por Ubicación y de esta manera se convierten en propiedades de Ubicación. Otra manera de representar las propiedades de elemento Ubicación heredado del tipo de elemento Elemento es extraer la Ubicación con las propiedades individuales de cada tipo de propiedad del elemento de origen enumerado en éste. La figura 6B es un diagrama de bloques que ilustra el elemento de Ubicación en donde sus tipos heredados descritos además de sus propiedades inmediatas. Debe observarse y comprenderse que este elemento es el mismo elemento que se ilustra en la figura 5A, aunque en la figura actual la Ubicación se ilustra con todas sus propiedades, tanto inmediatas, que se muestran tanto en esta figura como en la figura 5A, como heredadas, que se muestran en esta figura pero no en la figura 5 (mientras que en la figura 5 se hace referencia a otras propiedades mostrando con una flecha que el elemento Ubicación es un subtipo del tipo de elemento Elemento). Los elementos son objetos autónomos; de esta manera, si elimina un elemento, todos los elementos inmediatos y las propiedades heredadas también se eliminan.

De manera similar, cuando se recupera un elemento, lo que se recibe es el elemento y todas sus propiedades inmediatas y heredadas (incluyendo la información que pertenece a estos tipos de propiedades complejas). Algunas modalidades de la presente invención pueden habilitar a alguien para que solicite un conjunto de propiedades cuando recupera un elemento específico; sin embargo, el valor predeterminado para muchas de estas modalidades es proveer un elemento con todas sus propiedades inmediatas y heredadas cuando se recupera. Además, las propiedades de los elementos también se pueden extender añadiendo nuevas propiedades de las propiedades existentes de ese tipo de elemento. Estas "extensiones" por lo tanto son propiedades de buena fe del elemento y los subtipos de ese tipo de elemento automáticamente pueden incluir las propiedades de extensión.

El "límite" del elemento se representa a través de sus propiedades (incluyendo los tipos de propiedad compleja, las extensiones, etc.). Un límite de un elemento también representa el límite de una operación realizada en un elemento por ejemplo copiar, borrar, mover, crear, etc. Por ejemplo, en algunas modalidades de la presente invención, cuando se copia un elemento, todo lo que incluye los límites del elemento también se copia. Para cada elemento, el límite incluye lo siguiente: · El tipo Elemento del elemento y, si el elemento es un subtipo de otro Elemento (como es el caso en diversas modalidades de la presente invención en donde todos los Elementos se derivan de un solo Elemento y el tipo Elemento en el esquema base), cualquier información del subtipo aplicable (esto es, información que pertenece al tipo de Elemento origen). Si el Elemento original que se copia es un subtipo de otro Elemento, la copia también puede ser un subtipo dei mismo Elemento. • Las propiedades del tipo complejo del Elemento y sus extensiones, si hubiere alguna. Si el Elemento original tiene propiedades de los tipos complejos (nativos o extendidos), la copia también debe tener los mismos tipos complejos. • Los registros del Elemento en "relaciones de propiedad", esto es, la propia lista del Elemento de los propios Elementos (los "Elementos objeto") son propiedad del presente Elemento (en "Elemento propietario"). Esto es particularmente pertinente con respecto a la carpeta Elemento, analizadas con mayor detalle a continuación, y la regla establecida a continuación de que todos los Elementos deben permanecer al menos a una carpeta Elemento. Adicionalmente, con respecto a los Elementos incrustados, analizados con mayor detalle a continuación, un Elemento incrustado se considera como parte del Elemento en donde se incrusta para las operaciones como copiar, borrar y similares. 2. Identificación de elementos Los Elementos se identifican de manera exclusiva con el espacio de Elementos global con un identificar de Elemento (ItemID). El tipo Base. Item define un campo ItemID de la GUID que almacena la identidad del Elemento. Un Elemento debe tener exactamente una identidad en el almacén de datos 302. Una referencia del Elemento es una estructura de datos que contiene información para ubicar e identificar un Elemento. En el modelo de datos, un tipo abstracto se define denominado referencia del Elemento (ItemReference) desde el cual se derivan todos los tipos de referencia del elemento. El tipo Itemreference define un método virtual denominado resolución (Resolve). El método Resolve resuelve ItemReference y devuelve un Elemento. Este método se anula a través de los subtipos concretos de ItemReference, lo que implementa una función que recupera un elemento dada una referencia. El método Resolve se invoca como parte de la API de plataforma de almacenamiento 322. Iteml DReference es un subtipo de ItemReference. Define un campo Locator y un campo ItemID. El campo Locator nombra (es decir, identifica) un dominio de elemento. Se procesa a través del método de resolución del ubicador que puede resolver el valor de Locator en un dominio del Elemento. El campo ItemID es del tipo de identificador del Elemento. ItemPathReference es una especialización de ItemReference que define un campo Locator y un campo Path. El campo Locator identifica un dominio del elemento. Se procesa a través de un método de resolución de localizador que puede resolver el valor del Locator en un dominio del elemento. El campo Path contiene un trayecto (relativo) en el espacio del nombre de la plataforma de almacenamiento originado en la línea del elemento provisto por el localizador. Este tipo de referencia no se puede usar en una operación de configuración. La referencia generalmente debe resolverse a través de un proceso de resolución de trayecto. El método de resolución de la API de la plataforma de almacenamiento 322 proporciona esta funcionalidad. Las formas de referencia analizadas en los párrafos anteriores se representan a través de la jerarquía del tipo de referencia que se ilustra en la figura 11. Los tipos de referencia adicionales que e heredan de estos tipos se pueden definir en los esquemas. Se pueden usar en una declaración de relación como el tipo del campo objetivo. 3. Carpetas y categorías del elemento Como se analiza con mayor detalle a continuación, los grupos de Elemento se pueden organizar en Elementos especiales denominados carpetas elementos (que no deben confundirse con carpetas de archivos). Sin embargo, a diferencia de la mayoría de los sistemas de archivos, un elemento puede pertenecer a más de una carpeta elemento, de manera que cuando se accede a un elemento en una carpeta elemento y se revisa, entonces, se puede tener acceso a este elemento revisado directamente desde otra carpeta elemento. En esencia, aunque el acceso a un elemento puede producirse desde diferentes carpetas elementos, a lo que realmente se accede es al mismísimo elemento. Sin embargo, una carpeta elemento no necesariamente contiene todos sus elementos miembros, o simplemente puede ser copropietaria de elementos en conjunto con otras carpetas, por ejemplo la eliminación de una carpeta elemento no necesariamente ocasiona la eliminación del elemento. No obstante, en diversas modalidades de la presente invención, un elemento debe pertenecer al menos a una carpeta elemento, de manera que si la sola carpeta elemento para un elemento particular se elimina, entonces, para algunas modalidades, el elemento se elimina automáticamente o, en modalidades alternativas, el elemento automáticamente se convierte en un miembro de una carpeta elemento predeterminada (por ejemplo, una carpeta de elementos "bandeja de reciclaje" que es conceptualmente similar a las carpetas nombradas de manera similar que se usan en diversos sistemas basados en archivos y carpetas). Como se analiza también con mayor detalle a continuación, los elementos también pueden pertenecer a categorías basadas en características comunes descritas como (a) un tipo elemento (o tipos), (b) una propiedad inmediata específica o heredada (o propiedades), o (c) un valor específico (o valores) que corresponden a una propiedad del elemento. Por ejemplo, un elemento que comprende propiedades específicas para obtener información de contactos personales automáticamente puede pertenecer a una categoría de contacto y cualquier elemento que tenga propiedades de información de contacto de igual manera automáticamente puede pertenecer a esta categoría. De igual manera, cualquier elemento que tenga una propiedad de ubicación con un valor de "ciudad de Nueva York" puede pertenecer automáticamente a una categoría ciudad de Nueva York. Las categorías son diferentes conceptualmente de las carpetas elemento en que, mientras las carpetas elemento pueden comprender elementos que no están interrelacionados (es decir, sin una característica común descrita), cada elemento de una categoría tiene un tipo común, una propiedad o un valor (una "convergencia") que se describe para esa categoría, y es ésta la convergencia que forma la base para su relación y entre los otros elementos en la categoría. Adicionalmente, mientras una membresía del elemento en una carpeta particular no se basa de manera obligatoria en ningún aspecto particular de ese elemento, para ciertas modalidades todos los elementos que tengan una convergencia relacionada categóricamente con una categoría automáticamente pueden convertirse en un miembro de la categoría en el nivel del sistema de interfaz de los componentes físicos de computación y los programas y sistemas de programación. Conceptualmente, las categorías también pueden concebirse como carpetas de elementos virtuales cuya membresía se basa en los resultados de una consulta específica (como en el contexto de una base de datos), y los elementos que cumplan con las condiciones de esta consulta (definida por las convergencias de la categoría) comprenderían la membresía de la categoría. La figura 4 ilustra la relación estructural entre los elementos, las carpetas elementos y categorías. Una pluralidad de elementos 402, 404, 406, 408, 410, 412, 414, 416, 418 y 420 son miembros de diversas carpetas de elementos 422, 424, 426, 428 y 430. Algunos elementos pueden pertenecer a más de una carpeta de elementos, por ejemplo, el elemento 402 pertenece a las carpetas de elementos 422 y 424. Algunos elementos, por ejemplo, el elemento 402, 404, 406, 408, 410 y 412 también son miembros de una o más categorías 432, 434 y 436, mientras en otras ocasiones, por ejemplo los elementos 414, 416, 418 y 420 puede pertenecer a ninguna categoría (aunque esto es poco probable en algunas modalidades en donde la posesión de cualquier propiedad automáticamente implica la membresía de una categoría, y de esta manera un elemento estaría completamente sin características para que no fuera miembro de ninguna categoría en una modalidad tal). En contraste con la estructura jerárquica de las carpetas, tanto las categorías como las carpetas elementos tienen estructuras más similares a las gráficas dirigidas como se muestra. En cualquier evento, los elementos, carpetas elemento y categorías todos son elementos (aunque de diferentes tipo de elemento). En contraste con los archivos, carpetas y directorios, los elementos, carpetas elemento y categorías de la presente invención no son característicamente "físicos" en naturaleza debido a que no tienen equivalentes conceptuales de contenedores físicos, y por lo tanto los elementos pueden existir en más de una ubicación. La capacidad de existencia de los elementos en más de una ubicación de carpeta elemento así como la organización en categorías proporciona un grado mejorado y enriquecido de manipulación de datos y capacidades de estructura de almacenamiento en el nivel de interfaz de los componentes físicos y los programas y sistemas de programación, más allá de los disponible actualmente en la técnica. 4. Esquemas (a) Esquema base Para proveer un fundamento universal para la creación y uso de elementos, diversas modalidades de la plataforma de almacenamiento de la presente invención comprenden un esquema base que establece una estructura conceptual para crear y organizar elementos y propiedades. El esquema base define ciertos tipos especiales de elementos y propiedades, y las características de estos tipos fundamentales especiales desde los cuales se pueden dividir adicionalmente los subtipos. El uso de este esquema base permite que un programador distinga conceptualmente a los elementos (y sus tipos respectivos) de las propiedades (y sus tipos respectivos). Adicionalmente, el esquema base establece el conjunto en fundamentos de las propiedades que todos los elementos pueden poseer como todos los elementos (y sus tipos de elementos correspondientes) se derivan de este elemento fundamental en el esquema base (y su tipo de elemento correspondiente). Como se ilustra en la figura 7, y con respecto a diversas modalidades de la presente invención, el esquema base define tres tipos de nivel superior: Elemento, Extensión y Propiedad base. Como se muestra, el tipo de elemento se define por las propiedades de este tipo de elemento "Elemento" fundamental. En contraste, el tipo de propiedad de nivel superior "propiedad base" no tiene propiedades definidas previamente y es meramente el ancla desde la cual todos los tipos de propiedades se derivan a través de la cual todos los tipos de propiedades derivadas se interrelacionan (se derivan comúnmente del tipo de propiedad único). Las propiedades del tipo extensión definen qué elemento extiende la extensión así como la identificación para distinguir una extensión de otra ya que un elemento puede tener diversas extensiones. ItemFolder (carpeta elemento) es un subtipo del tipo del elemento Elemento que, además de las propiedades hereditarias del elemento, cuenta con una relación para establecer enlaces con sus miembros (si tiene alguno), mientras que IdentityKey (clave de identidad) y Property (propiedad) son subtipos de PropertyBase (propiedad base). En su momento, CategoryRef (referencia de categoría) es un subtipo de IdentitiKey. (b) Esquema central Diversas modalidades de la plataforma de almacenamiento de la presente invención además comprenden un esquema de núcleo que proporciona una estructura conceptual para las estructuras de tipo de elementos de nivel superior. La figura 8A es un diagrama de bloques que ilustra los elementos en el esquema de núcleo, y la figura 8B es un diagrama de bloques que ilustra los tipos de propiedad en el esquema de núcleo. La distinción que se hace entre los archivos con diferentes extensiones (*.com, *.exe, *.bat, *sys, etc.) y otros criterios similares en los sistemas basados en archivo y carpetas es análogo a la función del esquema de núcleo. En el sistema de interfaz de los componentes físicos de computación y los programas y sistemas de programación, el esquema de núcleo define un conjunto de tipos de elemento núcleo que, directamente (por tipo de elemento) o indirectamente (por subtipo de elemento), caracterizan todos los elementos en uno o más tipos de elemento de esquema de núcleo lo que comprende el sistema de interfaz de los componentes físicos de computación y los programas y sistemas de programación basados en elementos y puede procesar directamente de una manera predeterminada y predecible. Los tipos de elementos predefinidos reflejan los elementos más comunes en el sistema de interfaz de los componentes físicos de computación y los programas y sistemas de programación basados en elementos y de esta manera un nivel de eficiencia se obtiene a través del sistema de interfaz de los elementos físicos de computación y los programas y sistemas de programación basados en elementos comprendiendo estos tipos de elementos predefinidos que comprende el esquema de núcleo. En algunas modalidades, el esquema de núcleo no puede extenderse, esto es, no se puede subdividir en tipos de elementos adicionales directamente desde el tipo de elemento en el esquema base, con excepción de los tipos de elementos derivados predefinidos específicamente que son parte del esquema de núcleo. Al evitar las extensiones en el esquema de núcleo (es decir, al evitar la adición de nuevos elementos al esquema de núcleo), la plataforma de almacenamiento indica el uso de los tipos del elemento de esquema de núcleo ya que cada tipo de elemento subsiguiente es necesariamente un subtipo del tipo de elemento de esquema de núcleo. Esta estructura permite un grado razonable de flexibilidad en la definición de los tipos de elementos adicionales mientras que conserva los beneficios de tener un conjunto predefinido de tipos de elementos de núcleo. Para diversas modalidades de la presente invención, y haciendo referencia a la figura 8A, los tipos de elementos específicos soportados por el esquema de núcleo pueden incluir uno o más de lo siguiente: • Categoría: elementos de este tipo de elemento (y los subtipos derivados de éste) representan las categorías válidas en el sistema de interfaz de los componentes físicos de computación y los programas y sistemas de programación basados en elementos. • Productos: elementos que son cosas de valor identificable. • Dispositivos: elementos que tienen una estructura lógica que soporta las capacidades de procesamiento e información.

• Documentos: elemento con contenido que no se interpreta a través del sistema de interfaz de los componentes físicos de computación y los programas y sistemas de programación basados en elementos, en su lugar se interpretan a través de un programa de aplicaciones que corresponde al tipo de documento. • Eventos: elementos que registran ciertas ocurrencias en el entorno. • Ubicaciones: elementos que representan ubicaciones físicas (por ejemplo ubicaciones geográficas). • Mensajes: elementos de comunicación entre dos o más elementos principales (definidos a continuación). • Elementos principales: elementos que tienen al menos una identidad probable definitivamente además de un identificador del elemento (por ejemplo, la identificación de una persona, organización, grupo, agrupación, autoridad, servicio, etc.). • Afirmaciones: elementos que tiene información especial con respecto al entorno que incluye, sin limitarse a esto, políticas, suscripciones, identificaciones, etc. De igual manera y con referencia a la figura 8B, los tipos de propiedades específicas que se soportan por el esquema de núcleo pueden incluir uno o más de lo siguiente: • Certificados: Derivados del tipo fundamental (PropertyBase en el esquema base).

• Claves de identidad de elemento principal: (derivados del tipo IdentitiKey en el esquema base). • Dirección postal: (derivado del tipo Property en el esquema base). · Texto rico: (Property en el esquema base). • Dirección electrónica: (derivado del tipo Property en el esquema base). • Paquete de seguridad de identidad: (derivado del tipo Relationship en el esquema base). · Ocupación de rol (derivado del tipo Relationship en el esquema base). • Presencia básica (derivado del tipo Relationship en el esquema base). Estos elementos y propiedades se describen adicionalmente mediante sus propiedades respectivas que se establecen en la figura 8A y figura 8B. 5. Relaciones Las relaciones son relaciones binarias en donde un elemento está diseñado como fuente y el otro elemento como objetivo. El elemento fuente y el elemento objetivo están relacionados por la relación. El elemento fuente generalmente controla el tiempo de vida útil de la relación. Es decir, cuando el elemento fuente se elimina, la relación entre los elementos también se elimina. Las relaciones se clasifican en: Relaciones de propiedad y de referencia. Las relaciones de propiedad controlan el tiempo de vida útil de los elementos objetivo, mientras las relaciones de referencia no proporcionan ninguna semántica de administración del tiempo de vida útil. La figura 12 ilustra la manera en que las relaciones se clasifican. Los tipos de relación de propiedad además se clasifican en relaciones de propiedad e incrustación. Cuando todas las relaciones de propiedad en un elemento se eliminan, el elemento se elimina. Una relación de propiedad controla el tiempo de vida útil del objetivo a través de un mecanismo de conteo de referencia. Las relaciones de incrustación permiten modelar los elementos compuestos y se puede concebir como una relación de propiedad exclusiva. Un elemento puede ser un objetivo de una o más relaciones de propiedad; pero un elemento puede ser el objetivo de exactamente una relación de incrustación. Un elemento que es un objetivo de una relación de incrustación no puede ser un objetivo de ninguna otra relación de propiedad o incrustación. Las relaciones de referencia no controlan el tiempo de vida útil del elemento objetivo. Pueden estar pendientes, el elemento objetivo puede no existir. Las relaciones de referencia se pueden usar para modelar referencias para los elementos en cualquier momento en el espacio de nombre del elemento global (es decir, incluyendo almacenes de datos remotos).

La búsqueda de un elemento no busca automáticamente su relación. Las aplicaciones deben solicitar explícitamente las relaciones de un elemento. Además, la modificación de una relación no modifica el elemento fuente u objetivo; de manera similar, ia adición de una relación no afecta el elemento fuente/ objetivo. a) Declaración de relación Los tipos explícitos de relación se definen con los siguientes elementos: · Un nombre de relación se identifica en el atributo Ñame. • El tipo de relación es uno de los siguientes: propiedad, incrustación, referencia. Esto se especifica en el atributo type. · Puntos de extremo fuente y objetivo. Cada punto de extremo especifica un nombre y el tipo del elemento al que hace referencia. • En el campo del punto de extremo fuente generalmente del tipo ItemID (no declarado) y debe hacer referencia a un elemento en el mismo almacén de datos como el ejemplo de relación. • Para las relaciones de propiedad e incrustación, el campo del punto de extremo objetivo debe ser del tipo ItemIDReference y debe hacer referencia a un elemento en el mismo almacén como en el ejemplo de relación. Para las relaciones de referencia el punto de extremo objetivo puede ser de cualquier tipo ItemReference y puede hacer referencia a los elementos en otros almacenes de datos de la plataforma de almacenamiento. · Opcionalmente uno o más campos de un tipo escalar o propiedad de base se pueden declarar. Estos campos pueden contener los datos asociados con la relación. • Los ejemplos de una relación se almacenan en una tabla de relaciones global. · Todos los ejemplos de relaciones se identifican de manera exclusiva mediante la combinación (identificador del elemento fuente, identificador de la relación). El identificador de la relación es único dentro de un identificador del elemento fuente determinado para toda las relaciones que se originan en un elemento determinado sin importar su tipo. El elemento fuente es el propietario de la relación. Aunque un elemento diseñado como el propietario controla el tipo de vida útil de la relación, la relación en sí misma está separada de los elementos a los que se refiere. La API 322 de la plataforma de almacenamiento proporciona mecanismos para exponer las relaciones asociadas con un elemento. A continuación se da un ejemplo de una declaración de relación: <Relationship Ñame- 'Employment" BaseType="Reference" > <Source Name="Employee" ItemType="Contact.Person"/ <Target Name="Employer" ItemType="Contact. Organiza ReferenceType="ItemIDReference" /> <Property Name="StartDate" Type="the storage platformTypes.DateTime" /> <Property Name="EndDate" Type="the storage platformTypes.DateTime" /> <Property Name="Offíce" Type="the storage platformTypes.DateTime" /> </Relationship> Este es un ejemplo de una relación de referencia. La relación puede no ser creada si el elemento persona al que se hace referencia a través de la referencia fuente no existe. De igual manera, si el elemento persona se borra, los ejemplos de la relación entre la persona y la organización se borran. Sin embargo, si el elemento organización se elimina, la relación no se elimina y queda colgando. (b) Relaciones de propiedad Las relaciones de propiedad se usan para modelar una cuenta de referencia con base en la administración del tiempo de vida útil de los elementos objetivo. Un elemento puede ser un punto de extremo fuente para 0 o más relaciones para los elementos. Un elemento que no es un elemento incrustado puede ser un objetivo en una o más relaciones de propiedad. El tipo de referencia del punto de extremo objetivo debe ser Iteml DReference y debe hacer referencia a un elemento en el mismo almacén que el ejemplo de la relación.

Las relaciones de propiedad refuerzan la administración del tiempo de vida útil del punto de extremo objetivo. La creación de un ejemplo de una relación de propiedad y el elemento al que se dirige es una operación atómica. Los ejemplos de la relación de propiedad adicionales pueden crearse y se dirigen al mismo elemento. Cuando se borra un ejemplo de una relación de propiedad última con un elemento determinado como el punto de extremo objetivo, el elemento objetivo también se borra. Los tipos de los elementos del punto de extremo especificados en la declaración de la relación generalmente serán reforzados con un ejemplo de la relación al crearla. Los tipos de los elementos del punto de extremo no se pueden cambiar después de establecer la relación. Las relaciones de propiedad juegan un papel clave en la formación del espacio de nombre del elemento. Contienen la propiedad " ame" que define el nombre del elemento objetivo con relación al elemento fuente. Este nombre relativo es único para todas las relaciones de propiedad originadas desde un elemento determinado. En la lista ordenada de estos nombres relativos iniciando desde el elemento de raíz hacia un elemento determinado forma el nombre completo del elemento. Las relaciones de propiedad forman una gráfica acíclica dirigida (DAG). Cuando una relación de propiedad se crea el sistema asegura que no se cree un ciclo, de esta manera asegura que el espacio de nombre del elemento forma una DAG. Aunque la relación de propiedad controla el tiempo de vida útil del elemento objetivo, no controla la consistencia operativa del elemento del punto de extremo objetivo. El elemento objetivo es independiente operativamente del elemento que lo contiene a través de la relación de propiedad. Las operaciones de copiar, mover, hacer un respaldo así como otras de un elemento que es una fuente de una relación de propiedad no afectan al elemento que es un objetivo de la misma relación; por ejemplo, esto es, respaldar un elemento de carpeta no respalda automáticamente todos los elementos dentro de la carpeta (los objetivos de la relación FolderMember). A continuación se da un ejemplo de una relación de propiedad: <Relationship Name="FolderMembers" BaseType="Holding" > <Source Name="Folder" ItemType="Base.Folder7> <Target Name="Item" ItemType="Base.Ite:m" ReferenceType="ItemIDReference" /> </Relationship> La relación FolderMember habilita el concepto de una carpeta como una colección genérica de elementos. c) Relaciones de incrustación Las relaciones de incrustación modelan el concepto de control exclusivo del tiempo de vida útil del elemento objetivo. Habilitan el concepto de elementos compuestos. La creación de un ejemplo de una relación de incrustación y el elemento que es el objetivo es una operación atómica. Ei elemento puede ser una fuente de 0 o más relaciones de incrustación. Sin embargo, un elemento puede ser un objetivo de una y sólo una relación de incrustación. Un elemento que es un objetivo de una relación de incrustación no puede ser un objetivo de una relación de propiedad . El tipo de referencia del punto de extremo objetivo debe ser Iteml DReference y debe hacer referencia a un elemento en el mismo almacén de datos como el ejemplo de la relación. Los tipos de los elementos de puntos de extremo especificados en la declaración de relación generalmente se reforzarán cuando un ejemplo de la relación se crea. Los tipos de los elementos del punto de extremo no se pueden cambiar después de establecer la relación. Las relaciones de incrustación controlan la consistencia operativa del punto de extremo objetivo. Por ejemplo, la operación de hacer una serie de un elemento puede incluir hacer una serie de todas las relaciones de incrustación que tienen como origen el elemento, así como todos sus objetivos; el copiado de un elemento también copia todos sus elementos incrustados. A continuación se da un ejemplo de declaración: <Relationship Name="ArchiveMembers" BaseType="Embedding" > <Source Name=" Archive" ItemType="Zip. Archive" /> <Target Name="Member" ItemType-'Base.Item " ReferenceType="ItemIDReference" /> <Property Name- 'ZipSize" Type="the storage platformTypes.bi.gint" /> <Property Type=" the storage platfonnTypes.float" /> </Rclationship> d) Relaciones de referencia La relación de referencia no controla el tiempo de vida útil del elemento al que hace referencia. Incluso, las relaciones de referencia no garantizan la existencia del objetivo, tampoco garantizan el tipo del objetivo como se especifica en la declaración de relación. Esto significa que las relaciones de referencia se pueden quedar colgando. También, la relación de referencia puede hacer referencia a los elementos en otros almacenes de datos. Las relaciones de referencia también pueden concebirse como conceptos similares a enlaces en páginas de redes informáticas. Un ejemplo de una declaración de relación de referencia es la que se indica a continuación: , . <Relationship Name="DocumentAuthor" BaseType="Reference" > <Sourc ItemType-'Document" ItemType="Base.Document"/> <Target ItemType- 'Author" ItemType="Base.Author" ReferenceTpof="ItemIDReference"/> <Property Type="Role" Type="Core.CategoryRef ' /> <Property Type="DisplayName" Type-'the storage platformTypes.nvarchar(256)" /> </Relationship> Cualquier tipo de referencia se permite en el punto de extremo objetivo. Los elementos que participan en una relación de referencia pueden ser cualquier tipo de elemento. Las relaciones de referencia se usa para modelar la mayoría de las relaciones de administración que no son del tiempo de vida útil entre los elementos. Debido a que la existencia del objetivo no se refuerza, la relación de referencia es cómoda para modelar relaciones relacionadas de manera suelta. La relación de referencia se puede usar para elementos del objetivo en otros almacenes de datos incluyendo almacenes en otras computadoras. e) Reglas y restricciones Las siguientes reglas y restricciones adicionales aplican a las relaciones: · Un elemento debe ser un objetivo de (exactamente una relación de incrustación) o (una o más relaciones de propiedad). Una excepción es e! elemento de raíz. Un elemento puede ser un objetivo de 0 o más relaciones de referencia. · Un elemento que es un objetivo de una relación de ' incrustación no puede ser la fuente de una relación de propiedad. Puede ser una fuente de relaciones de referencia.

• Un elemento no puede ser una fuente de una relación de propiedad si se promueve desde un archivo. Puede ser una fuente de relaciones de incrustación y relaciones de referencia. • Un elemento que se promueve desde un archivo no puede ser un objetivo de una relación de incrustación, f) Orden de las relaciones En al menos una modalidad, la plataforma de almacenamiento de la presente invención soporta el orden de las relaciones. El orden se logra a través de una propiedad denominada "orden" en la definición de relación base. No hay una restricción única en el campo Order. El orden de las relaciones con el mismo valor de propiedad Order no está garantizado, sin embargo, se garantiza que puede estar ordenado después de que las relaciones con un valor de orden inferior y antes de las relaciones con un valor en el campo "Order" sean superiores. Las aplicaciones pueden obtener las relaciones en el orden predeterminado al hacer un orden con base en la combinación (SourceltemID, Relationshipl D, Order). Todos los ejemplos de relación que provienen de un elemento determinado se ordenan como una colección única sin importar el tipo de las relaciones en la colección. Sin embargo, esto garantiza que todas las relaciones de un tipo determinado (por ejemplo, FolderMember) son un subconjunto ordenado de la colección de relaciones para un elemento determinado. La API 312 del almacén de datos para manipular las relaciones implementa un conjunto de operaciones que soportan el orden de las relaciones. Los siguientes términos se introducen para ayudar a explicar las operaciones: • ReiFirst es la primera relación en la colección ordenada con un valor de orden OrdFirst; • RelLast es la última relación en la colección ordenada con un valor de orden OrdLast; • RelX es una relación determinada en una colección con un valor de orden OrdX; · RelPrev es una relación más cercana en la colección al valor RelX con un valor de orden OrdPrev más pequeño que OrdX; y • ReINext es una relación más cercana en la colección al valor de RelX con un valor de orden OrdNext mayor que InsertBeforeFisrst (SourceltemID, relationship). Las operaciones incluyen sin limitarse a esto: • InsertBeforeFirst (SourceltemID, Relationship) inserta la relación como la primera relación en la colección. El valor de la propiedad "Order" de la nueva relación puede ser menor que Ordfirst. • I nsertAfterLast (SourceltemID, Relationship) inserta la relación como la última relación en la colección. El valor de la propiedad "Order" de la nueva relación puede ser mayor que OrdLast. · InsertAt (SourceltemID, Relationship) inserta una relación con el valor especificado para la propiedad "Order". • InsertBefore (Sourcelteml D, ord, Relationship) inserta la relación antes de la relación con el valor de orden determinado. La nueva relación se puede asignar con un valor de "Order" que está entre OrdPrev y ord no inclusive. • InsertAfter (SourceltemlD, ord, Relationship) inserta la relación después de la relación con el valor de orden determinado. La nueva relación se puede asignar con un valor de Order que está entre Ord y OrdNext, no inclusive. · MoveBefore (SourceltemlD, ord, Relationship) mueve la relación con el identificador de la relación determinado antes de la relación con el valor especificado de "Order". A la relación se puede asignar un nuevo valor de "Order" que está entre OrdPrev y ord, no inclusive. · MoveAfter (SourceltemlD, ord, Relationship) mueve la relación con el identificador de la relación determinada después de la relación con el valor especificado de "Order". La relación se puede asignar con un nuevo valor de orden que está entre Ord y OrdNext, no inclusive. Como se mencionó anteriormente, cada elemento debe ser parte de una carpeta elemento. En términos de relaciones, cada elemento debe tener una relación con una carpeta elemento. En diversas modalidades de la presente invención, ciertas relaciones se representan mediante las relaciones que existen entre los elementos.

Como se implemento en las diversas modalidades de la presente invención, una relación proporciona una relación binaria dirigida que se "extiende" en un elemento (la fuente) a otro elemento (el objetivo). Una relación pertenece a un elemento fuente (el elemento que la extendió) y de esta manera la extensión se elimina si la fuente se elimina (por ejemplo, la relación se elimina cuando el elemento fuente se elimina). Adicionalmente, en algunos casos, una relación puede compartir la propiedad (ser copropietario) del elemento objetivo, y de esta manera la propiedad puede reflejarse en la propiedad IsOwned (o su equivalente) de la relación (como se muestra en la figura 7 para el tipo de propiedad de relación). En estas modalidades, la creación de una nueva relación IsOwned automáticamente incrementa un conteo de referencia en el elemento objetivo, una eliminación de dicha relación puede disminuir el conteo de referencia en el elemento objetivo. Para estas modalidades específicas, los elementos siguen existiendo si tienen un conteo de referencia mayor que cero, y automáticamente se eliminan cuando el conteo llega a cero. Nuevamente, una carpeta de elemento es un elemento que tiene (o es capaz de tener) un conjunto de relaciones con otros elementos, estos otros elementos comprende la membresía de la carpeta elementos. Otras implementaciones reales de las relaciones son posibles y se anticipan a través de la presente invención para lograr la funcionalidad descrita en la presente. Sin tomar en cuenta la implementación real, una relación es una colección que se puede seleccionar de un objeto a otro. La capacidad de un elemento para pertenecer a más de una carpeta de elementos, así como una o más categorías, y si estos elementos, carpetas y categorías son públicas o privadas, se determina mediante los significados dados en la existencia (o falta) en una estructura basada en elementos. Estas relaciones lógicas son los significados asignados a un conjunto de relaciones, sin importar la implementación física, que se emplean específicamente para lograr la funcionalidad descrita en la presente. Las relaciones lógicas se establecen entre el elemento y sus carpetas de elemento o categorías (y viceversa) debido a que, en esencia, las carpetas de elementos y sus categorías cada una son de un tipo especial de elementos. En consecuencia, las carpetas de elementos y sus categorías pueden actuar de la misma manera que cualquier otro elemento, copiarse, añadirse a un mensaje de correo electrónico, incrustarse en un documento, etc. sin limitarse, y las carpetas de elementos y las categorías se pueden colocar en serie y separarse de esa serie (importarse y exportarse) usando el mismo mecanismo que para otros elementos (por ejemplo, en XML todos los elementos pueden tener un formato de enumeración en serie, y este formato aplica de igual manera a carpetas de elementos, categorías y elementos). Las relaciones mencionadas anteriormente, que representan la relación entre un elemento y una carpeta de elementos puede extenderse lógicamente desde el elemento hacia la carpeta del elemento, desde la carpeta de elementos hacia el elemento, o ambos. En la relación que se extiende lógicamente desde un elemento hacia una carpeta de elementos denota que la carpeta del elemento es pública para ese elemento y comparte su información de membresía con ese elemento, por el contrario, la falta de una relación lógica de un elemento a una carpeta de elementos denota que la carpeta del elemento es privada y que el elemento no comparte su información de membresía con ese elemento. De manera similar, una relación que se extiende lógicamente desde una carpeta de elementos hacia un elemento denota que el elemento es público y puede compartir con esa carpeta de elementos, mientras que la falta de una relación lógica desde la carpeta de elementos hacia el elemento denota que el elemento es privado y no puede compartirse. En consecuencia, cuando una carpeta de elementos exporta otro sistema, los elementos "públicos" son los que están compartidos en el nuevo contexto, y cuando un elemento busca sus carpetas de elementos para otros elementos que pueden ser compartidos, las carpetas de elementos "públicos" que proveen el elemento con información respecto a los elementos que pueden compartir que pertenecen a éste. La figura 9 es un diagrama de bloques que ilustra una carpeta de elementos (la cual, nuevamente, es un elemento en sí mismo), sus elementos miembro, y las relaciones de interconexión entre la carpeta de elementos y sus elementos miembro. La carpeta de elementos 900 tiene como miembros una pluralidad de elementos 902, 904 y 906. La carpeta de elementos 900 tiene una relación 912 desde sí misma hacia el elemento 902, lo que denota que el elemento 902 es público y puede compartirse con la carpeta de elementos 900, sus miembros 904 y 906, y cualesquiera otra carpetas de elementos, categorías o elementos (no se muestran) que puedan acceder a la carpeta de elementos 900. Sin embargo, no hay relación del elemento 902 con la carpeta de elemento 900, lo que denota que la carpeta de elementos 900 es privada para el elemento 902 y que no comparte su información de membresía con el elemento 902. El elemento 904, por otro lado, tiene una relación 924 desde sí mismo con 1a carpeta de elementos 900 la cual denota que la carpeta de elementos 900 es pública y comparte su información de membresía con el elemento 904. Sin embargo, no hay una relación de la carpeta de elementos 900 con el elemento 904 que denote que el elemento 904 es privado y no puede compartir con la carpeta de elementos 900, sus otros miembros 902 y 906 y cualquiera otras carpetas de elementos, categorías y elementos (no se muestran) que pueda acceder a la carpeta de elementos 900. En contraste con sus relaciones (o falta de éstas) con los elementos 902 y 904, la carpeta de elementos 900 tiene una relación 916 desde sí misma con el elemento 906 y el elemento 906 tiene una relación 926 hacia la carpeta de elementos 900, lo que en conjunto denota que el elemento 906 es público y puede compartir con la carpeta de elementos 900, y miembros 902 y 904, y cualesquiera otra carpeta de elementos, categorías o elementos (no se muestran) que puedan tener acceso a la carpeta de elementos 900, y que la carpeta de elementos 900 es pública y comparte su información de membresía con el elemento 906. Como se analizó anteriormente, los elementos de una carpeta de elementos no necesitan compartir una convergencia debido a que las carpetas de elementos no se describen. Las categorías, por otro lado, se describen a través de una convergencia que es común para todos los elementos de miembro. En consecuencia, la membresía de una categoría se limita de manera inherente a los elementos que tienen la convergencia descrita y, en algunas modalidades, todos los elementos que cubren la descripción de una categoría se hacen miembros automáticamente de la categoría. De esta manera, mientras las carpetas de elementos permiten que las estructuras de tipo seriales se representen a través de sus membresías, las categorías permiten las membresías basadas en las convergencias definidas. Desde luego las descripciones de las categorías son lógicas por naturaleza, y por lo tanto, una categoría puede describirse a través de cualquier representación lógica de tipos, propiedades y/o valores. Por ejemplo, como una representación lógica de una categoría puede ser su membresía para que comprenda los elementos que tienen una de dos propiedades o ambas. Si esas propiedades descritas para la categoría son "A" y "B", entonces la membresía de las categorías puede comprender elementos que tienen la propiedad A pero no la propiedad B, los elementos que tienen la propiedad B pero no la A, y los elementos que tienen ambas propiedades A y B. Esta representación lógica de propiedades se describe mediante el operador lógico "OR" en donde el conjunto de miembros descritos por la categoría son elementos que tienen una propiedad A OR B. Los operadores lógicos similares (incluyendo sin limitarse "AND", "XOR", y "NOT" solo o en combinación) también se puede usar para describir una categoría como será evidente para los expertos en la técnica. A pesar de las restricciones entre las carpetas de elementos (no descritas) y las categorías (descritas), la relación de categorías con los elementos y la relación de elementos con las categorías esencialmente son de la misma manera como se describió anteriormente en la presente para las carpetas de elementos y los elementos en muchas modalidades de la presente invención. La figura 10 es un diagrama de bloques que ilustra una categoría (la cual, nuevamente, es un elemento en sí mismo), sus elementos miembros y las relaciones de interconexión entre la categoría y sus elementos miembros (la categoría 1000 tiene como miembros una pluralidad de elementos 1002, 1004 y 1006, todos los cuales comparten la misma combinación de propiedades comunes, valores o tipos 1008 como se describió (descripción de convergencias 1008') mediante la categoría 1000. La categoría 1000 tiene una relación 1012 de sí misma con el elemento 1002, la cual denota que el elemento 1002 es público y puede compartirse con la categoría 1000, sus miembros 1004 y 1006, y cualesquiera otras categorías, carpetas de elementos o elementos (no se muestran) que puedan tener acceso a la categoría 1000. Sin embargo, no hay una relación del elemento 1002 con la categoría 1000, lo que denota que la categoría 1000 es privada para el elemento 1002 y no comparte su información de membresía con el elemento 1002. El elemento 1004, por otro lado, tiene una relación 1024 de sí mismo con la categoría 1000, lo que denota que la categoría 1000 es pública y comparte su información de membresía con el elemento 1004. Sin embargo, no hay una relación extendida de la categoría 1000 con el elemento 1004 que denota que el elemento 1004 es privado y no es compartido para la categoría 1000, sus otros miembros 1002 y 1006 y cualesquiera otras categorías, carpetas de elementos o elementos (no se muestran) que pudieran acceder a la categoría 1000. En contraste con las relaciones (o falta de éstas) con los elementos 1002 y 1004, la categoría 1000 tiene una relación 1016 de sí misma con el elemento 1006 y el elemento 1006 tiene una relación 1026 con la categoría 1000, lo que en conjunto denota que el elemento 1006 es público y puede compartir con la categoría 1000, sus miembros de elemento 1002 y 1004 y cualesquiera otras categorías, carpetas de elementos o elementos (no se muestran) que puedan acceder a la categoría 1000 y que la categoría 1000 es pública y comparte su información de membresía con el elemento 1006. Finalmente, debido a que las categorías y las carpetas de elementos son elementos en sí mismos y los elementos pueden relacionarse entre sí, las categorías pueden relacionarse con las carpetas de elementos y viceversa, y las categorías, carpetas de elementos y elementos pueden relacionarse con otras categorías, carpetas de elementos y elementos respectivamente en ciertas modalidades alternativas. Sin embargo, en diversas modalidades, las estructuras de las carpetas de elementos y/o las estructuras de categorías están prohibidas, en el nivel del sistema de interfaz de los componentes físicos de cómputo y los programas y sistemas de programación, para contener ciclos. En donde la carpeta de elementos y las estructuras de categorías son similares a las gráficas dirigidas, las modalidades que prohiben los ciclos son similares a las gráficas acíclicas dirigidas (DAG) que, a través de una definición matemática en la técnica de ia teoría gráfica, son gráficas dirigidas en donde ningún trayecto inicia o termina en el mismo vértice. 6. Capacidad de extensión La plataforma de almacenamiento tiene la intención de proveer un conjunto inicial de esquemas 340 como se describió anteriormente. Sin embargo, además, en al menos algunas modalidades, la plataforma de almacenamiento permite que los clientes, incluyendo los vendedores de programas y sistemas de programación independientes (ISV), creen nuevos esquemas 344 (es decir, nuevos tipos de elementos y elementos anidados). Esta sección se dirige a los mecanismos para crear dichos esquemas al extender los tipos de elementos y los tipos de elementos anidados (o simplemente tipos de "elementos") definidos en el conjunto inicial de esquemas 340. Preferiblemente, la extensión del conjunto inicial de los tipos elemento y elemento anidado se restringe como se indica a continuación: • se permite que un ISV introduzca nuevos tipos de elementos, es decir el subtipo base.system; · se permite que un ISV introduzca nuevos tipos de elementos anidados, es decir el subtipo base.nestedElement; • se permite que un ISV introduzca nuevas extensiones, es decir el subtipo base.nestedElement; pero, • un ISV no puede subdividir ninguno de los tipos (tipos Item, NestedElement o Extensión) definidos por el conjunto inicial de los esquemas 340 de la plataforma de almacenamiento. Debido a que un tipo de elemento o tipo de elemento anidado definido por el conjunto inicial de los esquemas de la plataforma de almacenamiento puede no corresponder de manera exacta la necesidad de una aplicación ISV, es necesario permitir que las ISV personalicen el tipo. Esto se permite con la noción de las extensiones. Las extensiones son ejemplos clasificados en gran medida, pero (a) no pueden existir de manera independiente y (b) deben anexarse a un elemento o a un elemento anidado. Además de dirigir la necesidad de la capacidad de extensión de los esquemas, las extensiones también tienen la intención de dirigirse a la situación de "tipos múltiples". Debido a que, en algunas modalidades, la plataforma de almacenamiento puede no soportar múltiples subtipos de herencia o traslapantes, las aplicaciones pueden usar extensiones como una manera para modelar los ejemplos de tipos traslapantes (por ejemplo, un documento es un documento legal así como un documento seguro), a) Extensiones del elemento Para proveer una capacidad de extensión al elemento, el modelo de datos además define un tipo abstracto denominado base. extensión. Este es un tipo de raíz para la jerarquía de los tipos de extensión. Las aplicaciones pueden subclasificar base. extensión para crear los tipos de extensión específicos.

El tipo base. extensión se define en el esquema base como se indica a continuación: <Type Name-'Base.Extension" lsAbstract="True"> <Propety ame- 'ItemID" Type="the storage platformTypes.uniqueidentified" Nullable="false" MultiValued="false7> <Property Ñame- 'Extensión ID" Type-'the storage platformTypes.uniqueidentified" NuIIable="false" MultiValued="false'7> </Type> El campo ItemID contiene el identificador del elemento con el que se asocia la extensión. Un elemento con ese identificador de elemento debe existir. La extensión no se puede crear si el elemento con identificador del elemento determinado no existe. Cuando el elemento se elimina, todas las extensiones que tienen el mismo identificador de elemento se eliminan. La tupia (ItemID, ExtensionID identifica de manera exclusiva un ejemplo de extensión). La estructura de un tipo de extensión es similar a la de un tipo de elemento: · los tipos de extensión que tienen campo: • los campos pueden ser de tipos de elementos primitivos o anidados; y • los tipos de extensión pueden tener subtipos. Las siguientes restricciones aplican a los tipos de extensiones. • las extensiones no pueden ser orígenes ni objetivos de las relaciones; • las instancias de los tipos de extensiones no pueden existir de manera independiente de un elemento; y · los tipos de extensiones no se pueden usar como tipos de campos en las definiciones del tipo de plataforma de almacenamiento. No hay restricciones sobre los tipos de extensiones que se pueden asociar con un tipo de elemento determinado. Cualquier tipo de extensión se permite para extender cualquier tipo de elemento. Cuando se anexan múltiples ejemplos de extensiones a un elemento, son independientes entre sí tanto en estructura como en comportamiento. Los ejemplos de extensión se almacenan y se acceden a estos de manera separada desde el elemento. Todos los ejemplos de tipos de extensiones pueden accederse desde un formulario de extensión global. Una consulta eficiente puede componerse de manera que regresarán todos los ejemplos de un tipo determinado de extensión sin importar qué tipo de elementos está asociada a ésta. Las API de la plataforma de almacenamiento proporcionan un modelo de programación que puede almacenar, recuperar y modificar las extensiones de los elementos. Los tipos de extensiones pueden subdividirse usando el modelo de herencia único de la plataforma de almacenamiento. La derivación de un tipo de extensión crea un nuevo tipo de extensión. La estructura o el comportamiento de una extensión no puede anular o reemplazar la estructura o los comportamientos de la jerarquía del tipo de elemento. De manera similar a los tipos de elementos, los ejemplos del tipo de extensión se pueden acceder de manera directa a través de un formulario asociado con el tipo de extensión. El identificador del elemento de la extensión indica a qué elemento pertenecen y se pueden usar para recuperar el elemento correspondiente objetivo desde el formulario del elemento global. Las extensiones se consideran parte del elemento para objetivos de consistencia operativa. Las operaciones comunes como copiar/ mover, respaldar/ restaurar, así como otras, que la plataforma de almacenamiento define pueden operar en las extensiones como parte del elemento. Considere el siguiente ejemplo. Se define un tipo de contacto en el conjunto de tipos de Windows. <Type Name="Contact" BaseType^" Base. Item" > <Property Name-'Name" Type="Str¡ng" Nullable="false" MuItiValued="false"/> <Property Name="Address" Type="Address" Nullable-'true" MultiValued="false"/> </Type> Un desarrollador de una aplicación CRM puede desear anexar una extensión de aplicación CRM a (os contactos almacenados en la plataforma de almacenamiento. El desarrollador de la aplicación puede definir una extensión CRM que puede contener la estructura de datos adicionales que la aplicación puede manipular. <Type Name="CRM Extensión" BaseType^Base.Extension" > <Property Name="CustomerlD" Type="String" Nullable="false" MultiVa!ued="false"/> </Type> Un desarrollador de una aplicación HR puede desear también anexar datos adicionales con el contacto. Estos datos son independientes de los datos de aplicación CRM. Nuevamente el desarrollador de la aplicación puede crear una extensión. <Type Name-'HRExtension" EBaseType-'Base. Extensión" > <Property Name-'EmployeeID" Type="String" Nuilable="fa!se" ultiValued="false"/> </Type> La extensión CR y la extensión HR son dos extensiones independientes que se pueden anexar a los elementos de los contactos. Se crean y se acceden de manera independiente entre sí. En el ejemplo anterior, los campos y los métodos para el tipo CRMExtension no pueden anular los campos o los métodos de la jerarquía de contacto. Debe observarse que los ejemplos del tipo CRMExtension se pueden anexar a los tipos de elementos diferentes a contacto. Cuando el elemento del contacto se recupera, sus extensiones de elemento no se recuperan de manera automática. Dado un elemento de contacto, sus extensiones de elemento relacionadas se pueden acceder mediante una consulta al formulario de extensión global en cuanto a las extensiones con el mismo identificador de elemento. Todas las extensiones CRMExtension en el sistema pueden accederse a través del formulario del tipo CRMExtension, sin tomar en cuenta a qué elemento pertenecen. Todas las extensiones de elemento de un elemento comparten el mismo identificador de elemento. En el ejem plo a nterior, el ejemplo de elemento de contacto y los ejempl os de C RM Extension H RExtension anexos representa n el m ismo identifi cador d el elemento. La sig u iente tabla resume l as sim ilitudes y las diferencias entre los ti pos I tem , Extensió n y Nested EIement: TABLA 1 Elemento vers us Extens ión del elemento vers us Elemento an idado Elemento Extensión del Elemento anidado elemento Identificador del Tiene su propio Comparte el No tiene su propio elemento identificador de elemento identificador de identificador de elemento elemento. El elemento anidado es parte del elemento Almacenamiento La jerarquía del elemento La jerarquía de la Se almacena con el se almacena en sus extensión del elemento propias tablas elemento se almacena en sus propias tablas Consulta/ Puede consultar las Puede consultar las Generalmente puede búsqueda tablas del elemento tablas de extensión ser consultado del elemento únicamente dentro del contexto del elemento que lo contiene Alcance de Puede buscar entre Puede buscar a Generalmente sólo búsqueda/ todas las instancias de través de todas las puede buscar dentro de consulta un tipo de elemento instancias de un tipo las instancias del tipo de extensión de de elemento anidado elemento de un elemento que lo contiene Semánticas de la Puede tener relaciones No tiene relación con No tiene relación con relación con los elementos las extensiones de los los elementos anidados elementos Asociación con Se puede relacionar con Generalmente sólo se Se relaciona con el elementos otros elementos a través puede relacionar a elemento a través de de mantener, incrustar y través de las los campos. Los relaciones directas extensiones. La elementos anidados semántica de la son parte del elemento extensión es similar a la semántica del elemento incrustado b) Extensión de los tipos elemento anidados Los tipos de elementos anidados no se extienden con el mismo mecanismo que los tipos de los elementos. Las extensiones de los elementos anidados se almacenan y son accede a ellos con los mismos mecanismos que los campos de los tipos de los elementos anidados. El modelo de datos define una raíz para los tipos de elemento anidado denominado Elemento: <Type Name-'Element" lsAbstract="True"> <Property Name="ElementiD" Type="lhe storage platformTypes.uniqueidentifier" Nullable="false" MultiVaiued="fals8"/> </Type> El tipo NestedElement se hereda de este tipo. El tipo de elemento NestedElement adicionalmente define un campo que es un conjunto múltiple de elementos. <Type Name="NestedElement" BaseType-'Base.Element" lsAbstract="True"> <Property Name-'Extensions" Type-'Base.Element" Nullab!e="falsen MultiValued="true"/> <Type> Las extensiones del tipo NestedElement son diferentes de las extensiones del elemento de la siguiente forma: • Las extensiones del elemento anidado no son tipos de extensiones. No pertenecen a la jerarquía del tipo de extensión que está originada en el tipo Base. Extensión. • Las extensiones del elemento anidado se almacenan junto con los otros campos del elemento y no se puede tener acceso a estos globalmente, no se puede tener una consulta que recupere todas las instancias de un tipo de extensión determinado. • Estas extensiones se almacenan de la misma manera que se almacenan otros elementos anidados (del elemento). Como otros conjuntos anidados, las extensiones NestedElement se almacenan en un UVT. Se puede tener acceso a éstas a través del campo Extensions del tipo del elemento anidado. • Las interfaces de la colección que se usan para acceder a las propiedades de valores múltiples también se usa para acceder y reiterar un conjunto de extensiones del tipo. La siguiente tabla resume y compara las extensiones Item y las extensiones NestedElement.

TABLA II Extensiones del elemento versus extensiones del elemento anidado F. MOTOR DE LA BASE DE DATOS Como se mencionó en párrafos anteriores, el almacén de datos se implementa en un motor de una base de datos. En la presente modalidad, el motor de la base de datos comprende un motor de una base de datos de relación que implementa el lenguaje de consulta SQL, como el motor del servidor SQL de Microsoft, con extensiones relaciónales de objeto. Esta sección describe la correlación del modelo de datos que el almacén de datos implementa con el almacén relacional y provee información en la API lógica consumida por los clientes de la plataforma de almacenamiento, de conformidad con la presente invención. Sin embargo, se comprende que se puede emplear una correlación diferente cuando se emplee un motor de base de datos diferente. En su lugar, además de la implementación del modelo de datos conceptual de la plataforma de almacenamiento en un motor de base de datos relacional, también se puede implementar en otros tipos de bases de datos, por ejemplo, orientados por objeto y bases de datos XML. Un sistema de la base de datos orientada por objeto (OO) proporciona una persistencia en las transacciones para programar objetos de lenguaje (por ejemplo C + + , JAVA). La noción de la plataforma de almacenamiento de un "elemento" se correlaciona bien con un "objeto" en los sistemas orientados por objeto, aunque las colecciones incrustadas deberán ser añadidas a Jos objetos. Otros conceptos de los tipos de plataforma de almacenamiento, como los tipos de elemento anidado y de herencias, también correlacionan los sistemas del tipo orientado por objeto. Los sistemas orientados por objeto típicamente ya soportan la identidad del objeto; por lo tanto, se puede correlacionar la identidad del elemento con la identidad del objeto. Los comportamientos del elemento (operaciones) se correlaciona bien con los métodos del objeto. Sin embargo, los sistemas orientados por objeto típicamente no cuentan con capacidades de organización y tienen una mala búsqueda. De igual manera, los sistemas orientados por objeto no proveen soporte para datos no estructurados y semiestructurados. Para soportar el modelo de datos de plataforma de almacenamiento completo que se describe en la presente, los conceptos como relaciones, carpetas y extensiones no deben añadirse al modelo de datos de objeto. Además, será necesario implementar mecanismos como promociones, sincronización, notificaciones y seguridad. De manera similar a los sistemas orientados por objeto, las bases de datos XML, basadas en XSD (definición del esquema XML), soportan un sistema de tipo basado en una sola herencia. El sistema de tipo elemento de la presente invención se puede correlacionar con el modelo de tipo XSD. Los XSD tampoco proporcionan soporte para los comportamientos. Los XSD para los elementos deberán aumentarse con los comportamientos del elemento. Las bases de datos XML lidian con documentos uncios XSD y no cuentan con buenas capacidades de organización y búsqueda amplia. Como con las bases de datos orientadas por objeto, para soportar el modelo de datos descrito en la presente, otros conceptos como relaciones y carpetas será necesario que sean incorporadas en las bases de datos como XML; también, los mecanismos como la sincronización, notificaciones y seguridad será necesario que sean implementadas. Con respecto a las siguientes subsecciones, se proporcionan algunas ilustraciones para facilitar la información general que se describe: la figura 13 es un diagrama que ilustra un mecanismo de notificación. La figura 14 es un diagrama que ¡lustra un ejemplo en donde dos transacciones insertan un nuevo registro en el mismo árbol B. La figura 15 ¡lustra un proceso de detección de cambio de datos; la figura 16 ¡lustra un árbol directorio ejemplar. La figura 17 muestra un ejemplo en donde una carpeta existente de un sistema de archivos basado en un directorio se mueve en un almacén de datos de la plataforma de almacenamiento. 1. Implementación del almacén de datos usando UDT En la presente modalidad, el motor de la base de datos relacional 314, el que en una modalidad comprende el motor del servidor de SQL de Microsoft, soporta los tipos escalares integrados. Los tipos escalares integrados son "nativos" y "simples". Son nativos en el sentido de que el usuario no puede definir sus propios tipos y son simples porque no pueden encapsular una estructura compleja. Los tipos definidos por el usuario (denominados a partir de ahora: UDT) proporcionan un mecanismo para la capacidad de extensión del tipo anterior sobre y más allá del sistema tipo escalar nativo al habilitar a los usuarios para que extiendan el sistema de tipo al definir tipos estructurados y complejos. Una vez definidos por un usuario, un UDT se puede usar en cualquier momento en el sistema tipo que puede usar un tipo escalar integrado. De conformidad con un aspecto de la presente invención, los esquemas de la plataforma de almacenamiento se correlacionan con las clases de UDT en el almacén del motor de la base de datos. Los elementos del almacén de datos se correlacionan con las clases de UDT que se derivan del tipo Base. Item. Como los elementos, las extensiones también se correlacionan las clases de UDT y usan la herencia. El tipo de extensión de raíz es Base. Extensión, desde la cual se derivan todos los tipos de extensiones. Un UDT es una clase CLR, tiene un estado (por ejemplo campos de datos) y comportamiento (es decir, rutina). Los UDT se definen usando cualquiera de los lenguajes administrados-C#, VB.NET, etc. Los métodos de UDT y sus operadores se pueden invocar en T-SQL en comparación con una instancia de dicho tipo. Un UDT puede ser: el tipo de una columna en una fila, el tipo de un parámetro de una rutina en T-SQL, o el tipo de una variable en T-SQL. La correlación de los esquemas de la plataforma de almacenamiento con las clases de UDT es bastante franco en un nivel superior. Generalmente, un esquema de plataforma de almacenamiento se correlaciona con un espacio de nombre (CLR). Un tipo de plataforma de almacenamiento se correlaciona con una clase de CLR. La clase CLR hereda reflejos de la herencia del tipo de plataforma de almacenamiento y se correlaciona una propiedad de la plataforma del almacenamiento con una propiedad de la clase CLR. 2. Correlación de elementos Dado el atractivo de los elementos para que puedan buscarse globalmente y el soporte en la base de datos relacional de la presente modalidad para la herencia y capacidades de institución del tipo, una implementación posible para el almacenamiento de elementos en el almacén de base de datos sería almacenar todos los elementos en una sola tabla con una columna del tipo Base. Item. Usando el tipo de capacidad de sustitución, los elementos de todos los tipos se pueden almacenar y las búsquedas se pueden filtrar por el tipo de elemento y el subtipo usando el operador de Yukon "es del (tipo)". Sin embargo, a los asuntos relacionados con la sobrecarga asociada con dicho enfoque, en la presente modalidad, los elementos se dividen por tipo de nivel superior, dichos elementos de dicho tipo "familia" se almacenan en una tabla separada. Bajo este esquema de división, se crea una tabla para cada tipo de elemento que se hereda directamente desde Base. Item. Los tipos que se heredan a continuación se almacenan en la tabla de familia del tipo apropiado usando la capacidad de sustitución del tipo, como se describió anteriormente. Sólo el primer nivel de herencia del Base. Item se trata de manera especial. Se usa una tabla "sombra" para almacenar copias de las propiedades que pueden ser buscadas globalmente para todos los elementos. Esta tabla se puede mantener a través del método de actualización Update() de la API de la plataforma de almacenamiento, a través de la cual se hacen todos los cambios a los datos. A diferencia de las tablas de la familia de tipo, esta tabla de elemento global contiene sólo las propiedades escalares de nivel superior del elemento, no el objeto del elemento UDT completo. La tabla de elementos global permite la navegación hacia el objeto del elemento almacenado en una tabla de familia de tipo mediante la exposición de un identificador de elemento y un identificador de tipo. El identificador del elemento generalmente identificará de manera exclusiva el elemento dentro del almacén de datos. El identificador de tipo se puede correlacionar usando los metadatos, que no se describen en la presente, con un nombre de tipo y el formulario que contiene el elemento. Debido a que el hallazgo de un elemento a través de su identificador del elemento puede ser una operación común, tanto en el contexto de la tabla del elemento global y de otra manera, una función de obtener elemento GetltemQ se provee para recuperar un objeto del elemento determinando un identificador de elemento para este elemento. Para un cómodo acceso y para ocultar los detalles de la implementación en el grado de lo posible, todas las consultas de los elementos pueden hacerse en contra de los formularios integrados en las tablas de elementos descritas anteriormente. Específicamente, las listas se pueden crear para cada tipo de elemento en contra de la tabla de familia de tipo adecuado. Esos formularios de tipo pueden seleccionar todo los elementos de tipo asociado, incluyendo los subtipos. Por comodidad, además del objeto de UDT, las listas pueden exponer columnas para todos los campos de nivel superior de dicho tipo, incluyendo los campos heredados. 3. Correlación de extensiones Las extensiones son muy similares a los elementos y tienen algunos de los mismos requerimientos. Como otro tipo de raíz que soporta la herencia, las extensiones están sujetas a muchas de estas mismas consideraciones e intercambios en el almacenamiento. Debido a esto, una correlación familiar de tipo familiar se aplica a las extensiones, en lugar de un solo enfoque de tabla. Desde luego, en otras modalidades, se puede usar otro enfoque de tabla única. En la presente modalidad, se asocia una extensión con exactamente un elemento a través del identificador del elemento y contiene un identificador de extensión que es exclusivo en el contexto del elemento. Como con los elementos, se debe proveer una función para recuperar una extensión dada su identidad, lo que consiste en un par de identificador de elemento e identificador de extensión. Se crea un formulario para cada tipo de extensión, similar a los formularios del tipo de elemento. 4. Correlación de elementos anidados Los elementos anidados son tipos que se pueden incrustar en los elementos, extensiones, relaciones y otros elementos anidados para formar estructuras anidadas más profundamente. Como en los elementos y las extensiones, los elementos anidados se implementan como UDT, pero se almacenan dentro de un elemento y extensión. Por lo tanto, los elementos anidados no tienen una correlación de almacenamiento más allá de sus contenedores de elemento y extensión. En otras palabras, no hay tablas en el sistema que almacenan de manera directa las instancias de los tipos NestedElement, y no hay formularios dedicados específicamente a los elementos anidados. 5. Identidad del objeto Cada entidad en el modelo de datos, es decir, cada elemento, cada extensión y cada relación, tiene un valor clave único. Un elemento se identifica de manera exclusiva por su propio identificador de elemento. Una extensión se identifica de manera exclusiva a través de una clave compuesta de (identificador del elemento, identificador de la extensión). Una relación se identifica a través de una clave compuesta (identificador del elemento, identificador de la relación). ItemID, ExtensionID y RelationID son valores de GUID. 6. Denominación de objetos de SQL Todos los objetos creados en el almacén de datos se pueden almacenar en un nombre de esquema SQL derivados del nombre del esquema de la plataforma de almacenamiento. Por ejemplo, el esquema base de la plataforma de almacenamiento (con frecuencia denominado "base") puede producir tipos en el esquema "[System. Storage]" SQL, por ejemplo "[System. Storage]. Item. Los nombres generados tienen un prefijo a través de un calificador para eliminar los conflictos de denominación. Cuando es adecuado, se usa un signo de admiración (¡) como un separador para cada parte lógica del nombre. La tabla a continuación señala las convencionalismos de denominación usadas para los objetos en el almacén de datos. Cada elemento del esquema (Item, Extensión, Relationship y View), se enumera junto con las convencionalismos de denominación decoradas usadas para acceder a las instancias en el almacén de datos.

TABLA III 7. Denominación de columnas Cuando se correlaciona cualquier modelo de objeto en un almacén, la posibilidad de las coaliciones de denominaciones se producen debido a una información adicional almacenada junto con un objeto de la aplicación. Para evitar las coaliciones de denominación, todas las columnas específicas sin tipo (columnas que no correlacionan directamente con la propiedad denominada en una declaración de tipo) recibe un prefijo con un carácter de guión bajo (_). En la modalidad que se presenta, los caracteres de guión bajo (_) están inhabilitados como el carácter de inicio de cualquier propiedad del identificador. Adicionalmente, para unificar la denominación entre CLR y el almacén de datos, todas las propiedades de los tipos de la plataforma de almacenamiento o del elemento de esquema (relación, etc.) deben tener un primer carácter en mayúscula. 8. Formularios de búsqueda Los formularios se proporcionan mediante la plataforma de almacenamiento para buscar el contenido almacenado. Un formulario SQL se proporciona para cada tipo de elemento y extensión. Adicionalmente, los formularios se proporcionan para soportar las relaciones y los formularios (como se define por el modelo de datos). Todos los formularios SQL y las tablas subyacentes en la plataforma de almacenamiento son de sólo lectura. Los datos se pueden almacenar o cambiar usando el método de actualización Update() de la API de la plataforma de almacenamiento, como se describe con mayor detalle a continuación. Cada formulario definido explícitamente en un esquema de plataforma de almacenamiento (definida por el diseñador del esquema, y no generada automáticamente por la plataforma de almacenamiento) se puede tener acceso a ésta a través del formulario SQL denominado [<schema-name>]. [View!<view-name>]. Por ejemplo, se puede tener acceso al formulario denominado "ventadelibros" en el esquema "publicacionesacme. libros" usando el nombre "[publicacionesacme.Iibros].[Formulario!ventadelibros]". Debido a que el formato de resultados de un formulario se personaliza por cada formulario (definido por una consulta arbitraria proporcionada por la parte que define al formulario), las columnas se correlacionan directamente con base en la definición del formulario del esquema. Todos los formularios de búsqueda de SQL en el almacén de datos de la plataforma de almacenamiento usan los siguientes convencionalismos de orden para las columnas: • Columnas "clave" lógicas de los resultados del formulario como Itemld, Elementld, Reltionshipld,... • Información de los metadatos en el tipo de resultados como Typeld • Cambio de las columnas de seguimiento como CreateVersion, UpdateVersion , ... · Columnas específicas del tipo (propiedades del tipo declarado) • Formularios específicos del tipo (formularios de familia) también contienen una columna de objeto que devuelve el objeto. Los miembros de cada tipo de familia pueden buscarse usando una serie de formularios de elementos, contando con un formulario por tipo de elemento en el almacén de datos. La figura 28 es un diagrama que ilustra el concepto de un formulario de búsqueda de elemento. a) Elemento Cada formulario de búsqueda de elemento (Item) contiene una fila para cada instancia de un elemento del tipo específico o sus subtipos. Por ejemplo, el formulario para el documento puede devolver instancias de documento, documento legal y documento de revisión. Dado este ejemplo, los formularios de los elementos se pueden estimar como se muestra en la figura 29. (1) Formulario maestro de búsqueda de elementos Cada instancia de un almacén de datos de la plataforma de almacenamiento define un formulario especial del elemento denominado formulario de elemento maestro. Este formulario proporciona información de resumen de cada elemento en el almacén de datos. El formulario proporciona una columna por propiedad de tipo de elemento, una columna que describe el tipo de elemento y diversas columnas que se usan para proveer el seguimiento de los cambios además de información de sincronización. El formulario del elemento maestro se identifica en un almacén de datos usando el nombre "[System. Storage].[Master!ltem]".

TABLA IV (2) Formularios de búsqueda de elementos por tipo Cada tipo de elemento tiene un formulario de búsqueda. Aunque es similar al formulario del elemento de origen, este formulario también proporciona acceso al objeto del elemento a través de la columna "_ltem". Cada formulario de búsqueda del elemento clasificado se identifica en un almacén de datos que usa el nombre [SchemaName].[itemTypeName]. Por ejemplo [AcmeCorp.Doc].[OfficeDoc]. TABLA V Columna Tipo Descripción Itemld Identificador del elemento La identidad de la plataforma de almacenamiento del elemento <seguimiento de cambios Información del seguimiento del por tipo> cambio del tipo <propiedades de origen> <específico de propiedad> Una columna por propiedad origen <propiedades del elemento> <específico de propiedad> Una columna por propiedad exclusiva de este tipo Jtem Tipo de CLR del elemento Objeto CLR-tipo del elemento declarado b) Extensiones del elemento Todas las extensiones del elemento en un almacén WinFS también son accesibles usando formularios de búsqueda. (1) Formulario maestro de búsqueda de extensiones Cada instancia de un almacén de datos define un formulario de extensión especial denominado formulario de extensión maestra. Este formulario proporciona información de resumen en cada extensión en el almacén de datos. El formulario tiene una columna por propiedad de la extensión, una columna que describe el tipo de la extensión y diversas columnas que se usan para proveer el seguimiento de los cambios y la información de sincronización. El formulario de la extensión maestra se identifica en un almacén de datos que usa el nombre "[System. Storage].[Master!Extensión]". TABLA VI Columna Tipo Descripción ltemld Identificador del elemento La identidad de la plataforma de almacenamiento del elemento con el que esta extensión está asociada.

Extensionld Identificador de la extensión Identificador de esta instancia de (GUID) extensión _Typeld Identificador del tipo El identificador del tipo de extensión identifica el tipo exacto de la extensión y se puede usar para recuperar información en la extensión usando el catálogo de metadatos. <seguimiento de Información del seguimiento de cambios globales> cambios globales <prop¡edades de <específico de la propiedad> Una columna por cada propiedad del extensión> tipo de extensión (2) Formularios de búsqueda de extensión por tipo Cada tipo de extensión también tiene un formulario de búsqueda. Aunque es similar al formularlo de extensión maestra, este formularlo también proporciona acceso al objeto del elemento a través de la columna _extensión. Cada formulario de búsqueda de extensión por tipo se identifica en un almacén de datos usando el nombre [sc7e/T7a/Va/77e].[Extension!e íens/'o/JíypeA/an7e]. Por ejemplo [AcmeCorp.Doc].[Extension!OfficeDocExt]. TABLA VII c) Elementos anidados Todos los elementos anidados se almacenan dentro de las instancias elementos, extensiones o relaciones. De esta manera, se puede tener acceso a estos al consultar el formulario de búsqueda adecuado de elemento, extensión o relación. d) Relaciones Como se analizó anteriormente, las relaciones forman la unidad fundamental de enlace entre los elementos en un almacén de datos de la plataforma de almacenamiento. (1) Formulario maestro de búsqueda de relaciones Cada almacén de datos proporciona un formulario de relación maestra. Este formulario proporciona información sobre todas las instancias de relación en el almacén de datos. El formulario de la relación maestra se identifica en un almacén de datos usando el nombre "[System.Storage].[Master!Relationship]". TABLA VIII (2) Formularios de búsqueda de instancias de relación Cada relación declarada también tiene un formulario de búsqueda que devuelve todas las instancias de la relación particular. Aunque es similar al formulario de la relación maestra, este formulario también proporciona columnas denominadas para cada propiedad de los datos de la relación. Cada formulario de búsqueda de la instancia de relación se identifica en un almacén de datos usando el nombre [schemaName].[Re\ations ip\realtioshipName]. Por ejemplo [AcmeCorp.Doc].[Relationship!DocumentAuthor]. TABLA IX e) 9 Actualizaciones Todos los formularios en el almacén de datos de la plataforma de almacenamiento son de sólo lectura. Para crear una nueva instancia de un elemento de modelo de datos (elemento, extensión o relación), o para actualizar una instancia existente, los métodos de operación de procesos o de actualización de procesos de la API de la plataforma de almacenamiento se deben usar. El método de operación del proceso es un procedimiento de almacenamiento único definido por el almacén de datos que consume una "operación" que detalla una acción que será realizada. El método de actualización de procesos es un procedimiento almacenado que desarrolla un conjunto ordenado de operaciones, conocido como un "drama de actualización", que detalla de manera colectiva un conjunto de acciones que serán realizadas. El formato de la operación puede extenderse y proporciona diversas operaciones sobre los elementos del esquema. En algunas operaciones comunes se incluye: 1 operaciones en el elemento: 1. Operaciones del elemento: a. Crearelemento (crea un nuevo elemento dentro del contexto de una relación de incrustación o propiedad) b. Actualizarlemento (actualiza un elemento existente) 2 Operaciones de la relación: a. Crearrelación (crea una instancia de una propiedad de referencia o de propiedad) b. Actualizarrelación (actualiza una instancia de relación) c. Borrarrelación (retira una instancia de relación) 3. Operaciones de la extensión: a. Crearextensión (añade una extensión a un elemento existente) b. Actualizarextensión (actualiza una extensión existente) c. Borrarextensión (borra una extensión) 10. Seguimiento de cambios y lápidas Los servicios de seguimiento de cambios y lápidas se proporcionan mediante el almacén de datos, como se analiza con mayor detalle a continuación. Esta sección proporciona un esquema de la información de seguimiento de cambios expuestos en un almacén de datos. a) Seguimiento de cambios Cada formulario de búsqueda proporcionado por el almacén de datos contiene columnas que se usan para proveer información de seguimiento de cambios; las columnas son comunes entre todos los formularios de elemento, extensión y relación. Los formularios del esquema de la plataforma de almacenamiento, que se definen explícitamente mediante los diseñadores de esquemas, no proporcionan de manera automática información del seguimiento de cambios, como la información que se provee de manera indirecta a través de los formularios de búsqueda en donde se construye el mismo formulario. Para cada elemento dentro del almacén de datos, la información del seguimiento de los cambios está disponible en dos lugares, el formulario del elemento "maestro" y el formulario del elemento "clasificado". Por ejemplo, la información de seguimiento de cambios en el tipo de elemento AcmeCorp.Document está disponible en el formulario del elemento maestro "[System. Storage]. [Master! Item] y el formulario de búsqueda de elemento clasificado [AcmeCorp.Document].[Document]. (1) Seguimiento de cambios en formularios "maestros" de búsqueda La información del seguimiento de cambios en los formularios de búsqueda maestra proporciona información sobre las versiones de creación y actualización de un elemento, la información sobre el compañero sincronizado creado en el elemento, cuyo compañero sincronizado actualizó por última vez el elemento y los números de versión para cada compañero para creación y actualización. Los compañeros en las relaciones de sincronización (descritas a continuación) se identifican a través de una clave de compañero. Usando un objeto UDT único denominado _ChangeTrackinglnfo del tipo [System. Sorage. Store]. ChangeTrackinglnfo contiene toda esta información. El tipo se identifica en el System. Storageschema. El campo _ChangeTrackinglnfo está disponible en todos los formularios de búsqueda globales por elemento, extensión y relación. La definición del tipo de ChangeTrackingl nfo es: <Type Name="ChangeTrackingInfo" BaseType="Base.NestedElement"> <F±eldProperty Name="CreationLocalTS" Type="SqlTypes . Sqllnt64" Nullable="False" /> <FieldProperty Name="CreatingPartnerKey" Type="SqlTypes.SqlInt32" Nullable="False" /> <F.i.eldPropert:y Name="CreatingPartnerTS" Type="SqlTypes.SqlInt64" Nullable="False" /> <FieldProperty Name="LastUpdateLocalTS" Type="SqlTypes.SqlInt64" Nullable="False" /> <FieldProperty Name="LastUpdatingPartner ey" Type="SqlTypes.SqIInt32" Nullable="False" /> <FieldProperty Name="LastUpdatingPartnerTS" Type="SqlTypes SalIn<-64" Nullable="False" /> </Type> Estas propiedades contienen la siguiente información: TABLA X (2) Seguimiento de cambios en formularios de búsqueda "por tipo" Además de proveer la misma información que en el formulario de búsqueda global, cada formulario de búsqueda clasificada proporciona información adicional que registra el estado de sincronización de cada elemento en la topología de sincronización . TABLA XI b) Lápidas El almacén de datos proporciona información sobre las lápidas para los elementos, extensiones y relaciones. Los formularios de las lápidas proporcionan información sobre las entidades lapidadas y activas (elementos, extensiones y relaciones) en un lugar. Los formularios de lápidas del elemento y extensión no proporcionan acceso al objeto correspondiente, aunque el formulario de las lápidas de la relación proporcionan acceso al objeto de relación (el objeto de relación es NULO en caso de una relación lapidada). (1) Lápidas de elementos Las lápidas del elemento se recuperan del sistema a través del formulario [System. Storage].[Tombstone!ltem] TABLA XII (2) Lápidas de extensiones Las lápidas de extensión se recuperan del sistema usando el formulario [System. Storage].[Tombstone!Extension]. La información de seguimiento del cambio de extensión es similar a la que se provee para los elementos con la adición de la propiedad de Extensionld.

TABLA XIII (3) Lápida de relaciones Las lápidas de las relaciones se recuperan del sistema a través del formulario [System. Storage].[Tombstone!ReIat¡onship]. La información sobre las lápidas de las relaciones son similares a las que se proveen para las extensiones. Sin embargo, se proporciona información adicional en el campo ItemRef objetivo de la instancia de relación. Además, el objeto de relación también se selecciona.

TABLA XIV (4) Limpieza de lápidas Para evitar el crecimiento ilimitado de la información de las lápidas, el almacén de datos proporciona una tarea de limpieza de lápidas. Esta tarea determina cuando la información de la lápida se puede desechar. La tarea computa un límite en la versión de actualización/ creación local y después trunca la información de lápidas desechando todas las versiones de tumbas anteriores. 11. Funciones e interfaces de programas de aplicación (API) de ayuda La correlación base también proporciona un número de funciones de ayuda. Estas funciones se proveen para ayudar a las operaciones comunes sobre el modelo de datos. a) Función [System. Storage].Getltem Devuelve a un objeto de elemento determinado un identificador del elemento // Item Getltem (Itemld Itemld) b) Función [System. Storagej.GetExtension // Devuelve a un objeto de extensión determinado un identificador de elemento (ItemID) y un identificador de extensión (Extensionld) // Extensión GetExtension (Itemld Itemld, Extensionld Extensionld) c) Función [System. StorageJ.GetRelationship // Devuelve a un objeto de extensión determinado un identificador de elemento (ItemID) y un identificador de relación (Relationshipld) // Relationship GetRelationship (Itemld Itemld, Relationshipld Relationshipld) 12 Metadatos Hay dos tipos de metadatos representados en el almacén: Metadatos de la instancia (del tipo de un elemento), etc. y metadatos de tipo. a) Metadatos de esquema Los metadatos de esquema se almacenan en el almacén de datos como instancia de los tipos de los elementos del meta esquema. b) Metadatos de instancia Los metadatos de instancia se usan mediante una aplicación para consultar el tipo de un elemento y encuentra las instrucciones asociadas con un elemento. Dado el Itemld para un elemento, una aplicación puede consultar el formulario de elementos global para devolver el tipo de un elemento y usa este valor para consultar el formulario de meta-tipo para devolver una información en el tipo declarado del elemento. Por ejemplo: // Return metadata Item object for given Item instance // SELECT m.Jtem AS metadatalnfoObj FROM [System.Storage].[ltem] i INNER JOIN [Meta].[Type] m ON i. Typeld = m Itemld WHERE ¡.Itemld = @ltemld G. SEGURIDAD En general, todos los objetos que pueden asegurarse disponen sus derechos de acceso usando el formato de máscara de acceso que se muestra en la figura 26. En este formato, los 16 bits de orden bajo son para derechos de acceso específicos por objeto, los siguientes 7 bits son para los derechos de acceso estándar, los cuales se aplican a la mayoría de los tipos de objetos y los cuatro bits de orden se pueden usar para especificar los derechos de acceso genéricos que cada tipo de objeto puede correlacionar con un conjunto de derechos específicos de objeto y estándares. El bit ACCES_SYSTEM_SECURITY corresponde al derecho de acceder al SACL del objeto. En la estructura de máscara de acceso de la figura 26, los derechos específicos para elemento se colocan en la sección de derechos específicos de objeto (16 bits de orden inferior). Debido a que en la presente modalidad la plataforma de almacenamiento expone dos conjuntos de API para administrar la seguridad, Win32 y la API de la plataforma de almacenamiento, los derechos específicos de objeto para el sistema de archivos se deben considerar para motivar el diseño de los derechos específicos para el objeto de la plataforma de almacenamiento. El modelo de seguridad para la plataforma de almacenamiento de la presente invención se describe en la solicitudes relacionadas incorporadas por referencia anteriormente en la presente. Con este respecto, la figura 27 (partes a, b y c) ilustra una nueva región de seguridad protegida de manera idéntica que se hace a partir de una región definida existente, de conformidad con una modalidad del modelo de seguridad.

H. SEGUIMIENTO DE CAMBIOS Y NOTIFICACIONES De conformidad con otro aspecto de la presente invención, la plataforma de almacenamiento proporciona una capacidad de notificaciones que permite que las aplicaciones rastreen los cambios de los datos. Esta funcionalidad principalmente se creó para las aplicaciones que mantienen un estado no permanente o ejecutan una lógica comercial en los eventos de cambio de datos. Las aplicaciones se registran para las notificaciones en los elementos, extensiones de elementos y relaciones de elementos. Las notificaciones se entregan de manera asincrona después de que los cambios de los datos se realizan. Las aplicaciones pueden centrar notificaciones por elemento, expresión y tipo de relación así como por tipo de operación. De conformidad con una modalidad, la API 322 de la plataforma de almacenamiento proporciona dos tipos de interfaces para las notificaciones. En primer lugar, las aplicaciones se registran para los eventos de cambios de datos simples activados por los cambios a los elementos, las extensiones de los elementos y las relaciones de los elementos. En segundo lugar, las aplicaciones crean objetos "observadores" para supervisar conjuntos de elementos, extensiones de elementos y relaciones entre los elementos. El estado de un objeto observador se puede guardar y volver a crearse después de la falla de un sistema o después de que el sistema salga de línea durante un periodo largo. Una sola notificación puede reflejar diversas actualizaciones. Los detalles adicionales con respecto a esta funcionalidad se pueden encontrar en las solicitudes relacionadas incorporadas en la presente por referencia en principio de este documento. I. SINCRONIZACIÓN De conformidad con otro aspecto de la presente invención, la plataforma de almacenamiento proporciona un servicio de sincronización 330 que (1) permite que múltiples instancias de la plataforma de almacenamiento (cada una con su propio almacén de datos 302) sincronice partes de su contenido de conformidad con un conjunto flexible de reglas, y (2) proporciona una infraestructura para terceras partes para sincronizar el almacén de datos de la plataforma de almacenamiento de la presente invención con otras fuentes de datos que implementan protocolos propietarios. La sincronización de plataforma de almacenamiento a plataforma de almacenamiento se produce entre un grupo de réplicas participantes. Por ejemplo, con referencia a la figura 3, puede ser deseable proveer la sincronización entre el almacén de datos 302 de la plataforma de almacenamiento 300 con otro almacén de datos 338 remoto bajo el control de otra instancia de la plataforma de almacenamiento, tal vez que se ejecuta en un sistema de cómputo diferente. La membresía total de este grupo no necesariamente se conoce en ninguna réplica determinada en algún momento. Las réplicas diferentes pueden hacer cambios de manera independiente es decir, de manera concurrente. El proceso de sincronización se define haciendo consiente cada réplica de los cambios hechos por otras réplicas. Esta capacidad de sincronización es inherentemente de varios maestros. La capacidad de sincronización de la presente invención permite réplicas para: · Determinar los cambios que conoce otra réplica; • Solicitar información sobre los cambios que esta réplica no conoce; • Transportar información sobre los cambios que la otra réplica no conoce; · Determinar cuando dos cambios están en conflicto entre sí; • Aplicar cambios localmente; • Transportar resoluciones de conflictos a otras réplicas para asegurar la convergencia; y · Resolver los conflictos con base en las políticas especificadas para las resoluciones de los conflictos. 1. Sincronización de plataforma de almacenamiento - plataforma de almacenamiento La aplicación primaria del servicio de sincronización 330 de la plataforma de almacenamiento de la presente invención es sincronizar múltiples instancias de la plataforma de almacenamiento (cada una con su propio almacén de datos). El servicio de sincronización funciona en el nivel de los esquemas de la plataforma de almacenamiento (en lugar de tablas subyacentes del motor de la base de datos 314). De esta manera, por ejemplo, "enfoques" se usa para definir los conjuntos de sincronización como se analiza a continuación. El servicio de sincronización funciona bajo el principio de "cambios netos". En lugar de registrar y enviar operación individual (como con la réplica transaccional), el servicio de sincronización envía el resultado final de las operaciones, de esta manera consolidando con frecuencia los resultados de las operaciones múltiples en un cambio único resultante. El servicio de sincronización no respeta los límites de transacción en general. En otras palabras, si se hacen dos cambios en un almacén de datos de la plataforma de almacenamiento en una sola transacción, no existe una garantía de que estos cambios se apliquen a todas las réplicas de manera automática, una puede aparecer sin la otra. La excepción a este principio es que si dos cambios se hacen en el mismo elemento en la misma transacción, entonces estos cambios se garantiza que se enviarán y aplicarán a otras réplicas de manera automática. De esta manera, los elementos son las unidades de consistencia del servicio de sincronización. a) Aplicaciones de control de sincronización (Sync) Cualquier aplicación se puede conectar al servicio de sincronización e iniciar una operación de sincronización. Tal aplicación proporciona todos los parámetros necesarios para realizar la sincronización (véase el perfil Sync a continuación). Tales aplicaciones se denominan en la presente como aplicaciones de control de sincronización (SCA). Cuando se sincronizan dos instancias en una plataforma de almacenamiento, se inicia la sincronización en un lado mediante las SCA. Dichas SCA informan al servicio de sincronización local que debe sincronizarse con el compañero remoto. Del otro lado, el servicio de sincronización recibe una alerta a través de un mensaje enviado por el servicio de sincronización desde la máquina de origen. Responde con base a la información de configuración persistente (véase correlaciones a continuación) presente en la máquina de destino. El servicio de sincronización se puede ejecutar programado o como respuesta a diversos eventos. En estos casos, el servicio de sincronización que implementa la programación se convierte en la SCA. Para habilitar la sincronización, es necesario tomar dos pasos. Primero, el diseñador de esquemas debe anotar el esquema de la plataforma de almacenamiento con la semántica de sincronización adecuada (designar las unidades de cambio como se describe a continuación). En segundo lugar, la sincronización debe considerarse de manera adecuada en todas las máquinas que tienen una instancia de la plataforma de almacenamiento que participan en la sincronización (como se describe a continuación). b) Anotación de esquemas Un concepto fundamental de los servicios de sincronización es el de una unidad de cambio. Una unidad de cambio es la pieza más pequeña del esquema que se rastrea de manera individual a través de la plataforma de almacenamiento. Para cada una de las unidades de cambio, el servicio de sincronización puede estar disponible para determinar si cambió o no cambió desde la última sincronización. La designación de unidades de cambio en el esquema tiene múltiples propósitos. Primero, determina qué cantidad de información contiene el servicio de sincronización en el cable. Cuando se hace un cambio dentro de una unidad de cambio, la unidad de cambio completa se envía a las otras réplicas, ya que el servicio de sincronización no conoce qué parte de la unidad de cambio fue cambiada. En segundo lugar, determina la granularidad de la detección del conflicto. Cuando dos cambios concurrentes (estos términos se definen con detalle en secciones posteriores) se hacen a la misma unidad de cambio, el servicio de sincronización llega a un conflicto, por otro lado, si los cambios concurrentes se hacen en diferentes unidades de cambio, entonces no se generan conflictos y los cambios surgen de manera automática. En tercer lugar, afecta en gran medida la cantidad de metadatos mantenidos en el sistema. Muchos de los metadatos en el servicio de sincronización se mantienen por unidad de cambio; de esta manera haciendo que las unidades de cambio más pequeñas incrementen la sobrecarga de sincronización. La definición de las unidades de cambio requiere el hallazgo de los cambios correctos. Por esta razón, el servicio de sincronización permite que los diseñadores de esquema participen en el proceso. En una modalidad, el servicio de sincronización no soporta las unidades de cambio que son más grandes que un elemento. Sin embargo, soporta la capacidad de los diseñadores de esquema para especificar las unidades de cambio más pequeñas que un elemento, a saber, atributos múltiples de agrupamiento de un elemento en una unidad de cambio separada. En esa modalidad, esto se logra usando la siguiente sintaxis: <F¡eld Name=" eet¡ngStatus" Type="the storage platformTypes.uniqueidentifierNullable="Fals="/> <Field Name="OrganizerNarne" Type="the storage platformTypes.nvarchar(512)" Nullable="False"/> <Field Name="OrganizerEmail" Type="the storage platformTypes.nvarchar(512)" Type ajorVersion="1" Mult¡Valued='True"/> <C angeUn¡t Name="CU_Status"> <Field Name="Meet¡ngStatus7> c </ChangeUn¡t> O Criangellnit Name="CU_Organizer"/> . <Field Name="OrganizerName" /> <Field Name=OrganizerEma¡l" /> </CriangeUnit> <A"ype> c) Configuración de sincronización 0 Un grupo de compañeros de la plataforma de almacenamiento que desean mantener ciertas partes de sus datos en sincronía se denomina en la presente como comunidad de sincronización. Aunque los miembros de la comunidad desean mantenerse en sincronización, no 5 necesariamente representan los datos de la misma exacta manera; en otras palabras, los compañeros de sincronización pueden transformar los datos que sincronizan. En una situación de cliente a cliente, no es práctico que los clientes mantengan las correlaciones de transformación 0 de todos sus compañeros. En su lugar, el servicio de sincronización realiza un enfoque de definición de "carpetas de comunidad". Una carpeta de comunidad es una abstracción que representa una "carpeta compartida" con la que todos los miembros de la comunidad se sincronizan. 5 Esta afirmación se ilustra a manera de ejemplo. Si Juan desea mantener las carpetas de "Mis documentos" de sus diversas computadoras en sincronización, Juan decide una carpeta de comunidad denominada, digamos, documentos de Juan. Entonces, en todas las computadoras, Juan configura una correlación entre la carpeta hipotética documentos de Juan y la carpeta local de "Mis documentos". Desde este punto, cuando la computadora de Juan haga una sincronización con las demás, se comunicarán en términos de documentos en los documentos de Juan, en lugar de sus elementos locales. De esta manera, todas las computadoras de Juan se entienden sin tener que conocer quienes son las otras, la carpeta de comunidad se convierte en la lengua franca de la comunidad de sincronización. La configuración del servicio de sincronización consiste en tres pasos: (1) definir correlaciones entre carpetas locales y carpetas de comunidad; (2) definir perfiles de sincronización que determinan lo que se sincroniza (por ejemplo, qué se debe sincronizar con qué y qué subconjuntos deben enviarse y cuáles recibirse); y (3) definir los programas en los que deben ejecutarse los perfiles de sincronización diferentes, o ejecutarlos de manera manual. (1) Correlaciones de la carpeta de comunidad Las correlaciones de la carpeta de comunidad se almacenan como archivos de configuración XML en máquinas individuales. Cada correlación tiene los siguientes esquemas: /correlaciones / carpeta de comunidad Este elemento denomina la carpeta de comunidad con la que se correlaciona. El nombre sigue las reglas de sintaxis de las carpetas. /Correlaciones / carpeta local Este elemento denomina la carpeta local que la correlación transforma. El nombre sigue a las reglas de sintaxis de las carpetas. La carpeta ya debe existir para que la correlación sea válida. Los elementos dentro de esta carpeta se consideran para la sincronización para esta correlación. /Correlaciones / transformaciones Este elemento define la manera de transformar elementos de la carpeta de comunidad a la carpeta local y de regreso. Si está ausente o vacía, no se realizan transformaciones. En particular, esto significa que no se correlacionan ID. Esta configuración se usa principalmente para crear una memoria intermedia de una carpeta. /Correlaciones / transformaciones / identificadores de correlación Este elemento solicita que los identificadores locales que sean generados sean asignados a todos los elementos correlacionados desde la carpeta de la comunidad, en lugar de rehusar identificadores de la comunidad. El tiempo de ejecución de la sincronización mantiene las correlaciones de los identificadores para convertir los elementos de ida y de regreso. /Correlaciones / transformaciones / raíz local Este elemento solicita que todos los elementos de raíz dentro de la carpeta de comunidad tengan elementos secundarios a partir de la raíz especificada. /Correlaciones / ejecutar cómo Este elemento controla bajo qué solicitudes de autoridad para esta correlación se procesan. Si está ausente, se asume que es un remitente. /Correlaciones / ejecutar cómo / remitente La presencia de este elemento indica que el remitente de mensajes para esta correlación debe ser imitada y las solicitudes procesarse bajo sus identificaciones. (2) Perfiles Un perfil de sincronización es un conjunto total de parámetros necesarios para iniciar la sincronización. Este es provisto por una SCA para que el tiempo de ejecución de la sincronización inicie la sincronización. Los perfiles de sincronización para la sincronización de la plataforma de almacenamiento a plataforma de almacenamiento contienen la siguiente información: • Carpeta local, para funcionar como la fuente y el destino para los cambios; • Nombre de la carpeta remota para sincronizarse, esta carpeta se debe publicar desde compañeros remotos a manera de correlación como se definió anteriormente; • Dirección, el servicio de sincronización soporta sólo envíos, sólo recepciones y sincronización de envíos y recepciones; • Filtro local, selecciona la información local que se envía al compañero remoto. Expresado como una consulta de la plataforma de almacenamiento sobre la carpeta local; · Filtro remoto, selecciona la información remota que se recupera desde el compañero remoto, expresado como una consulta de la plataforma de almacenamiento sobre la carpeta de comunidad; • Transformaciones, define cómo transformar los elementos hacia y desde el formato local; • Seguridad local, especifica si los cambios recuperados desde el punto de extremo remoto se aplican bajo el permiso del punto de extremo remoto (imitado) o el usuario que inicia localmente la sincronización; y · Política de resolución de conflictos, especifica si los conflictos se deben rechazar, ingresar o resolver automáticamente, en el último caso, especifica qué conflictos resolver en el uso, así como los parámetros de configuración para estos. El servicio de sincronización proporciona una clase de CLR en el tiempo de ejecución que permite la construcción simple de perfiles de sincronización. Los perfiles también pueden recibir una enumeración en serie hacia y desde los archivos (XML) para un almacenamiento fácil (con frecuencia programas y conjuntos). Sin embargo, no hay un lugar estándar en la plataforma de almacenamiento en donde se almacenen todos los perfiles; se reciben los SCA para construir un perfil en el punto sin hacerlo persistente. Observe que no hay necesidad de tener una correlación local para iniciar la sincronización. Toda la información de sincronización se puede especificar en el perfil. Sin embargo, la correlación se requiere para responder a las solicitudes de sincronización iniciadas por el lado remoto. (3) Programaciones En una modalidad, el servicio de sincronización no proporciona su propia infraestructura de programación. En su lugar, se apoya en otros componentes para realizar esta tarea, el programador de Windows disponible con el sistema operativo Windows de Microsoft. El servicio de sincronización incluye una utilería de línea de comando que actúa como una SCA y activa la sincronización con base en un perfil de sincronización guardado en un archivo XML. Esta utilería facilita configurar el programador de Windows para ejecutar la sincronización en lugar de programar o responder a los eventos como la entrada al sistema o salida del sistema de un usuario. d) Manejo de conflictos El manejo de conflictos en el servicio de sincronización se de divide en tres etapas: (1) detección del conflicto, lo que sucede al momento de aplicar el cambio, este paso determina si un cambio puede aplicarse de manera segura; (2) resolución del conflicto de manera automática y acceso, durante este paso (el que se lleva a cabo de manera inmediata después de detectar el conflicto) los elementos de resolución de conflicto automáticos se consultan para ver si el conflicto se puede resolver, si no es así el conflicto se puede cargar opcionalmente; y (3) inspección y resolución del conflicto, este paso se desarrolla si algún conflicto se ha cargado y sucede fuera del contexto de la sección de sincronización, en este momento, los conflictos cargados se pueden resolver y eliminar del registro. (1) Detección de conflictos En la modalidad que se presenta, el servicio de sincronización detecta dos tipos de conflictos: basados en el conocimiento y basados en limitaciones. (a) Conflictos basados en conocimientos Un conflicto basado en el conocimiento se produce cuando dos réplicas hacen cambios independientes a la misma unidad de cambio. Dos cambios se invocan de manera independiente si se hacen sin el conocimiento uno de otro. En otras palabras, el segundo no conoce la versión del primero y viceversa. El servicio de sincronización detecta automáticamente todos los conflictos con base en el conocimiento de las réplicas como se describió anteriormente.

Algunas veces es útil concebir los conflictos como bifurcaciones en el historial de versiones de una unidad de cambio. Si no se producen conflictos durante la vida útil de una unidad de cambio, su historial de versión es una cadena simple, cada cambio que se introduce después del anterior. En el caso de un conflicto con base en el conocimiento, ocurren dos cambios en paralelo, ocasionando que la cadena se divida y se convierta en un árbol de versiones. (b) Conflictos basados en restricciones Existen casos en donde los cambios independientes llenan una restricción de integridad cuando se aplican en conjunto. Por ejemplo, dos réplicas que crean un archivo con el mismo nombre en el mismo directorio puede ocasionar que se produzca un conflicto tal. Un conflicto basado en la restricción involucra dos cambios independientes (justo como el que se basa en el conocimiento), pero no afecta la misma unidad de cambio. En su lugar, afecta diferentes unidades de cambio pero con una restricción existente entre éstas.

El servicio de sincronización detecta las violaciones de restricciones en el momento de la aplicación del cambio y emite de manera automática conflictos basados en restricciones. La resolución de los conflictos basados en restricciones usualmente requiere un código personalizado que modifique los cambios de una manera tal que no viole la restricción; el servicio de sincronización no provee un mecanismo de objetivo general para realizarlo. (2) Procesamiento de conflictos Cuando se detecta un conflicto, el servicio de sincronización puede tomar una de tres acciones (seleccionar a través de sincronización en la expresión de sincronización): (1) rechazar el cambio, volver a enviarlo nuevamente al remitente; (2) registrar un conflicto de una bitácora de conflictos; o (3) resolver el conflicto de manera automática. Si se rechaza el cambio, el servicio de sincronización actúa como si el cambio no hubiera llegado a la réplica. Una confirmación negativa se envía al origen. Esta política de resolución es útil principalmente en réplicas sin encabezado (por ejemplo servidores de archivo) en donde los conflictos de acceso al sistema no son factibles. En su lugar, dichas réplicas fuerzan a las otras a lidiar con los conflictos mediante su rechazo. Los iniciadores de la sincronización configuran la resolución de conflictos en sus perfiles de sincronización. El servicio de sincronización da soporte a la combinación de múltiples elementos de resolución de conflictos en un solo perfil de las siguientes maneras, primero, al especificar una lista de elementos de resolución de conflictos que se probarán uno tras otro, hasta que uno de ellos tenga éxito; y segundo, al asociar a los elementos de resolución de conflictos con los tipos de conflicto, por ejemplo, al dirigir conflictos basados en el conocimiento de actualización a actualización hacia un elemento de resolución, pero todos los otros conflictos hacia la bitácora. (a) Resolución automática de conflictos El servicio de sincronización proporciona un número de elementos de resolución de conflictos predeterminados. Esta lista incluye: • Recuperaciones locales: no toma en cuenta los cambios entrantes si está en conflicto con los datos almacenados localmente; • Recuperaciones remotas: no toma en cuenta los datos locales si está en conflicto con los cambios entrantes; • Recuperación del último escritor: toma las recuperaciones locales o las recuperaciones remotas por unidad de cambio con base en la etiqueta de tiempo del cambio (observe que el servicio de sincronización en general no se basa en valores de reloj; este elemento de resolución de conflictos es la única excepción a esta regla); • Determinista: selecciona un ganador de una manera que se garantiza será la misma en todas las réplicas, más no significativa de otra manera, una modalidad de los servicios de sincronización usa comparaciones lexicográficas de los ID de compañero para implementar esta funcionalidad. Además, los ISV puede implementar e instalar sus propios elementos de resolución de conflictos. Los elementos de resolución de conflictos personalizados pueden aceptar parámetros de configuración; dichos parámetros pueden especificarse mediante la SCA de la sección de resolución de conflictos del perfil de sincronización. Cuando un elemento de resolución de conflictos maneja un conflicto, devuelve la lista de operaciones que deben realizarse (en lugar del cambio en conflicto) de regreso hacia el tiempo de ejecución. El servicio de sincronización entonces aplica estas operaciones, habiendo ajustado adecuadamente el reconocimiento remoto para disminuir lo que el manejador de conflictos consideró. Es posible que otro conflicto sea detectado mientras se aplique la resolución. En tal caso, debe resolverse un nuevo conflicto antes de que se reinicie el procesamiento original. Cuando se piensa en conflictos como ramificaciones en el historial de la versión de un elemento, las resoluciones de conflicto se pueden visualizar como uniones, que combinan dos ramas para formar un solo puente. De esta manera, las resoluciones de conflicto convierten los historiales de versiones en DAG. (b) Registro de conflictos Un tipo muy particular de un elemento de resolución de conflictos es el registrador de conflictos. El servicio de sincronización registra los conflictos como elementos de tipo Conf lictRecord. Estos registros se relacionan con los elementos que están en conflicto (a menos que los elementos en sí mismos se hayan eliminado). Cada registro de conflicto contiene: el cambio entrante que ocasionó el conflicto; el tipo del conflicto: actualización-actualización, actualización-eliminación, eliminación-actualización, inserción-inserción, o restricción; inversión del cambio entrante y el conocimiento de la réplica que lo envía. Los conflictos registrados están disponibles para su inspección y resolución como se describe a continuación. (c) Inspección y resolución de conflictos El servicio de sincronización proporciona una API para que las aplicaciones examinen el registro de conflictos y para que sugieran resoluciones de los conflictos en estos. La API permite la aplicación para eliminar todos los conflictos, o los conflictos relacionados con un elemento determinado. También permite que dichas aplicaciones resuelvan conflictos registrados en una de tres formas: (1) recuperaciones, aceptar el cambio registrado y sobrescribir el cambio local en conflicto; (2) recuperaciones locales, ignorar las partes en conflicto del cambio registrado; y (3) sugerir un cambio nuevo, en donde la aplicación propone una fusión que, bajo su opinión, resuelve el conflicto. Una vez que los conflictos se resuelven a través de una aplicación, el servicio de sincronización los retira del registro. (d) Convergencia de réplicas y propagación de resoluciones de conflicto En situaciones de sincronización compleja, el mismo conflicto se puede detectar en múltiples réplicas. Si esto sucede, diversas cosas pasan: (1) el conflicto se puede resolver en una réplica, y la resolución enviarse a la otra; (2) ei conflicto se resuelve en ambas réplicas de manera automática; o (3) el conflicto se resuelve en ambas réplicas manualmente (a través de la inspección del conflicto de la API). Para asegurar la convergencia, el servicio de sincronización envía las resoluciones de conflicto a otras réplicas. Cuando un cambio que resuelve un conflicto llega a la réplica, el servicio de sincronización encuentra automáticamente cualesquiera registros de conflicto en el registro que se han resuelto a través de esta actualización y las elimina. En este sentido, una resolución de conflicto en una réplica se vincula en todas las otras réplicas. Si se eligen diferentes soluciones a través de las réplicas diferentes para el mismo conflicto, el servicio de sincronización aplica el principio de resolución de conflicto de vinculación y elige las dos resoluciones a obtener sobre la otra automáticamente. El ganador se elige de una manera determinante que se garantiza produce el mismo resultado siempre (una modalidad usa comparaciones lexicográficas del identificador de réplica). Si se sugieren "nuevos cambios" diferentes a través de diferentes réplicas para el mismo conflicto, el servicio de sincronización trata este nuevo conflicto como un conflicto especial y usa el registrador de conflictos para evitar que se propague a otras réplicas. Dicha situación se presenta comúnmente con una resolución de conflictos manual. 2. Sincronización de almacenes de datos diferentes a la plataforma de almacenamiento De conformidad con otro aspecto de la plataforma de almacenamiento de la presente invención, la plataforma de almacenamiento proporciona una arquitectura para que los ISV implementen adaptadores de sincronización que permitan que la plataforma de almacenamiento sincronice los esquemas de legados como Microsoft Exchage, AD, Hotmail, etc. Los adaptadores de sincronización se benefician de diversos servicios de sincronización proporcionados por el servicio de sincronización como se describe a continuación. A pesar del nombre, los adaptadores de sincronización no necesitan implementarse como unidades enchufables en alguna arquitectura de la plataforma de almacenamiento. Si se desea, un "adaptador de sincronización" simplemente puede ser cualquier aplicación que usa las interfaces del tiempo de ejecución del servicio de sincronización para obtener los servicios como la enumeración de cambios y la aplicación de estos. Para simplificar la configuración y ejecución de la sincronización en un extremo final determinado, los escritores del adaptador de sincronización son alentados para que expongan la interfaz del adaptador de sincronización estándar, el cual ejecuta la sincronización dado el perfil de sincronización como se describió anteriormente. El perfil proporciona información de configuración al adaptador, algunos de los adaptadores pasan al tiempo de ejecución de sincronización para controlar los servicios del tiempo de ejecución (por ejemplo, la carpeta a sincronizar). a) Servicios de Sincronización El servicio de sincronización proporciona un número de servicios de sincronización a los escritos del adaptador. Para el resto de esta sección, es cómodo referirse a la máquina en la que la plataforma de almacenamiento realiza la sincronización como el "cliente" y el extremo final de la plataforma que no es de almacenamiento del extremo final al que el adaptador se refiere como el "servidor". (1) Enumeración de cambios Con base en los datos del seguimiento de cambios mantenido por el servicio de sincronización, la enumeración de cambios permite que los adaptadores de sincronización enumeren fácilmente los cambios que se han producido en una carpeta del almacén de datos desde la última vez que se intentó realizar una sincronización con este compañero. Los cambios se enumeran con base en el concepto de "ancla", una estructura opaca que representa información sobre la última sincronización. El ancla toma la forma de saber de la plataforma de almacenamiento, como se describió en las secciones anteriores. Los adaptadores de sincronización que utilizan los servicios de numeración de cambios caen en dos amplias categorías: los que usan "anclas almacenadas" y los que usan "anclas provistas". La diferencia se basa en dónde se almacena la información sobre la última sincronización, en el cliente o en un servidor. Con frecuencia es más fácil que los adaptadores almacenen esta información en el cliente, el extremo posterior con frecuencia no es capaz de almacenar cómodamente esta información. Por otro lado, si múltiples clientes se sincronizan con el mismo extremo posterior, el almacenamiento de esta información en el cliente no es eficiente y en algunos casos es incorrecto, hace que un cliente no conozca los cambios que el otro cliente ha presionado hacia el servidor. Si un adaptador desea usar un ancla almacenada en el servidor, el adaptador debe proveerla nuevamente a la plataforma de almacenamiento al momento de la enumeración del cambio. Para que la plataforma de almacenamiento mantenga el ancla (ya sea para un almacenamiento local o remoto), la plataforma de almacenamiento debe conocer los cambios que se aplicaron de manera satisfactoria en el servidor. Estos y sólo estos cambios se pueden incluir en el ancla. Durante la enumeración de cambios, los adaptadores de sincronización usan una interfaz de confirmación para reportar qué cambios se aplicaron de manera satisfactoria. Al final de la sincronización, los adaptadores que usan las anclas provistas deben leer la nueva ancla (que incorpora todos los cambios aplicados satisfactoriamente) y enviarla al extremo posterior.

Con frecuencia, los adaptadores deben almacenar datos específicos de los adaptadores junto con los elementos que insertan en el almacén de datos de la plataforma de almacenamiento. Ejemplos comunes de dichos datos son identificadores remotos y versiones remotas (etiquetas de tiempo). El servicio de sincronización proporciona un mecanismo para almacenar estos datos y la enumeración de cambios provee un mecanismo para recibir estos datos extra junto con los cambios que se devuelven. Esto elimina la necesidad de que los adaptadores vuelvan a consultar la base de datos en la mayoría de los casos. (2) Aplicación de cambios La aplicación de cambios permite que los adaptadores de sincronización apliquen los cambios recibidos desde su extremo posterior hacia la plataforma de almacenamiento local. Se espera que los adaptadores transformen los cambios en el esquema de plataforma de almacenamiento. La figura 24 ilustra el proceso mediante el cual las clases de la API de la plataforma de almacenamiento se generan desde el esquema de la plataforma de almacenamiento. La función primaria de la aplicación de cambios es detectar automáticamente conflictos. Como en el caso de la sincronización de plataforma de almacenamiento a plataforma de almacenamiento, se define un conflicto como dos cambios traslapantes que se hacen sin conocimiento uno del otro. Cuando los adaptadores usan la aplicación de cambios, deben especificar el ancla con respecto a la que se realizó la detección del conflicto. La aplicación de cambio genera un conflicto si se detecta un cambio local traslapante que no está cubierto por el conocimiento del adaptador. Similar a la enumeración de cambios, los adaptadores pueden usar anclas almacenadas o provistas. La aplicación de cambio soporta un almacenamiento eficiente de los metadatos específicos del adaptador. Dichos datos se pueden anexar mediante el adaptador a los cambios aplicados y se pueden almacenar a través del servicio de sincronización. Los datos pueden devolverse en la siguiente numeración de cambios. (3) Resolución de conflictos Los mecanismos de resolución de conflictos descritos anteriormente (opciones de resolución automática y conexión al sistema) están disponibles para los adaptadores de sincronización también. Los adaptadores de sincronización pueden especificar la política para la resolución de conflictos al aplicar los cambios. Si especifica, los conflictos pueden pasar hacia el elemento de resolución de conflictos especificado y resolverse (si es posible). Los conflictos también se pueden registrar. Es posible que el adaptador detecte un conflicto cuando intenta aplicar un cambio local al extremo posterior. En cuyo caso, el adaptador puede aún pasar el conflicto a un tiempo de ejecución de sincronización que será resuelto de conformidad con la política. Además, los adaptadores de sincronización pueden solicitar que los conflictos detectados por el servicio de sincronización se envíen nuevamente a estos para su procesamiento. Esto es particularmente cómodo en el caso en donde el extremo posterior puede almacenar o resolver los conflictos. (b) Implementación del adaptador Aunque algunos "adaptadores" son simplemente aplicaciones que utilizan interfaces de tiempo de ejecución, los adaptadores se intensifican para que implementen las interfaces del adaptador estándar. Estas interfaces permiten que las aplicaciones de control de sincronización: soliciten que el adaptador realice la sincronización de conformidad con un perfil de sincronización determinado; cancele la sincronización en curso y reciban los reportes del progreso (porcentaje completo) en una sincronización en curso. 3. Seguridad El servicio de sincronización se basa en la introducción de tan poco como sea posible en el modelo de seguridad implementado por la plataforma de almacenamiento. En lugar de definir nuevos derechos para la sincronización, los derechos existentes se usan. Específicamente, · Cualquiera que pueda leer un elemento en el almacén de datos puede enumerar los cambios para dicho elemento; • Cualquiera que pueda escribir en un elemento de almacén de datos puede aplicar los cambios a dicho elemento; y · Cualquiera que pueda extender un elemento en el almacén de datos puede asociar los metadatos de sincronización con dicho elemento. El servicio de sincronización no mantiene información de autoría segura. Cuando un cambio se hace en la réplica A por el usuario O y se transfiere a la réplica B, el hecho de que el cambio se realizó originalmente en A "o mediante O" se pierde. Si B transfiere este cambio a la réplica C, esto se realiza la autoridad de B, no la de A. Esto conduce a la siguiente limitante: si no se confía en la réplica para que haga sus propios cambios en un elemento, no puede transferir los cambios hechos por otros. Cuando el servicio de sincronización se inicia, esto se realiza a través de una aplicación de control de sincronización. El servicio de sincronización imita la identidad de SCA y realiza todas las operaciones (tanto local como remota) bajo esa identidad. Para ilustrar, observe que el usuario O no puede ocasionar que el servicio de sincronización local recupere los cambios de una plataforma de almacenamiento remota para los elementos que el usuario O no tiene acceso de lectura. 4. Capacidad de gestión El monitoreo de una comunidad distribuida de las réplicas es un problema complejo. El servicio de sincronización puede usar un algoritmo de "barrido" para recolectar y distribuir información sobre el estado de la réplica. Las propiedades del algoritmo de barrido asegura que la información sobre todas las réplicas configuradas se recolecta eventualmente y que se detectan las réplicas con fallo (que no responden). Esta información de monitoreo en toda la comunidad está disponible en todas las réplicas. Las herramientas de monitoreo se pueden ejecutar en una réplica elegida de manera arbitraria para examinar esta información de monitoreo y tomar las decisiones administrativas. Cualesquiera cambios de configuración deben hacerse directamente en las réplicas afectadas. J. INTEROPERABILIDAD CON EL SISTEMA DE ARCHIVOS TRADICIONAL Como se mencionó anteriormente, la plataforma de almacenamiento de la presente invención tiene la intención, al menos en algunas modalidades, de representar una parte integral del sistema de interfaz de los componentes típicos de computación y los programas y sistemas de programación. Por ejemplo, la plataforma de almacenamiento de la presente invención puede representarse como una parte integral de un sistema operativo, por ejemplo la familia Windows de Microsoft de los sistemas operativos. En esta capacidad, la API de la plataforma de almacenamiento se convierte en una parte de las API del sistema operativo a través de la cual los programas de aplicación interactúan con el sistema operativo. De esta manera, la plataforma de almacenamiento convierte los medios a través de los cuales los programas de aplicación almacenan la información en el sistema operativo y el elemento basado en el modelo de datos de la plataforma de almacenamiento de esta manera reemplaza el sistema de archivos tradicional de tal sistema operativo. Por ejemplo, como se representa en la familia Windows de Microsoft de sistemas operativos, la plataforma de almacenamiento puede reemplazar el sistema de archivos NTFS implementado en ese sistema operativo. Actualmente, los programas de aplicación acceden a los servicios del sistema de archivos NTFS a través de las API Win32 expuestas por la familia de Windows de sistemas operativos. Sin embargo, reconocer que el reemplazo por completo del sistema de archivos NTFS con la plataforma de almacenamiento de la presente invención requeriría la recodificación de los programas de aplicación basados en Win32 y que dicha recodificación puede no ser deseada, sería benéfico para la plataforma de almacenamiento de la presente invención proveer alguna interoperabilidad con los sistemas de archivos existentes, por ejemplo NTFS. En una modalidad de la presente invención, por lo tanto, la plataforma de almacenamiento habilita programas de aplicación que se basan en el modelo de programación Win32 para acceder al contenido tanto del almacén de datos de la plataforma de almacenamiento así como al sistema de archivos tradicional NTFS. En este extremo, la plataforma de almacenamiento utiliza un convencionalismo de denominación que es un superconjunto de las convencionalismos de denominación de Win32 para facilitar una interoperabilidad fácil.

Adicionalmente, la plataforma de almacenamiento da soporte al acceso de archivos y directorios almacenados en un volumen de una plataforma de almacenamiento a través de la API Win32. Detalles adicionales con respecto a esta funcionalidad se pueden encontrar en las solicitudes relacionadas incorporadas a la presente por referencia en párrafos anteriores. K. API DE LA PLATAFORMA DE ALMACENAMIENTO La plataforma de almacenamiento comprende una API que habilita los programas de aplicación para acceder a las funcionalidades y capacidades de la plataforma de almacenamiento analizada anteriormente y para acceder a los elementos almacenados en el almacén de datos. Esta sección describe una modalidad de una API de la plataforma de almacenamiento de la plataforma de almacenamiento de la presente invención. Los detalles con respecto a esta funcionalidad se pueden encontrar en las solicitudes relacionadas incorporadas por referencia a la presente en párrafos anteriores, con alguna de esta información resumida a continuación por comodidad. Haciendo referencia a la figura 18, una carpeta de contención es un elemento que contiene relaciones de propiedad para otros elementos y es equivalente al concepto común de una carpeta de un sistema de archivos. Cada elemento está "contenido" dentro de al menos una carpeta de contención . La figura 19 ilustra la arquitectura básica de la API de la plataforma de almacenamiento, de conformidad con la presente modalidad. La API de la plataforma de almacenamiento utiliza SQLCIient 1900 para comunicarse con el almacén de datos local 302 y también puede usar el SQLCIient 1900 para comunicarse con los almacenes de datos remotos (por ejemplo, el almacén de datos 340). El almacén local 302 también puede comunicarse con el almacén de datos remotos 340 usando un procesador de consulta distribuida DQP o a través del servicio de sincronización de la plataforma de almacenamiento descrito anteriormente. La API 322 de la plataforma de almacenamiento también actúa como la API puente para las notificaciones del almacén de datos, pasa las suscripciones de la aplicación al motor de notificación 332 y enruta las notificaciones hacia la aplicación (por ejemplo, aplicación 350a, 350b ó 350c), como también se describió anteriormente. En una modalidad, la API 322 de la plataforma de almacenamiento también define una arquitectura limitada de "proveedor" de manera que puede acceder datos en ItemContext y AD. La figura 20 representa esquemáticamente los diversos componentes de API de la plataforma de almacenamiento. La API de la plataforma de almacenamiento consiste en los siguientes componentes: (1) clases de datos 2002, que representa el elemento de la plataforma de almacenamiento y los tipos de elementos, (2) estructuras de tiempo de ejecución 2004, que secciona la persistencia del objeto y proporciona clases de soporte 2006; y (3) herramientas 2008, que se usan para generar clases de CLR desde los esquemas de la plataforma de almacenamiento. La jerarquía de las clases resultantes de un esquema determinado se refleja directamente en la jerarquía de los tipos en ese esquema. Por ejemplo, considere los tipos de elementos definidos en el esquema de contacto como se muestra en la figura 21A y en la figura 21B. La figura 22 ilustra la estructura del tiempo de ejecución en operación. La estructura del tiempo de ejecución opera como se indica a continuación: 1. Una aplicación 350a, 350b ó 350c se une a un elemento en la plataforma de almacenamiento; 2. La estructura 2004 crea un objeto ItemContext 2202 que corresponde a los límites del elemento y los regresa a la aplicación; 3. La aplicación presenta un hallazgo en este ItemContext para obtener una colección de elementos; la colección de vuelta conceptualmente es una gráfica objeto 2204 (debido a las relaciones); 4. La aplicación cambia, elimina e inserta datos; . La aplicación guarda los cambios al invocar el método de actualización Update(). La figura 23 ¡lustra la ejecución de una operación de buscar todo ("FindAII"). La figura 24 ilustra el proceso mediante el cual las clases de la API de la plataforma de almacenamiento se generan a partir del esquema de la plataforma de almacenamiento. La figura 25 ilustra el esquema sobre el cual se basa la API del archivo. La API de la plataforma de almacenamiento incluye un espacio de nombre para lidiar con los objetos de archivo. Este espacio de nombre se denomina System. Storage. Files. Los miembros de datos de las clases en System. Storage. Files directamente refleja la información almacenada en el almacén de la plataforma de almacenamiento; esta información se "emite" desde los objetos del sistema de archivos o se pueden crear de manera innata usando la API de Win32. El espacio de nombre System. Storage. Files tiene dos clases: Fileltem y Directoryltem. Los miembros de estas clases y sus métodos se pueden descubrir fácilmente al observar el diagrama del esquema de la figura 25. Fileltem y Directoryltem son de sólo lectura desde la API de la plataforma de almacenamiento. Para modificarlas, se debe usar la API de Win32 o las clases en System. IO.

Con respecto a las API, una ¡nterfaz de programación (o simplemente una interfaz) se puede visualizar como un mecanismo, proceso, protocolo para habilitar uno o más segmentos del código para comunicarse o acceder a la funcionalidad que se provee a través de uno o más segmentos de código. Alternativamente, una ¡nterfaz de programación se puede visualizar como uno o más mecanismos, métodos, invocaciones de funciones, módulos, objetos, etc. de un componente de un sistema capaz de acoplamiento comunicativo con uno o más mecanismos, métodos, invocaciones de funciones, módulos, etc. entre otros componentes. El término "segmento de código" en la oración anterior tiene la intención de incluir una o más instrucciones de líneas de código e incluye, por ejemplo, módulos de código, objetos, subrutinas, funciones y etc., sin tomar en cuenta la terminología aplicada o si los segmentos de código se compilan por separado o si los segmentos de código se proveen como código fuente, código intermedio o código objetivo, ya sea que los segmentos de código se utilicen en un sistema de tiempo de ejecución o proceso, o si se ubican en la misma o en diferente máquina o distribuido a través de diferentes máquinas o si la funcionalidad representada por los segmentos de los códigos están implementadas por completo en los programas y sistemas de programación, por completo en los componentes físicos de cómputo o la combinación de los componentes físicos de cómputo y los programas y sistemas de programación. Una interfaz de programación se puede visualizar genéricamente, como se muestra en la figura 30A o en la figura 30B. La figura 30A ilustra una interfaz Interfaz 1 como un conducto a través del cual los segmentos de código primero y segundo se comunican. La figura 30B ilustra una interfaz que comprende objetos de interfaz 11 y 12 (que pueden o no ser parte de los segmentos de código primero y segundo), que habilitan los segmentos de código primero y segundo de un sistema para comunicarse a través del medio M. En el formulario de la figura 30B, se puede considerar los objetos 11 e 12 de interfaz como interfaces separadas del mismo sistema y se puede también considerar que los objetos 11 e 12 además del medio M comprenden la interfaz. Aunque las figuras 30A y 30B muestran un flujo bidireccional y las interfaces de cada lado del flujo, algunas implementaciones pueden sólo tener un flujo de información en una dirección (o ningún flujo de información como se describe posteriormente) o sólo puede tener un objeto de interfaz en un lado. A manera de ejemplo, y no así de limitante, los términos como interfaz de programación de aplicación (API), punto de entrada, método, función, subrutina, invocación de procedimiento remoto e interfaz de modelo de objeto de componente (COM) están incluidos dentro de la definición de la interfaz de programación. Aspectos de dicha interfaz de programación puede incluir el método por el cual el primer segmento de código transmite información (en donde "la información" se usa en su sentido más amplio e incluye datos, comandos, solicitudes, etc.) hacia el segundo segmento de código; el método por el que el segmento de código segundo recibe la información, y la estructura, que puede ser, sintaxis, organización, esquema, temporización y contenido de la información. A este respecto, el medio de transporte subyacente en sí mismo puede no ser importante para la operación de la interfaz, si el medio es cableado o inalámbrico, o una combinación de ambos, mientras la información se transporte en la manera definida por la interfaz. En algunas situaciones, la información puede no pasar en una o ambas direcciones en el sentido convencional, ya que la transferencia de información puede ser a través de otro mecanismo (por ejemplo, al información se puede colocar en una memoria intermedia, archivo, etc. separada del flujo de información entre los segmentos de código) o no existir, como cuando un segmento de código simplemente accede a la funcionalidad realizada por un segundo segmento de código. Cualquiera o todos los aspectos se pueden importar en una situación determinada, por ejemplo, dependiendo de si los segmentos de código son parte de un sistema en una configuración acoplada ligera o fuertemente, y de esta manera esta lista debe considerarse ilustrativa y no limitante. Esta idea de una interfaz de programación es conocida por los expertos en la técnica y es clara a partir de la descripción detallada precedente de la invención. Sin embargo, hay otras maneras de implementar la interfaz de programación, y, a menos de que se excluya de manera expresa, éstas también tienen la intención de estar incluidas por las reivindicaciones que se establecen al final de esta especificación. Dichas otras maneras pueden aparecer más complicadas o complejas que el formulario simplista de las figuras 30A y 30B, no obstante realizan una función similar para lograr el mismo resultado general. Ahora se describirá brevemente algunas implementaciones alternativas de una interfaz de programación. Factorización: Una comunicación de un segmento de código a otro se puede lograr de manera indirecta al romper la comunicación en diversas comunicaciones discretas. Esto se ilustra esquemáticamente en las figuras 31A y 31B. Como se muestra, algunas interfaces se pueden describir en términos de conjuntos de funcionalidad dirigibles. De esta manera, la funcionalidad de la interfaz de las figuras 30A y 30B se puede dividir para lograr el mismo resultado, igual que se puede proveer matemáticamente 24 o dos veces dos veces tres veces dos. De esta manera, como se ilustra en la figura 31A, la función que se provee mediante la interfaz 1 se puede subdividir para convertir las comunicaciones de la interfaz en múltiples interfaces, interfaz 1a, interfaz 1b, interfaz 1c, etc., mientras se logra el mismo resultado. Como se ilustra en la figura 31B, la función que se provee mediante la interfaz 11 se puede subdividir en múltiples interfaces 11a, 11b, 11c, etc. Mientras se logre el mismo resultado. De manera similar, la interfaz 12 del segundo segmento de código que recibe información del primer segmento de código se puede dividir en múltiples interfaces I2a, 12 b , I2c, etc. Al dividirla, el número de interfaces incluidas con el primer segmento de código necesitan no corresponder con el número de interfaces que se incluyen con el segundo segmento de código. En cualquiera de los casos de las figuras 31A y 31B, el espíritu funcional de las interfaces interfaz 1 e 11 siguen siendo las mismas que con las figuras 30A y 30B, respectivamente. La división de las interfaces también puede seguir propiedades de asociación, comunicación y otras propiedades matemáticas de manera que la factorización puede ser difícil de reconocer. Por ejemplo, el orden de las operaciones puede ser no importante y en consecuencia, se puede desarrollar una función a través de una interfaz de una manera adecuada por adelantado al alcanzar la interfaz, por otra pieza del código o interfaz, o realizarse a través de un componente separado del sistema. Adicionalmente, un experto en la técnica de las artes de la programación puede apreciar que existe una variedad de formas de hacer diferentes invocaciones de funciones que logran el mismo resultado. Redefinición: En algunos casos, puede ser posible ignorar, añadir o redefinir algunos aspectos (por ejemplo parámetro) de una interfaz de programación mientras logre el resultado intencionado. Esto se ilustra en las figuras 32A y 32B. Por ejemplo, suponga que la interfaz 1 de la figura 30A incluye una invocación de función cuadrada (entrada, precisión, salida), una invocación que incluye tres parámetros, entrada, precisión y salida, y que se emite desde el primer segmento de código hacia el segundo segmento de código. Si la precisión del parámetro medio no se refiere a una situación determinada, como se muestra en la figura 32A, sólo puede ignorarse o incluso reemplazarse con un parámetro sin significado (para esta situación). También se puede añadir un parámetro adicional sin relación. En cualquier caso, la funcionalidad del cuadrado se puede lograr, mientras un resultado se devuelva después de que la entrada se haga un cuadrado por el segundo segmento de código. La precisión puede ser un parámetro muy significativo para alguna porción descendente u otra del sistema de cómputo; sin embargo, una vez que se reconoce esta precisión no es necesario para el objetivo angosto de calcular el cuadrado, se puede reemplazar o ignorar. Por ejemplo, en lugar de pasar un valor de precisión válido, un valor sin significado como una fecha de nacimiento puede pasar sin afectar de manera adversa el resultado. De manera similar, como se muestra en la figura 32B, la interfaz 11 se reemplaza por la interfaz 11', se redefine para ignorar o añadir parámetros a la interfaz. La interfaz Ib puede de igual manera redefinirse como la interfaz I2\ reducimiento para ignorar los parámetros no necesarios o los parámetros que se pueden procesar en otro lado. El punto aquí es que en algunos casos una interfaz de programación puede incluir aspectos, como parámetros, que no son necesarios para algunos objetivos, y de esta manera se pueden ignorar o redefinir o procesar en otro lugar para otros propósitos. Codificación en línea: También puede ser factible fusionar algunas o todas las funcionalidades de dos módulos de código separados, como la "interfaz" entre las formas de cambio. Por ejemplo, la funcionalidad de las figuras 30A y 30B se pueden convertir a la funcionalidad de las figuras 33A y 33B, respectivamente. En la figura 33A, los segmentos de código anteriores primero y segundo de la figura 30A se fusionan en un módulo que contiene ambos. En este caso, los segmentos de código aún se pueden comunicar entre sí, pero la interfaz se puede adaptar a una forma que es más adecuada para el módulo único. De esta manera, por ejemplo, las afirmaciones formales de invocación y devolución pueden no ser más necesarias, pero el procesamiento o las respuestas similares referentes a la interfaz 1 pueden aún tener efecto. De manera similar, como se muestra en la figura 33B, parte de la interfaz 12 (o toda) de la figura 30B se puede describir en línea en la interfaz 11 para formar la interfaz 11". Como se ilustra, la interfaz 12 se divide en I2a e 12 b , la porción de interfaz I2a se ha codificado en línea con la interfaz 11 para formar la interfaz 11". Para otorgar un ejemplo concreto, considere que la interfaz 11 de la figura 30B realiza una invocación de función cuadrada (entrada/ salida), que se recibe mediante la interfaz 12, la cual después del procesamiento del valor pasó con la entrada (para cuadrarla) por el segundo segmento de código, pasa nuevamente el resultado cuadrado con salida. En este caso, el procesamiento realizado por el segundo segmento de código (entrada cuadrada) se puede realizar mediante el primer segmento de código sin una llamada a la interfaz. Divorcio: Una comunicación de un segmento de código con otro se puede lograr de manera indirecta al romper la comunicación en múltiples comunicaciones discretas. Esto se ilustra esquemáticamente en las figuras 34A y 34B. Como se muestra en la figura 34A, una o más piezas de programación intermedia (interfaces de divorcio, ya que se divorcian la funcionalidad y/o las funciones de interfaz de la interfaz original) se proveen para convertir las comunicaciones en la primer interfaz, interfaz 1, para conformarlas en una interfaz diferente, en este caso las interfaces Interfaz 2a, interfaz 2b e interfaz 2c. Esto puede realizarse, por ejemplo, cuando hay una base instalada de aplicaciones diseñadas para comunicarse con, digamos, un sistema operativo de conformidad con un protocolo de la interfaz 1, pero entonces el sistema operativo cambia para usar una interfaz diferente, en este caso las interfaces interfaz 2a, interfaz 2b e interfaz 2c. El punto es que la interfaz original que se usó por el segundo segmento de código cambia de manera que ya no es compatible con la interfaz usada por el primer segmento de código, y de esta manera se usa un intermediario para hacer que las interfaces anteriores y nuevas sean compatibles. De manera similar, como se muestra en la figura 34B, se puede producir un tercer segmento de código con la interfaz de divorcio b y 1 para recibir las comunicaciones desde la interfaz 11 y con la interfaz de divorcio 12 para transmitir la funcionalidad de interfaz, por ejemplo, a las interfaces I2a e 12 b , rediseñadas para funcionar con d 12 , pero para proveer el mismo resultado funcional. De manera similar, dM y d 12 pueden funcionar juntas para traducir la funcionalidad de las interfaces 11 e 12 de la figura 30B en un nuevo sistema operativo, mientras proveen el mismo resultado funcional o uno similar. Reescritura: Otra variante posible es rescribir dinámicamente el código para reemplazar la funcionalidad de la interfaz con algo más pero que logre el mismo resultado general. Por ejemplo, puede haber un sistema en donde un segmento de código presentado en un lenguaje intermedio (por ejemplo Microsoft IL, Java byte Code, etc. (se proporciona en un compilador de justo tiempo (JIT) o un intérprete en un entorno de ejecución (como el que se provee por la estructura .net, el entorno de tiempo de ejecución de Java u otros entornos de tipo de tiempo de ejecución similar). El compilador JIT se puede escribir de manera que convierte de manera dinámica la comunicación del primer segmento de código al segundo segmento de código es decir, para conformarlos en una interfaz diferente como sería requerido por el segundo segmento de código (ya sea el original o un segundo segmento de código diferente). Esto se ilustra en las figuras 35A y 35B. Como puede observarse en la figura 35A, este enfoque es similar a la situación de divorcio descrita anteriormente. Puede realizarse, por ejemplo, en donde una base instalada de aplicaciones se diseña para comunicarse con un sistema operativo de conformidad con un protocolo de la interfaz 1, pero el sistema operativo cambia para usar una interfaz diferente. El compilador JIT se puede usar para conformar la comunicación al vuelo desde las aplicaciones instaladas en la base hacia la nueva interfaz del sistema operativo. Como se ilustra en la figura 35B, este enfoque de reescritura dinámica de las ¡nterfaces se puede aplicar para factorizar de manera dinámica, o de otra manera modificar las ¡nterfaces también. Debe observarse que las situaciones descritas anteriormente para lograr los resultados similares o iguales como una interfaz a través de modalidades alternativas también se puede combinar de diversas maneras, en serie y/o en paralelo, o con otros códigos de intervención. De esta manera, las modalidades alternativas presentadas anteriormente no se excluyen entre sí y se pueden combinar, acoplar y mezclar para producir los mismos escenarios o equivalentes a los escenarios genéricos presentados en las figuras 30A y 30B. También se observa que, como con la mayoría de las construcciones de programación, hay otras maneras similares de lograr la misma funcionalidad o una similar de una interfaz que no se describe en la presente, no obstante, se representa mediante el espíritu y alcance de la invención, es decir, se observa que al menos parcialmente se representa la funcionalidad mediante una interfaz, así como los resultados útiles habilitados por ésta, que subyacen al valor de una interfaz. III. EXTENSIONES Y HERENCIA Un concepto fundamental de la presente invención es la utilización de elementos que en cierto grado, modelan objetos de aplicación del mundo real en estructuras complejas, conductas y operaciones descritas por un esquema y reforzadas por el sistema de interfaz de los componentes físicos de cómputo y los programas y sistemas de programación. Para proveer una funcionalidad rica en subclasificación y en varias modalidades de la presente invención, un sistema de interfaz de los componentes físicos de computación y los programas y sistemas de programación (los que, por comodidad, simplemente referiremos en la presente y a partir de ahora como "WinFS") puede proveer un mecanismo mediante el cual los elementos (y los tipos de elementos) se puedan extender usando "extensiones". Las extensiones proporcionan estructuras de datos adicionales (propiedades, relaciones, etc.) a estructuras de tipos de elementos ya existentes. Como se analizó anteriormente (y se analizó particularmente en las secciones 11. E6. (a) y II. F.3), mientras que la plataforma de almacenamiento tiene la intención de proveerse con un conjunto inicial de esquemas, al menos en algunas modalidades la plataforma de almacenamiento permite que los clientes, incluyendo los vendedores de programas y sistemas de programación independientes (ISV), para crear nuevos esquemas (es decir, tipos nuevos de elementos y elementos anidados). Debido a que un tipo de elemento o un tipo de elemento anidado definido por el conjunto inicial de los esquemas de la plataforma de almacenamiento puede no exactamente corresponder a una necesidad de una aplicación de ISV es necesario permitir que los ISV personalicen el tipo. Esto se logra conociendo las extensiones. Las extensiones son instancias no clasificadas pero (a) no pueden existir de manera independiente y (b) deben anexarse a un elemento o a un elemento anidado. También, además de resolver la necesidad de la capacidad de extensión de un esquema, las extensiones también se crearon para resolver asuntos de "clasificación múltiple". Debido a que, en algunas modalidades, la plataforma de almacenamiento puede no soportar la herencia múltiple o los subtipos de traslapo, las aplicaciones pueden usar extensiones como una manera para modelar las instancias de tipo de traslapo (por ejemplo, un documento puede ser un "documento legal" así como un "documento seguro"). A. TIPOS DE SISTEMAS En diversas modalidades de la presente invención, un sistema tipo "WinFS" proporciona un mecanismo para definir estructuras de datos. El sistema tipo se usa para representar datos almacenados en WinFS. Un tipo WinFS se declara en el esquema WinFS. Un esquema WinFS define un espacio de nombre que funciona como un agrupamiento lógico para un conjunto de tipos y otros elementos del esquema WinFS. Los esquemas WinFS se pueden declarar usando un lenguaje de definición de esquema (SDL) que pueden usar un formato XML. A continuación se da el ejemplo de una declaración de esquema posible. <S chema nameSpace = "System.Storage"> Definiciones de tipo </Schema> Los esquemas de WinFS también funcionan como una unidad para la versión del tipo. WinFS define diversos esquemas de sistemas que arrancan el sistema. Existe un espacio de nombre para el esquema System. Storage que contiene las declaraciones de tipo de los tipos de raíz en el sistema, y el esquema System. Storage. WinFS que declara todos los tipos escalares primitivos en el sistema. El sistema tipo WinFS declara un conjunto de tipos escalares simples. Estos tipos se usan como el bloque de construcción más primitivo para todos los otros tipos en el sistema de tipo WinFS. Estos tipos se declaran en el espacio de nombre del esquema System. Storage. WinFS. La siguiente tabla define un conjunto de tipos primitivos.

Una enumeración winFS es un tipo escalar que declara un conjunto de constantes denominadas una lista de valor. Un tipo de enumeración se puede usar en cualquier lugar en donde un tipo escalar se puede usar. A continuación se da un ejemplo de una declaración de enumeración: <Enumeration Name="Gender" > <Vaiue Name="Male" /> <Value Name="Female" /> </Enumeration> Los valores de la enumeración se dan sólo en cero. En el ejemplo anterior el campo Gender.Male representa el valor cero y Geneder.Female representa el valor 1. Un tipo complejo se define mediante un nombre y un conjunto de propiedades. La propiedad es un campo miembro del tipo, y se define mediante un nombre y un tipo. El tipo de una propiedad puede ser escalar (incluyendo el tipo de enumeración) u otro tipo complejo. Un tipo WinFS que se puede usar como un tipo de propiedad se denomina tipo anidado. Un ejemplo de un tipo anidado puede sólo existir como valor de una propiedad de un tipo WinFS complejo, el ejemplo está anidado dentro de una instancia de un tipo complejo. Un tipo anidado se declara usando el elemento de esquema BaseType. A continuación se dan unos ejemplos de declaraciones de tipos válidos: <NestedType Name="Address" BaseType="System.Storage.NestedObject"> <Property Nullable="false" /> <Property Name="City" Type=" WinFS.String" Size="256" Nullable="false" /> <Property Name="State" Type=" WinFS.String" Size="256" NuHable="false" /> <Property Nullable="false" /> </NestedType> <ItemType Name="Person" BaseType="System.Storage.Item"> <PropertyName="Name" Type=,,WinFS.String" Size="256" Nullable="false" /> <Property Name="Age" Type="WinFS.Int32" Nullable="false" Default="l > <Property Name="Picture" Type="WinFS.Binary" Size="max"/> <Property Name="Addresses" Type="MultiSet" MultiSetOfType="Address"> </ItemType> Para las propiedades del tipo String y Binary, se debe especificar un atributo de tamaño. Este atributo especifica el tamaño máximo de los valores contenidos en la propiedad. Una propiedad se puede declarar opcionalmente con una capacidad de nulidad que restringe el uso del atributo anulable. Un valor de "falso" para este atributo indica que la aplicación debe proveer un valor al crear una instancia en el tipo. Otro atributo de propiedad opcional es el atributo por defecto que especifica el valor predeterminado para la propiedad. Este valor se asigna a la propiedad en el momento de la creación de la instancia si la aplicación no lo provee.

La propiedad Addresses en el ejemplo anterior es de tipo de conjunto múltiple. Una propiedad de tipo de conjunto múltiple también se denomina como una propiedad de valores múltiples. En el ejemplo este conjunto múltiple contiene un conjunto de instancias del tipo de dirección. Un conjunto múltiple es similar a una colección. Puede contener cero o más instancias de un tipo complejo. El tipo de la instancia en el conjunto múltiple puede ser un tipo anidado complejo. El tipo de conjuntos múltiples no soporta instancias de los tipos escalares de WinFS (incluyendo los tipos de enumeración). Una propiedad del tipo de conjuntos múltiples no puede ser anulable y no puede tener un valor predeterminado. WinFS soporta una sola herencia de tipos. En todos los tipos en WinFS deben heredarse de uno y solo en el tipo WinFS. El tipo que se hereda se denomina el tipo derivado y el tipo desde el cual este tipo se derivó se denomina como el tipo base. El tipo base en el atributo BaseType de los elementos de declaración del tipo WinFS. Suponga que el tipo A se deriva del tipo base B que en su momento se deriva del tipo C. El tipo C es un tipo anterior de tipo A y B. El tipo A es un tipo de saliente de los tipos B y C. Una instancia de datos almacenada en WinFS siempre es una instancia de un solo tipo. Sin embargo, podemos dar un tratamiento a las instancias de datos como instancias de un conjunto de tipos que contienen el tipo y todos sus tipos antecesores. Para una instancia de datos que es una instancia de dicho conjunto de tipos, invocamos el tipo que no es el antecesor de ningún otro tipo en el conjunto el tipo con mayor derivación. Una instancia de datos de un solo tipo es una instancia del tipo con mayores derivaciones exactamente. En general, nos referiremos al tipo con mayores derivaciones de un elemento de un solo tipo como subtipo. El tipo derivado hereda todas las propiedades declaradas en este tipo base. El tipo derivado puede declarar nuevas propiedades pero no puede anular las propiedades definidas en el tipo base. Una propiedad declarada en el tipo derivado no puede usar el mismo nombre que la propiedad del tipo base. La utilidad principal de la herencia en el modelo de datos se obtiene de la capacidad de sustitución de los tipos heredados. Considere el siguiente ejemplo: <NestedType Name="Name" BaseType="System.Storage.NestedObject" > <Property Name="FirsfName" Type="WinFS.String" /> <Property Name="LastName" Type="WinFS.String" /> </Nestedype> <NestedTy > <Property </NestedType> <NestedType Name="Person" BaseType="System .Storage.Item" ' > <Property Name="RealName" Type-'Name" /> <Property Name=OtherNames" Type="MultiSet" MultiSetOfType="Name" /> </NestedType> En el ejemplo anterior, el tipo Person tiene una propiedad "realname" del tipo "ñame" y una propiedad "OTHERNAMES" que es un conjunto del tipo ÑAME. Normalmente se requerirá que la propiedad REALNAME sólo tenga instancias cuyo tipo sea ÑAME. Sin embargo, con la herencia, las instancias de un solo valor se permiten como el valor de REALNAME mientras el tipo ÑAME es uno de los ancestros del tipo con mayor derivación de dicho elemento. De esta manera, una instancia de NameWithMiddlelnitial será permitida como el valor de la propiedad REALNAME. La misma regla se extiende para configurar las propiedades. La propiedad OTHERNAME contiene un conjunto de elementos. Para cada instancia con una sola clasificación que es un miembro de dicho conjunto, el tipo con mayor derivación de la instancia debe tener la propiedad AME como uno de sus antecesores. De esta manera, algunas de las instancias en el conjunto OTHERNAMES pueden ser instancias del tipo ÑAME aunque otras instancias puedan ser del tipo NameWithMiddlelnitial. La herencia también habilita una consulta cómoda en que es posible en el sistema WinFS encontrar todas las instancias de un cierto tipo. Cuando se busca todas las instancias de un tipo, el motor de búsqueda también devuelve todas las instancias cuyos tipos con mayor derivación son descendentes de este tipo. Sin embargo, estas operaciones sólo están soportadas para los tipos de elemento, extensión y relación (no para los tipos de propiedad). Para los tipos anidados (es decir, elementos anidados, propiedad o tipos de propiedad compleja), la operación sólo está soportada para las instancias contenidas dentro de una propiedad de conjuntos múltiples únicos. B. TIPOS DE FAMILIAS En resumen, el sistema de tipo WinFS define cuatro distintos tipos de familias: · Tipos de elementos anidados (es decir tipos anidados o tipos de propiedad) • Tipos de elemento • Tipos de relación • Tipos de extensión. Cada tipo de familia tiene un conjunto diferente de propiedades y usos en el sistema tipo WinFS. El nombre de espacio del esquema System. Storage declara cuatro tipos que funcionan como tipo de raíz para cada uno de los tipos de la familia. Las siguientes secciones describen los tipos de familias en detalle. 1. Tipos de elementos anidados A diferencia de otras familias de los tipos WinFS, los tipos anidados se pueden usar como tipos de propiedades de tipos complejos WinFS, las instancias de un tipo anidado sólo se pueden anidar dentro de una instancia de otro tipo complejo. Sin embargo, las instancias de los tipos anidados no se pueden consultar globalmente, esto es, las aplicaciones no pueden componer una consulta simple que devuelva todas las instancias de un tipo anidado determinado dentro de un almacén WinFS. 2. Tipos de elementos Un elemento WinFS es una instancia de un tipo cuyo ancestro es el tipo System. Storage. Item. Este tipo es un tipo complejo que es la raíz de la familia del tipo del elemento. System. Storage. Item declara una propiedad del nombre del identificador del elemento del tipo GUID. Esta es una propiedad especial de un elemento que funciona como una clave primaria del elemento. El valor de esta propiedad se garantiza que será exclusivo para los elementos en un almacén WinFS determinado. Esta propiedad no es anulable y debe asignarse mediante la aplicación cuando se crea una instancia de un tipo de elemento. La propiedad Itemld también es inmutable, nunca puede cambiar y no debe volver a usarse. El motor de consulta puede devolver instancias de un tipo de elemento determinado en un almacén WinFS. Esta consulta devuelve todas las instancias del tipo y todos sus tipos descendentes. Posteriormente en la presente se describe el papel central de los elementos en las semánticas operativas del sistema WinFS. 3. Tipos de relaciones Los tipos de relación habilitan las relaciones para que existan entre los elementos. Los tipos de relación WinFS describen relaciones binarias en donde un elemento está diseñado como la fuente y el otro elemento está diseñado como el objetivo. Una relación es una instancia de un tipo cuyo antecesor es System. Storage. Relationship. Este tipo es una raíz de la jerarquía del tipo de relación. El tipo System. Storage. Relationship declara las siguientes propiedades: • Sourceltemld el identificador del elemento que es una fuente de la instancia de la relación. • Relationshipld, es un identificador exclusivo de la relación con relación al elemento fuente; el par "Sourceltemld, Reltionshipld" forma la clave primaria para los tipos de relación en WinFS. • Targetltemld es el identificador del elemento del objetivo de la relación. • Mode, uno de los tres modos de instancias de relación: Holding, embedding o Reference (propiedad, incrustación o de referencia). • Ñame contiene el nombre de la relación para contener las relaciones. • IsHidden, es un atributo Booleano que las aplicaciones pueden usar opcionalmente para filtrar las relaciones que no necesitan ser visualizadas. Los valores de las propiedades Sourceltemld, Relationshipld, Targetltemld y Mode son inmutables. Estos se asignan a la hora de creación de instancia de la relación y no pueden cambiar. Se declara un tipo de relación como un tipo complejo con las siguientes descripciones adicionales: • Una especificación del punto de extremo fuente y objetivo: cada punto de extremo especifica un nombre y el tipo del elemento al que hace referencia. • Los modos permitidos de la instancia del tipo de relación: una instancia de relación no puede tener un valor para la propiedad de modo que no se permite en la declaración de relación. A continuación se da un ejemplo de una declaración de relación: <RelationshipTpeName="DocumentAuthor" BaseType-'System.Storage.Relationship'' Al lo wsHolding="true" AllowsEmbedding="false" AllowsReference-'true" > <Source ame-'Docuraent" Type="Core.Document7> <Target Type="Core.Contact" /> <Property Name="Role" Type="WinFS.Stríng" /> <Property /> </RelationshipType> . Se declara una relación Documentauthor con las restricciones de las instancias del modo Holding o Reference. Esto significa que una instancia de la relación Documentauthor puede tener instancias con un valor Mode = "Reference" o Mode = "HoIding". Las instancias con un valor Mode="Embedding" no serán permitidas. La relación declara un punto de extremo fuente denominado "document" del tipo de elemento "core.document" y un punto de extremo objetivo del tipo "core.contact". La relación también declara las propiedades adicionales. Las instancias de relación se almacenan y se accede a éstas por separado desde el elemento. Todas las instancias del tipo de relación pueden accederse desde un formulario de extensión global. Se puede componer una consulta que devolverá todas las instancias de un tipo determinado de relación. Dado el elemento todas las relaciones para el cual el elemento es una fuente se pueden enumerar con base en la propiedad Sourceltemld de la relación. De manera similar, para un elemento determinado toda la relación en el mismo almacén para el cual el elemento es un objetivo se puede enumerar usando la propiedad Targetltemld de la relación. a) Semántica de las relaciones Las siguientes secciones describen las semánticas de los diferentes modos de instancias de relación: Relación de propiedad: Las relaciones de propiedad, HoldingRelationship, se usan para el conteo de referencia modelo con base en la sección del tiempo de vida útil de los elementos objetivos. Un elemento puede ser un punto de extremo fuente para cero o más relaciones para los elementos. Un elemento que no es un elemento incrustado puede ser un objetivo de una o más relaciones de propiedad. El elemento debe estar en el mismo almacén que la instancia de la relación. Las relaciones de propiedad refuerzan la gestión del tiempo de vida útil del punto de extremo objetivo. La creación de una instancia de relación de propiedad y el elemento que es el objetivo es una operación atómica. Las instancias de la relación de propiedad pueden crearse siendo objetivos del mismo elemento. Cuando la última instancia de la relación de propiedad con un elemento determinado como punto de extremo objetivo se elimina el elemento objetivo también se elimina. Los tipos de elementos de punto de extremo especificados en la declaración de la relación se refuerzan cuando una instancia de la relación se crea. Los tipos de los elementos de punto de extremo no se pueden cambiar después de establecer la relación. Las relaciones de propiedad juegan un papel clave en la formación del espacio de nombre del elemento WinFS. Todas las relaciones de propiedad participan en la relación del espacio de nombre. La propiedad "ÑAME" en la declaración de la relación define el nombre del elemento objetivo con relación al elemento fuente. Este nombre relativo es único para todas las relaciones de propiedad que tienen un origen de un elemento determinado y no pueden ser nulas. La lista ordenada de los nombres relativos que inician desde el elemento de raíz hacia un elemento determinado forma el nombre completo del elemento. La relación de propiedad forma una gráfica acíclica primitiva (DAG). Cuando una relación de propiedad se crea, un sistema asegura que un ciclo no se crea y de esta manera asegura que el espacio de nombre del elemento de WinFS forma una DAG. Para obtener más información sobre el espacio de nombre de WinFS y las rutas del elemento refiérase a la especificación "espacio de nombre WinFS". Relaciones de incrustación: Las relaciones de incrustación, EmbeddingRelationship, modelan el concepto del control exclusivo del tiempo de vida útil del elemento objetivo. Habilitan el concepto de los elementos compuestos. La creación de una instancia de relación de incrustación y el elemento al que se dirige es una operación anatómica. Un elemento puede ser una fuente de cero o más relaciones de incrustación. Sin embargo, un elemento puede ser un objetivo de una y sólo una relación de incrustación. Un elemento que es un objetivo de la relación de incrustación no puede ser un objetivo de una relación de propiedad. El elemento objetivo debe estar en el mismo almacén que la instancia de la relación. Los tipos de los elementos del punto de extremo especificados en la declaración de la relación serán responsables cuando se crea una instancia de la relación. Los tipos de los elementos del punto de extremo no pueden cambiarse después de establecer la relación. Las relaciones incrustadas no participan en el espacio de nombre de WinFS. El valor de la propiedad del nombre de una relación incrustada debe ser nulo. Relaciones de referencia: Las relaciones de referencia, ReferenceRelationship, no controlan el tiempo de vida útil del elemento al que hace referencia. Las relaciones de referencia no garantizan la existencia del objetivo, tampoco garantizan el tipo de objetivo como se especifica en la declaración de relación. Esto significa que las relaciones de referencia pueden estar colgando. También, la relación de referencia puede hacer referencia a los elementos en otros almacenes WinFS. En WinFS las relaciones de referencia se usarán para modelar la mayoría de las relaciones de cesión que no son del tiempo de vida útil entre los elementos. Ya que la existencia del objetivo no se refuerza, la relación de referencia es cómoda para modelar relaciones acopladas de manera suelta. La relación de referencia se puede usar para elementos objetivo en otros almacenes WinFS incluyendo almacenes en otras máquinas. Las relaciones de incrustación participan en el espacio de nombre de WinFS. El valor de la propiedad de nombre de una relación de incrustación debe ser "nul". b) Reglas y restricciones de las relaciones Las siguientes reglas adicionales y restricciones aplican a las relaciones: • Un elemento debe ser un objetivo de (exactamente uno en la relación de incrustación) o (una o más relaciones de propiedad). La única excepción es el elemento de raíz. Un elemento debe ser un objetivo de cero o más relaciones de referencia. • Un elemento que es un objetivo de la relación de incrustación no puede ser la fuente de la relación de propiedad. Puede ser una fuente de las relaciones de referencia. • Un elemento no puede ser la fuente de una relación de propiedad si se promueve desde el archivo. Puede ser una fuente de las relaciones de incrustación y de las relaciones de referencia. • Un elemento que se promueve desde un archivo no puede ser un objetivo de la relación de incrustación. Cuando una relación de tipo A se deriva de una relación base tipo B, se aplican las siguientes reglas: • El tipo de relación A además puede restringir los tipos del punto de extremo. Los tipos del punto de extremo deben ser subtipos del tipo de punto de extremo correspondiente en la relación B base. Si el punto de extremo se restringe adicionalmente debe declararse un nuevo nombre para el punto de extremo. Si el punto de extremo no se restringe la precipitación del punto de extremo es opcional. • El tipo A de la relación además puede restringir los modos de estancia permitidos declarados en la relación base. El conjunto restringido de los modos de estancia deben ser un subconjunto del conjunto del tipo base de los tipos de estancias permitidos. • Los nombres de los puntos de extremo se tratan como nombres de propiedad: no pueden ser el mismo que el nombre de una propiedad o un nombre de punto de extremo del tipo o subtipo base. • Los elementos fuente y objetivo son opcionales si el tipo de punto de extremo correspondiente no está restringido adicionalmente por la relación derivada. A continuación se da un ejemplo de una declaración de un tipo de relación que se deriva de la relación DocumentAuthor definido anteriormente: <RelationshipType ame="LegalDocumentAuthor" BaseType-'Core.DocumentAuthor" AllowsHolding="false" AllowsEmbedding="fal:;e" AHowsReference-'true" > <Source Name="LegalDocument" Type="Legal.Document "/> <Property Name="CaseNuraber" Type="WinFS.String" /> </RelationshipType> La relación LegalDocumentAuthor además restringe el punto de extremo fuente pero no el punto de extremo objetivo. El tipo de punto de extremo fuente es Legal. Document, que se deriva de Core. Document. El punto de extremo objetivo no se restringe adicionalmente en este caso, de esta manera el elemento objetivo se omite. La relación también restringe los modos de instancias permitidos. Deshabilita el modo de propiedad (HOLDING) y el único modo permitido remanente es el de referencia (REFERENCE). 4. Tipos de extensiones Una extensión de WinFS es una instancia de un tipo cuyo antecesor es el tipo System. Storage. Extensión. Este tipo es un tipo complejo que es la raíz de la familia del tipo de extensión. • System. Storage. Extensión define dos propiedades: • Itemld, el identíficador del elemento con el que se asocia la extensión. · Extensionld, un identíficador único para la extensión relacionada con el identificador del elemento. El par (Itemld, Extensionld) identifica de manera exclusiva una instancia de extensión. Las siguientes restricciones aplican a los tipos de extensión: • Las instancias del tipo de extensión no pueden existir de manera independiente de un elemento. Una instancia de tipo de elemento con el mismo identificador de elemento que el identificador de elemento de extensión debe existir en el almacén antes de crear la instancia del tipo de extensión. La extensión no puede crearse si elementos con el identificador de elemento determinado no existe. Cuando el elemento se elimina todas las extensiones con el mismo identificador de elemento se eliminan. · Cuando mucho una instancia de un tipo de extensión determinado con mayores derivaciones se puede asociar con un elemento individual. • Las extensiones que no son fuentes y objetivos de las relaciones. No hay restricciones sobre los tipos de extensiones que se pueden asociar con un tipo determinado de elemento. Cualquier tipo de extensión se permite extender cualquier tipo de elemento. Cuando diversas instancias de diferentes tipos de extensión se anexan a un elemento, son independientes entre sí tanto en estructura como en comportamiento. Las instancias de extensión se almacenan y se acceden por separado del elemento. Todas las instancias del tipo de extensión pueden accederse desde un formulario de extensión global. Una consulta puede realizarse y ésta devolverá todas las instancias de un tipo determinado de extensión sin tomar en cuenta el tipo de elemento al que están asociadas. El identificador del elemento de la extensión indica al elemento al que pertenecen y se puede usar para recuperar el objeto del elemento correspondiente desde el formulario del elemento global. También, dado un elemento todas las instancias de extensiones asociadas con el elemento se pueden enumerar usando la propiedad del identificador del elemento de la extensión. C. FUNCIONALIDAD MEJORADA En diversas modalidades de la presente invención, un sistema de interfaz de componentes físicos de cómputo y programas y sistemas de programación utiliza extensiones y la herencia para formalizar las relaciones entre diversos elementos y de esta manera mejorar la capacidad para consultar una pluralidad de elementos. 1. Herencia La figura 36 ilustra una serie de elementos interrelacionados en subconjunto de sus relaciones. El elemento del documento 3602 y un elemento de contacto 3604 se relacionan directamente a través de una relación diseñada 3606 que, en este caso, es una "relación de autor", esto es, el contacto 3604 es el "autor" del documento 3602. En este ejemplo, el elemento de imagen 3622, el elemento de música 3624 y el elemento especial 3626 todos se heredan desde el elemento del documento 3604, ya que cada tipo de elemento es un subtipo del tipo del elemento del documento. De manera similar, el elemento persona 3642 y el elemento organización 3644 se heredan del elemento de contacto 3604. En algunas modalidades de la presente invención, estos elementos de herencia (imagen 3622, música 3624, especial 3626, persona 3642, y organización 3644) no sólo heredan las propiedades de los elementos de origen respectivos (documento 3602 y contacto 3604), también heredan las relaciones diseñadas entre estos dos elementos de origen. Por ejemplo, la imagen 3622 hereda una relación 3662 para un contacto 3604, una relación 3664 para una persona 3642 y una relación 3666 para una organización 3644. Un conjunto similar de relaciones también se hereda mediante cada uno de dichos elementos mostrados. Sin embargo, es importante observar que la herencia de la relación no es automática y no se produce en todos los contextos. Por ejemplo, los atributos se describen cuando un tipo se puede heredar (es decir, controles de herencia) no son heredables en sí mismos. Los parámetros de herencia se mantienen y se regulan a través del sistema de interfaz de los componentes físicos de cómputo y los programas y sistemas de programación. 2. Extensiones La figura 37A ilustra los inconvenientes de la subclasificación estándar de un elemento para objetivos específicos de la aplicación. En esta figura, se puede tener acceso a un contacto mediante cuatro aplicaciones, APP1, APP2, APPX, y APPY. APP1 y APP2 acceden al contacto estándar, pero cada uno de APPX y APPY necesitan un objeto de contacto extendido (adición de campos adicionales) y de esta manera derivan el contacto prima y contacto doble prima, cada uno de los cuales se hereda desde el contacto. Sin embargo, el problema es que ahora hay tres instancias diferentes del elemento de contacto básico, uno en contacto, uno en contacto prima y uno en contacto doble prima. Una solución parcial para este problema, que se ilustra en la figura 37B, es extender las propiedades del contacto para que incluyan los campos necesarios para una aplicación que los requiere. En este caso, el contacto se extiende para que incluya los campos adicionales que se requiere para APPX. Sin embargo, al extender directamente los campos de un elemento como contacto sólo se puede realizar una vez, y de esta manera APPY no puede emplear este método. En una modalidad de la presente invención una solución más completa es extender el contacto con una extensión que es diferente y separada del mismo contacto como se ¡lustra en la figura 37C. De esta manera, APPX puede extender al contacto para que incluya sus campos adicionales de APPX mientras APPY también puede extender por separado el contacto para que incluya sus campos adicionales de APPY. Estas extensiones entonces pueden buscarse y pueden consultarse, y de esta manera las extensiones habilitan una forma de clasificación múltiple para el sistema de interfaz de los componentes físicos de cómputo y los programas y sistemas de programación. IV. CONCLUSIÓN Como se ilustra con la descripción anterior, la presente invención está dirigida a una plataforma de almacenamiento para organizar, buscar y compartir datos. La plataforma de almacenamiento de la presente invención extiende y amplía el concepto de almacenamiento de datos más allá de los sistemas de archivos existentes y los sistemas de bases de datos, y está diseñada para que sea el almacén de todo tipo de datos, incluyendo datos estructurados, no estructurados o semiestructurados, por ejemplo datos relaciónales (tabulares), XML y una nueva forma de elementos denominados datos. A través de su fundamento de almacenamiento común y datos de esquemas, la plataforma de almacenamiento de la presente invención habilita el desarrollo de aplicaciones más eficientes para los consumidores, trabajadores intelectuales y empresas. Ofrece una interfaz de programación de aplicación extensible que no sólo pone disponibles las capacidades inherentes en su modelo de datos, también involucra y extiende el sistema de archivos existentes y los métodos de acceso a las bases de datos. Se comprende que pueden hacerse cambios a las modalidades descritas en el presente documento sin separarse de los amplios conceptos inventivos de éste. De esta manera, la presente invención no está limitada a las modalidades particulares descritas, está creada para cubrir todas las modificaciones dentro del alcance y espíritu de la invención, como se describe en las reivindicaciones anexas. A partir de lo anterior, será evidente que todo o las porciones de diversos sistemas, métodos y aspectos de la presente invención se pueden representar en forma de un código de programa (es decir, instrucciones). Este código de programa se puede almacenar en un medio legible por computadora, por ejemplo un medio de almacenamiento óptico o eléctrico o magnético, incluyendo sin limitarse a un disco flexible, CD-ROM, CD-RW, DVD-ROM, DVD-RAM, cinta magnética, memoria instantánea, unidad de disco duro u otro medio de almacenamiento legible a través de una máquina, en donde, cuando el código de programa se carga y se ejecuta mediante una máquina, como una computadora o servidor, la máquina se convierte en un aparato para practicar la invención. La presente invención también puede representarse en forma de un código de programa que se transmite sobre algunos medios de transmisión, por ejemplo a través de un cableado eléctrico o alambrado eléctrico, a través de fibra óptica, en una red, incluyendo Internet o una red interna, o a través de cualquier otra forma de transmisión, en donde, cuando el código de programa se recibe y se carga y se ejecuta a través de una máquina, por ejemplo una computadora, la máquina se convierte en un aparato para practicar la invención. Cuando se implementa en un procesador de objetivo general, el código de programa se combina con el procesador para proveer un aparato único que funcione de manera análoga para especificar los circuitos lógicos.

Claims

REIVINDICACIONES 1. - Un método para extender un elemento, dicho elemento constituye una unidad de información discreta que se puede almacenar y que se puede manipular a través de un sistema de una interfaz de elementos físicos de cómputo y programas y sistemas de programación, dicho método comprende la utilización de una instancia con clasificaciones (una "extensión") para extender dicho elemento, dicha extensión constituye una unidad de información discreta que se puede almacenar y que se puede manipular mediante dicho sistema de interfaz de componentes físicos de cómputo y programas y sistemas de programación.
2. - El método tal y como se describe en la reivindicación 1, en donde dicha extensión se anexa a dicho elemento.
3.- El método tal y como se describe en la reivindicación 1, en donde dicha extensión no puede existir de manera independiente de dicho elemento, de manera que si dicho elemento deja de existir, dicha extensión también deja de existir.
4.- El método tal y como se describe en la reivindicación 1, en donde dicho elemento se extiende a través de una pluralidad de extensiones.
5.- El método tal y como se describe en la reivindicación 4, en donde dicha pluralidad de extensiones se usa para modelar las instancias del tipo de traslapo.
6. - Un método para extender una propiedad, dicha propiedad constituye un tipo de propiedad compleja que se puede manipular a través de un sistema de interfaz de los componentes físicos de cómputo y los programas y sistemas de programación, dicho método comprende la utilización de una instancia clasificada (una "extensión") para extender dicha propiedad, dicha extensión constituye una unidad de información discreta que se puede almacenar y que se puede manipular a través de dicho sistema de interfaz de componentes físicos de cómputo y programas y sistemas de programación y que se asocia con dicha propiedad.
7. - El método tal y como se describe en la reivindicación 6, en donde dicha extensión se anexa a dicha propiedad.
8. - El método tal y como se describe en la reivindicación 6, en donde dicha extensión no puede existir de manera independiente de dicha propiedad, de manera que si dicha propiedad deja de existir, dicha extensión también deja de existir.
9. - El método tal y como se describe en la reivindicación 6, en donde dicha propiedad se extiende a través de una pluralidad de extensiones.
10. - El método tal y como se describe en la reivindicación 9, en donde dicha pluralidad de extensiones se usa para modelar las instancias del tipo de traslapo.
11.- Un método para un sistema de interfaz de componentes físicos de cómputo y programas y sistemas de programación para organizar y consultar de manera eficiente una pluralidad de elementos, dicho elemento construye unidades de información que se pueden almacenar de manera discreta que se pueden manipular a través de un sistema de interfaz de componentes físicos de cómputo/ programas y sistemas de programación, dicha pluralidad de elementos comprenden una primera relación que se refiere a un primer elemento y a un segundo elemento, dicho método comprende para la representación de un tercer elemento, dicho tercer elemento tiene una instancia subclasificada de dicho primer elemento, dicho tercer elemento hereda automáticamente de dicho primer elemento una relación con dicho segundo elemento.
12.- El método tal y como se describe en la reivindicación 11, en donde, para la representación de un cuarto elemento, dicho cuarto elemento es una instancia subclasificada de dicho segundo elemento, dicho cuarto elemento hereda automáticamente de dicho segundo elemento una relación con dicho primer elemento.
13.- El método tal y como se describe en la reivindicación 12, en donde dicho cuarto elemento además hereda automáticamente de dicho segundo elemento una relación con dicho tercer elemento.
14.- El método tal y como se describe en la reivindicación 11, en donde para cada una de una primera pluralidad de instancias subsclasif ¡cadas de dicho primer elemento, cada una de dicha primera pluralidad de las instancias subclasificadas automáticamente hereda de dicho primer elemento una relación con dicho segundo elemento.
15. - El método tal y como se describe en la reivindicación 14, en donde, para cada una de la segunda pluralidad de instancias subclasificadas de dicho segundo elemento, dicha segunda pluralidad de instancias subclasificadas además hereda automáticamente de dicho segundo elemento las relaciones con dicho primer elemento.
16. - El método tal y como se describe en la reivindicación 15, en donde cada una de dicha primera pluralidad de instancias subclasificadas automáticamente hereda de dicho primer elemento una relación con cada una de dicha segunda pluralidad de instancias subclasificadas.
17. - El método tal y como se describe en la reivindicación 16 en donde cada una de dicha segunda pluralidad de instancias subclasificadas automáticamente hereda de dicho segundo elemento una relación con cada una de dicha primera pluralidad de instancias subclasificadas.
18. - Un sistema de interfaz de componentes físicos de cómputo y programas y sistemas de programación para manipular una pluralidad de elementos, en donde un elemento constituye una unidad de información que puede almacenarse de manera discreta que puede manipularse a través de dicho sistema de interfaz de componentes físicos de cómputo y programas y sistemas de programación, dicho sistema comprende un subsistema para extender un elemento con una instancia clasificada fuertemente (una "extensión"), dicha extensión constituye una unidad de información discreta que se puede almacenar que se puede manipular a través de dicho sistema de interfaz de componentes físicos de cómputo y programas y sistemas de programación.
19.- El sistema tal y como se describe en la reivindicación 18, caracterizado además porque dicha extensión se anexa al elemento.
20. - El sistema tal y como se describe en la reivindicación 18, caracterizado además porque dicha extensión no existe de manera independiente de dicho elemento, de manera que si dicho elemento deja de existir, dicha extensión también deja de existir.
21. - El sistema tal y como se describe en la reivindicación 18, caracterizado además porque dicho elemento se extiende a través de una pluralidad de extensiones.
22. - Un sistema de interfaz de componentes físicos de cómputo y programas y sistemas de programación para manipular una pluralidad de propiedades, dichas propiedades constituyen tipos de propiedad complejas que se pueden manipular a través de un sistema de interfaz de componentes físicos de cómputo y programas y sistemas de programación, dicho sistema comprende un subsistema para extender una propiedad con una instancia con varias clasificaciones (una "extensión"), dicha extensión constituye una unidad de información discreta que se puede manipular a través de dicho sistema de interfaz de componentes físicos de cómputo y los programas y sistemas de programación.
23. - El sistema tal y como se describe en la reivindicación 22, caracterizado además porque dicha extensión se anexa a dicha propiedad.
24. - El sistema tal y como se describe en la reivindicación 22, caracterizado además porque dicha extensión no puede existir de manera independiente de dicha propiedad, de manera que si dicha propiedad deja de existir, dicha extensión deja de existir.
25. - El sistema tal y como se describe en la reivindicación 22, caracterizado además porque dicha propiedad se extiende a través de una pluralidad de extensiones.
26. - Un sistema de interfaz de componentes físicos de cómputo y programas y sistemas de programación para manipular una pluralidad de elementos, en donde un elemento constituye una unidad de información que se puede almacenar discreta que se puede manipular a través de dicho sistema de interfaz de componentes físicos de cómputo y programas y sistemas de programación, dicho sistema comprende un subsistema para organizar y consultar de manera eficiente dicha pluralidad de elementos, dicha pluralidad de elementos comprende una primera relación que establece una relación entre un primer elemento y un segundo elemento, en donde dicho subsistema: para la representación de un tercer elemento, dicho tercer elemento es una instancia subclasificada de dicho primer elemento, establece automáticamente una relación entre dicho tercer elemento y dicho segundo elemento; para la representación de un cuarto elemento, dicho cuarto elemento es una instancia subclasificada de dicho segundo elemento, establece automáticamente una relación entre dicho cuarto elemento y dicho primer elemento; y establece automáticamente una relación entre dicho cuarto elemento y dicho primer elemento.
27.- El sistema tal y como se describe en la reivindicación 26, caracterizado además porque para cada una de una pluralidad de instancias subclasificadas de dicho primer elemento, y para cada una de una segunda pluralidad de instancias subclasificadas de dicho segundo elemento, dicho subsistema: establece automáticamente una relación para cada una de dicha primera pluralidad de instancias subclasificadas con dicho segundo elemento; establece automáticamente una relación para cada una de dicha segunda pluralidad de instancias subclasificadas con dicho primer elemento; y establece automáticamente una relación para cada una de dicha primera pluralidad de instancias subclasificadas con cada una de dicha segunda pluralidad de instancias subclasificadas.
28. - Un sistema de interfaz de componentes de cómputo y programas y sistemas de programación para manipular una pluralidad de elementos, en donde un elemento constituye una unidad de información que se puede almacenar discreta que se puede manipular a través de dicho sistema de interfaz de componentes físicos de cómputo y programas y sistemas de programación, dicho sistema comprende un subsistema para extender un elemento con una instancia muy clasificada (una "extensión"), dicha extensión constituye una unidad de información que puede almacenarse discreta y se puede manipular a través de dicho sistema de interfaz de componentes físicos de cómputo y programas y sistemas de programación.
29. - El sistema tal y como se describe en la reivindicación 28, en donde dicha extensión se anexa a dicho elemento.
30.- El sistema tal y como se describe en la reivindicación 28, en donde dicha extensión no puede existir de manera independiente de dicho elemento, de manera que si dicho elemento deja de existir, dicha extensión deja de existir.
31.- El sistema tal y como se describe en la reivindicación 28, caracterizado además porque dicho elemento se extiende a través de una pluralidad de extensiones.
32. - Un sistema de interfaz de componentes físicos de cómputo y programas y sistemas de programación para manipular una pluralidad de propiedades, dichas propiedades constituyen tipos de propiedad complejos que se pueden manipular a través de un sistema de interfaz de componentes físicos de cómputo y programas y sistemas de programación, dicho sistema comprende un subsistema para extender una propiedad con una instancia muy clasificada (una "extensión"), dicha extensión constituye una unidad de información que se puede almacenar discreta que se puede manipular a través de dicho sistema de interfaz de los componentes físicos de cómputo y los programas y sistemas de programación.
33. - El sistema tal y como se describe en la reivindicación 32, caracterizado además porque dicha extensión se anexa a dicha propiedad.
34.- El sistema tal y como se describe en la reivindicación 32, caracterizado además porque dicha extensión no puede existir de manera independiente de dicha propiedad, de manera tal que si dicha propiedad deja de existir, dicha extensión deja de existir.
35.- El sistema tal y como se describe en la reivindicación 32, caracterizado además porque dicha propiedad se extiende a través de una pluralidad de extensiones.
36.- Un sistema de interfaz de componentes físicos de cómputo y programas y sistemas de programación para manipular una pluralidad de elementos, en donde un elemento constituye una unidad de información que se puede almacenar discreta que se puede manipular a través de un subsistema de componentes físicos de cómputo y programas y sistemas de programación, dicho sistema comprende un subsistema para organizar y consultar de manera eficiente dicha pluralidad de elementos, dicha pluralidad de elementos comprende una primera relación que se refiere a un primer elemento y a un segundo elemento, en donde dicho subsistema: para la representación de un tercer elemento, dicho tercer elemento es una instancia subclasificada de dicho primer elemento, establece automáticamente una relación entre dicho tercer elemento y dicho segundo elemento; para la representación de un cuarto elemento, dicho cuarto elemento es una instancia subclasificada de dicho segundo elemento, establece automáticamente una relación entre dicho cuarto elemento y dicho primer elemento; y automáticamente establece una relación entre dicho cuarto elemento y dicho primer elemento.
37. - El sistema tal y como se describe en la reivindicación 36, caracterizado además porque cada una de una pluralidad de instancias subclasificadas de dicho primer elemento y para cada una de la segunda pluralidad de instancias subclasificadas de dicho segundo elemento, dicho subsistema: establece automáticamente una relación para cada una de dicha primera pluralidad de instancias subclasificadas con dicho segundo elemento; establece automáticamente una relación para cada una de dicha segunda pluralidad de instancias subclasificadas con dicho primer elemento; y establece automáticamente una relación para cada una de dicha primera pluralidad de instancias subclasificadas con cada una de dicha segunda pluralidad de instancias subclasificadas.
38. - Un medio legible por computadora que comprende instrucciones legibles por computadora para extender un elemento, dicho elemento constituye una unidad de información que se puede almacenar discreta que se puede manipular a través de un sistema de interfaz de componentes físicos de cómputo y programas y sistemas de programación, dichas instrucciones legibles por computadora comprenden instrucciones para el uso de una instancia muy clasificada (una "extensión") para extender dicho elemento, dicha extensión constituye una unidad de información que se puede almacenar discreta que se puede manipular a través de dicho sistema de interfaz de componentes físicos de cómputo y programas y sistemas de programación en donde dicha extensión se anexa a dicho elemento y en donde dicha extensión también deja de existir cuando dicho elemento deja de existir.
39.- Un medio legible por computadora que comprende instrucciones legibles por computadora para extender una propiedad, dicha propiedad constituye un tipo de propiedad compleja que se puede manipular a través de un sistema de interfaz de componentes físicos de cómputo y programas y sistemas de programación, dichas instrucciones legibles por computadora comprenden instrucciones para el uso de una instancia no clasificada (una "extensión") para extender dicha propiedad, dicha extensión constituye una unidad de información que se puede almacenar discreta que se puede manipular a través de dicho sistema de interfaz de componentes físicos de cómputo y programas y sistemas de programación en donde dicha extensión se anexa a dicha propiedad y en donde dicha extensión también deja de existir cuando dicha propiedad deja de existir.
40. - Un medio legible por computadora que comprende instrucciones legibles por computadora para organizar y consultar de manera eficiente una pluralidad de elementos, dicho elemento constituye unidades de información que se pueden almacenar discretamente que se pueden manipular a través de un sistema de interfaz de componentes físicos de cómputo y programas y sistemas de programación, dichas instrucciones legibles por computadora comprenden instrucciones para: representar un primer elemento, un segundo elemento y una primera relación que relaciona un primer elemento y un segundo elemento; representar un tercer elemento, dicho tercer elemento es una instancia subclasificada de dicho primer elemento; y establecer automáticamente una relación heredada entre dicho tercer elemento y dicho segundo elemento.
41. - El medio legible por computadora tal y como se describe en la reivindicación 40, caracterizado además porque comprende instrucciones para: representar un cuarto elemento, dicho cuarto elemento es una instancia subclasificada de dicho segundo elemento y establecer automáticamente entre dicho cuarto elemento y dicho primer elemento.
42.- El medio legible por computadora tal y como se describe en la reivindicación 41, caracterizado además porque comprende instrucciones para establecer automáticamente una relación heredada entre dicho tercer elemento y dicho cuarto elemento.