Examples

We will use the following example throughout this FAQ.

It is a possible (simplified) structure of a concept-oriented file system. It has two levels: file system level and database level. At the file system level it has several concepts such as Files or Concepts-Folders. At the database level it has user defined concepts like Mails. Inclusion of files, concepts and folders into other folders is implemented via special subconcepts.

1 File System Syntax and Semantics

1.1 What is the concept-oriented file system?

It is a set of lower level system concepts intended to implement the traditional organization of information by using files and folders as well as the concept-oriented approach to information organization by using concepts and items. We say that it is of lower level because it is simpler and does not know about higher levels (the concept-oriented database). In concept graph it is positioned higher. In the example these two levels are divided by line.

1.2 What are files, folders and concepts?

File, folder and concept are items in the special COFS system concepts called Files, Folders, Concepts, respectively. These concepts have dimensions specific to these types of entities, e.g., date of creation/modification, size etc. File contents is formally considered its dimensions but normally its implementation is more complex.

Names are not dimensions because it is a part of the name system (it is a part of representation mechanism and is closer to references). Files, folders and concepts do not know anything about their names and moreover they do not need to have names at all. Item reference is an identifier that can be used within the scope of the COFS (including the database as a higher level). For example, we might store a file, folder or concept reference as our custom concept dimension value just like we do it for any other variables. For example, items from the concept Mails may reference a file with its attachment. Files, folders and concepts do not know anything about the structure of the file system. In particular, they do not know their parent folder or about other existing files, folders and concepts.

1.3 What is a file content?

It can be viewed as a primitive type passed by value. It is just like number or other primitive type but having an arbitrary length. Thus file content is stored in a file item as one of dimension values.

In practice however it normally makes sense to implement file contents as a special domain with items passed by reference. These items then represent file content at physical level as an array of bytes or blocks while reference is this array identifies. This allows indirecting representation of such complex content and to have different options for its storage. It is a good idea to use a native file system file handles for such a purpose. Then native files in such an architecture play a role of physical storage while most parameters are stored at higher levels.

1.4 How inclusion into folders is implemented?

Just like for any relation, inclusion into folders is implemented via subconcepts Files-Folders, Folders-Folders and Concepts-Folders. These concepts have at least two dimensions pointing to the corresponding superconcepts.

1.5 Is it possible to include items from my own custom concept into a folder?

Yes. To do this, declare a dimension with the domain in the Folders concept. For each new item specify an existing folder item as its parent. The life cycle management will guarantee the reference integrity and consistency of the semantics. In particular, if this folder is removed then all its internal items (files, folder, concepts and custom items) will be either removed or have null assigned (depending on options specified). Analogously, if a file item is deleted then all other items that reference it will be either deleted or nullified. For example, if an attachment is deleted (directly) the corresponding reference in the mail item should be probably nullified (without deletion of the mail).

1.6 How concept syntactic structure is represented?

The concept-oriented file system stores also the syntactic structure of the higher level database. A special concept Concepts-Concepts (not shown in the example diagram) stores the syntactic relationships among concept items. It has at least two dimensions both with the domain in the Concepts concept. For each existing concept item from Concepts there exist a number of parent concept items as its dimension domains. All these pairs are stored in the Concepts-Concepts concept as items.

In fact the concept Concepts-Concepts should have more dimensions in order to be practically useful. In particular, it may have a name of the dimension and dimension constraints. (Alternatively, dimension names might be a part of the common name system). Each item in this concept describes one dimension in the whole system with all its parameters.

1.7 Is it possible to combine inclusion into concepts and into folders?

Theoretically yes. We can include other types of items into concepts by creating the corresponding relation concepts. For example, we could create a concept Files-Concepts. The concepts then are used just like folders. Or, on the other hand, folders are able to include items. Notice that inclusion of files into folder is implemented explicitly via special concept while inclusion of items into a folder is implemented implicitly at the system level via 'instance of' relation.

1.8 What are names?

Name is a part of the name system. Name system is a higher level identification mechanism over the reference system. In other words, names play the same role as items but they are adapted to the use by users while references are more convenient for the system. Name system is a convenience mechanism since names are assumed to be used by human users only. Thus if an item (including files and folders) is not going to be used by users directly then it should not have a name.

1.9 Is it necessary for files, folders and concepts to have names?

