The basic object model in Assets Server is very simple, it contains:
Each file imported in to the server is called an asset. Each asset has metadata, which is a flat list of property names with a value.
Each metadata property has a unique name. For each metadata field, the server knows:
- how to handle it when indexing and searching,
- what type of data it contains (text, number, date, ...),
- how it is embedded in certain file types,
Assets Server has a long list of standard metadata fields that are commonly used in a DAM system, and it already knows how to handle these. If none of these fields suits your needs, you can create as many additional custom metadata fields as you need.
Collections are assets like all other files. This means they can have metadata and can be searched for as normal assets can be. The contents of a collection are defined by 'contains' relations linking to the contained assets.
Collections are stored in the mainFilestore, but just as 0 kb files to reserve the file location.
Relations are 'links' between assets. A relation knows both of the assets that it links together. This means a relation can always be discovered from both ends of its link.
For more information, see How files are related to each other in Assets Server.
Folders in Assets Server are nothing more than just folders as you know them on your operating system. They are used to store files (assets) and organize them in hierarchical structures.
Tip: If you look in the <Elvis Data>/mainFilestore folder, you can see that the server stores all the originals in the same folder structure as shown as for example in Assets.
Warning: Do not modify files directly in the mainFilestore! If you do so, the server's index will not be updated with your changes and will no longer be in sync. ONLY make modifications through the API or Assets.
The location of each asset is described in the assetPath metadata property. It describes the location of an asset relative to the root of the mainFilestore:
/Demo Zone/Images/Beaches/Kauai.jpg <![CDATA[ ]]>
An assetPath always starts with a slash and never ends with one. It always uses forward slashes to separate folders (also on Windows), similar to a URL.
How Assets Server knows where to store a file
When you import and create assets in Assets Server using the API, there are several combinations of metadata that can be specified to build up an assetPath and determine where the file will be stored. The following table indicates the various ways in which this info can be specified. If none of these combinations are available, the server will not be able to create the asset.
|<![CDATA[ ]]>||Asset path||File name||Name||Asset type||Extension||Folder path||<![CDATA[ ]]>|
|specified||ignored||ignored||ignored||ignored||ignored||When assetPath is specified, the other fields are ignored, instead they are calculated.|
|not specified||specified||ignored||ignored||ignored||optional||The filename provides enough info the calculate the assetType, extension and name. When no folderPath is specified the system will place the file in a default location (<user-security-zone>/auto-stored/<year>/<yyyyMMdd>/)|
|not specified||not specified||specified||specified /optional||specified /optional||optional||When only a name is specified and no folderPath is specified, either assetType or extension should be specified.|
|not specified||not specified||not specified||ignored||ignored||ignored||When none of assetPath, filename or name is specified, the asset cannot be created.|
Within root folders, you can create as many subfolders as you want to organize your content.
The actual location of the file is not important, people or automated processes may just dump all files in one place. After all, even without knowing where it is stored, assets can easily be found using the search engine, the metadata or text content of assets.
Depending on the file system that is used, there may be limits to how many files can be stored efficiently in a single folder. To prevent too many files from being imported into top-level folders, the server uses a few simple mechanisms to automatically organize files that are dumped into the system without specifications.
If an asset is imported into a top-level folder, it will automatically be moved to the "Auto organized" folder. For example if the user tries to import a file to one of these location:
/Zone A <![CDATA[ ]]>
/Zone A/Auto organized <![CDATA[ ]]>
The system will automatically create a folder for the current day and store the assets in there:
/Zone A/Auto organized/2011/2011-01-18 <![CDATA[ ]]>
This also works in the root of each users private user folder:
/Users/<username>/Auto organized/2011/2011-01-18 <![CDATA[ ]]>
When you import assets into a specific subfolder, auto-organize is not used.
The root and /Users folder
The root and Users folder are off-limits to anyone. If someone tries to import a file into the root folder ("/") or into the /Users folder, this is considered a mistake and the file will instead be imported to the private folder of that user (/Users/<username>/Auto organized/...).
Do you have corrections or additional information about this article? Leave a comment! Do you have a question about what is described in this article? Please contact Support.
Please sign in to leave a comment.