nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

Content type properties or aspects ?

paulkeogh

Is the following assertion correct:

The XML file that defines a model can contain many content types. Each type can have a set of properties that are relevant to that type only. The file can contain aspects that are relevant to all defined content types.

In summary, properties are per content type whereas aspects apply to all content types in a model.

Find more posts tagged with

Comments

davidc

Hi,

Your assertion is correct, but I just wanted to clarify nodes, types, aspects and properties here…

Every node stored in the repository can support zero or more properties. For example, each folder created in the alfresco web client is stored as a node with a property called name (along with other properties too).

A model provides meta-data describing the property values that can be assigned to a node. Each property value may be data-typed, given a default etc. It also describes how nodes can be associated to each other. In effect, a model constrains what is otherwise a very free network of nodes and associated properties held in the repository.

Each model consists of type and aspect definitions. Each type and aspect can support zero or more property definitions (as well as associations etc) where the name, data-type, default value etc is declared.

A node is tied to a model via its primary type and aspects (also known as mixins in JSR-170 speak). A node must be of a single primary type (which is designated at node creation). On top of that, a node may also be designated zero or more aspects.

Typically, aspects are defined when it is known that a section of meta-data can be applied across a type model. For example, to represent folders and files, the types Folder and File can be declared with their specific property and association definitions. When a node is created, it's either a Folder or File (the primary type). On top of that, to represent services that cut-across both Folder and File, an aspect is declared e.g. Lock which declares properties such as the lock type and lock owner. The Folder and File nodes can then be assigned the Lock aspect. So, a general lock service can treat any node that is assigned the Lock aspect in a consistent manner.

We do exactly the above to support services such as Lock, Version, Translation, Categorisation etc; services which may apply to any type model.

You can think of types and aspects as Classes and Interfaces in Java.

Let me know if that clears it up.

cgagne

I see that Alfresco has DublinCore established as an aspect, not properties. I see that Author is a separate aspect. Is there an advantage to have an identifier for a document stored as a DublinCore entry or as a content type property? A major purpose of meta data is to support document discovery and aid in filtering your results lists. But are fact stored in either properties or aspects equally available in the searches?

If I collect information as a content type property, can it be used to populate records in a Dublin Core aspect node?

Thanks,
cynthia

davidc

A Type and an Aspect are very similar. Both provide a definition of properties that may be applied to a Node. All properties (regardless of whether defined against a Type or Aspect) are searchable. It's possible to switch off indexing of a property via its dictionary definition in which case searching is not available.

If I collect information as a content type property, can it be used to populate records in a Dublin Core aspect node?

Imagine we have:

Type: SOP
Property: Name, d:text

Aspect: DublinCore
Property: Publisher, d:text
Property: Identifier, d:text
‍‍‍‍‍‍‍

Then we can create a node in the repository that looks like:

Node (id: 1)
Primary Type: SOP
Aspects: DublinCore
Property: Name = Review & Approve Process
Property: Publisher = QA Department
Property: Identifier: SOP23
‍‍‍‍‍‍‍

As you can see, all properties regardless of Type or Aspect are first-class properties of the node and have equal search and edit capabilities. There isn't a seperate DublinCore aspect node.