No. Names are a part of the name system, which is a higher level over the reference system. All items must have a reference but name system is a convenience mechanism intended to be used by human users. Normally names are assigned to items that have to be accessed directly by users. Fundamentally this means that names are passed and stored outside the system somewhere in physical or mental environment. For programs names are not convenient and should be avoided. For example, if an application stores its parameters in a file, which is not supposed to be edited or viewed by the user then this file does not need a name. Instead, the application can store this file item reference somewhere in parameters. Notice that files, folders and concepts without names will still be visible and accessible from the database. The only difference is that they do not have names.

2 Related Technologies

2.1 What are main differences between MS WinFS and COM/COFS?

Items in WinFS are related explicitly via non-primitive elements (facts, relationship instances) while in COM this mechanism is implemented via references, which are primitive from the point of view of the model, i.e., they do not have any structure or propeties. In order to relate two items in WinFS we have to insert a record with source item and target item (analogue of reference from source item to target item in COM). Moreover, in ORM underlying WinFS the facts may have any arity rather than only 2. In other words, in WinFS semantics is based facts, which are not primitive and hence have their own structure (and semantics) while in COM the semantics is based on primitive references while higher level relationships are derived from this basic semantics.
In WinFS relationships are treated as special elements of the model different from objects while in COM there are only concepts and their instances, which may play different roles. In particular, we can define or derive different relationships from the basic semantics.
A field in WinFS type may have multiple values (a collection or an array). In COM fields are formally single-valued while multi-valued variables are produced from subconcepts. Here WinFS follows the conventional approach while COM solves the problem at fundamental level by supposing that one-valued variable are upward directed while multi-valued variables are downward directed in the concept lattice. It should be noted that it is still possible in COM to declare mult-valued variables directly but it is a convenience method.
Although WinFS declares that relations constitute a directed acyclic graph this property is not used to derive any semantic consequences. The only purpose of this constraint consists in avoiding cycles of relations, i.e. cycles are undesirable. In COM the syntax and semantics of the model are based on the concept acyclic structure. In particular, it is the basis for grouping and aggregation mechanism. Thus this constraint is one of the primary distinguishing properties of the model.
Life cycle in WinFS is controlled by options of relations, which specify what to do if something happens with source and/or target items. In particular, there is three types of relations. Holding relationships cannot be dangling and the target instance exists as long as there exists at least one instance of this relatinships referencing it as a target. In COM this mechanism is a built-in part of the logic of references, i.e., it is an integral part of the model behavior.
In WinFS there are two types of folders: containment folders and virtual folders. There is also a special type of conainment called embedded item.
"A containment folder is an item that contains holding links to other items and models the common concept of a file system folder. An item exists as long as at least one holding link references it. Note that a containment folder doesn't directly contain the items logically present in the folder but instead contains links to those items. This allows multiple containment folders to contain the same item." So the containment folder is just like normal folder in COFS.
"A virtual folder is a dynamic collection of items. It is a named set of items. You can either enumerate the set explicitly or specify a query that returns the members of the set. A virtual folder specified by a query is quite interesting. When you add a new item to the store that meets the criteria of the query for a virtual folder, the new item is automatically a member of the virtual folder. A virtual folder is itself an item. Conceptually, it represents a set of nonholding links to items..." So virtual folder in WinFS is like a multi-valued or virtual property defined by query in the concept-oriented data model. Such a query returns a collection of items, which are members of this virtual folder. Or it can be associated with a group item (a superitem).
"A particular type of containment is an embedded item in WinFS used to implement stronger ownership than that in conventional folders (such as document attachments). There is a special type of link for that in WinFS called embedded link. The referenced item can be bound to or otherwise manipulated only within the context of the containing item." In COFS currently there is no such a separate facility. Instead we might use one-to-one constraints in the case of representation by reference. Or we could use representation of the embedded object by value or by custom reference.
WinFS has a special (dedicated) mechanism of categories. "To classify items WinFS uses the mechanism of categories. The items then can be tagged by one or more categories. The idea is that the category names can be used in searches. The categories have a hierarchical tree-like structure." COFS does not have such a dedicated mechanism. Instead, the categories can be modeled using standard facilities. In this case we can create an arbitrary structure of categories (not only hierarchical but also multidimensional), which is an integral part of the model.

References

http://www.c-sharpcorner.com/Longhorn/WinFS/WinFSDataModel.asp

Back to the Concept-Oriented Portal