Logical Components of Dataspaces

A dataspace (see Figure 5) should contain all of the information relevant to a particular organization regardless of its format and location, and model a rich collection of relationships between data repositories. Hence, we model a dataspace as a set of participants and relationships.

Пространство данных (см. рисунок 5) должно содержать всю информацию, относящуюся к определенной организации независимо от ее формата и расположения, и смоделировать богатый набор отношений между репозитариями данных. Следовательно, мы моделируем пространство данных как ряд участников и отношений.

Fig. 5. An example dataspace and the components of a dataspace system.

The participants in a dataspace are the individual data sources: they can be relational databases, XML repositories, text databases, web services and software packages. They can be stored or streamed (managed locally by data stream systems), or even sensor deployments.

Some participants may support expressive query languages, while others are opaque and offer only limited interfaces for posing queries (e.g., structured files, web services, or other software packages). Participants vary from being very structured (e.g., relational databases) to semi-structured (XML, code collections) to completely unstructured. Some sources will support traditional updates, while others may be append-only (for archiving purposes), and still others may be immutable.

A dataspace should be able to model any kind of relationship between two (or more) participants.

Dataspaces can be nested within each other (e.g., the dataspace of the Computer Science department is nested within the dataspace of the university), and they may overlap (e.g., the dataspace of the Computer Science department may share some participants with the Electrical Engineering department). Hence, a dataspace must include access rules between disparate dataspaces. In general, there will be cases where the boundaries of a dataspace may be fluid, but we expect that in most of the cases the boundaries will be natural to define.

Участники пространства данных - отдельные источники данных: они могут быть реляционными базами данных, репозитариями XML, базами текстовых данных, веб-сервисами и пакетами программного обеспечения. Они могут быть сохранены или переданы потоком (управляемый локально системами потока данных), или даже развертывание датчика.

Некоторые участники могут поддерживать выразительные языки запросов, в то время как другие непрозрачны и предлагают только ограниченные интерфейсы для того, чтобы изложить запросы (например, структурированные файлы, веб-сервисы или другие пакеты программного обеспечения). Участники варьируются от того, чтобы быть очень структурированным (например, реляционные базы данных) к полуструктурированному (XML, кодируйте наборы) к полностью неструктурированному. Некоторые источники будут поддерживать традиционные обновления, в то время как другие могут быть только добавлением (для того, чтобы заархивировать цели), и все еще другие могут быть неизменными.

Пространство данных должно быть в состоянии смоделировать любой вид отношения между два (или больше) участники.

Пространства данных могут быть вложены друг в друге (например, пространство данных Кафедры информатики вложено в пространстве данных университета), и они могут наложиться (например, пространство данных Кафедры информатики может совместно использовать некоторых участников с Электротехническим отделом). Следовательно, пространство данных должно включать правила доступа между несоизмеримыми пространствами данных. В целом будут случаи, где границы пространства данных могут быть жидкими, но мы ожидаем, что в большинстве случаев границы будут естественными, чтобы определить.