This article provides a brief introduction to NetX's main objects. The headers below provide a list of the core objects, but this is by no means a complete list. Please also know that the APIs will often refer to these objects with a legacy nomenclature, which is noted parenthetically in each header. — ie "Asset" and "Image" are interchangeable in the API object model.
An Asset is defined as a single indexed record in NetX, which is comprised of either an associated file, associated metadata, or both. In some cases, an Asset will begin its lifecycle as purely metadata. In other cases, an Asset record may have various historical versions, and/or view files (typically different variations of the main "master" Asset file. In both of these extremes however, there remains a single database and index record for that Asset. NetX can store, organize, manage, and distribute any type of asset file.
NetX provides for a hierarchical organization of all stored assets by way of a folder tree system. Folders are individual nodes, or branches. Folders can be parents or children to other folders. Additionally, folders can contain both sub-folders and assets. This is very similar to a file system – folders are effectively directories (also known as "categories"). The entire folder structure provides taxonomy for your assets. Additionally, this structure is directly exposed to the users of NetX as a way to logically browse for the assets they are looking for. Named folders are entirely custom to each instance of NetX. For example, a Manufacturer will want to store products in a structure that mimics the way they think about their product line. A pre-press company may want to organize assets according to their clients. And your folder structure will be unique to your organizational needs.
A version is a recorded historic change to an asset file. If you check in a new copy of an asset file, a new version record is created. In this way, you can track changes to files, and revert to earlier copies as needed.
An asset "view" is simply file attachments to the Asset record. The name implies a visual representation, but that's not necessarily the case; XML, document and other file types can be attached to an asset just as easily as a JPG.
NetX provides a mechanism for collecting assets for the purpose of performing some function on the entire collection at once, instead of having to do everything one at a time. While other systems refer to such a mechanism as a basket, a lightbox, or other titles, NetX calls this function a collection (and in the API as a "cart"). For most users, the Collection provides way to select asset files for quick downloading: with the click of a button, batch actions allows users to download a zip archive of all assets in their selection. At a more advanced level, a collection is a powerful tool for administrators who need to process many assets at once (for example, updating, organizing, or deleting). A collection is also useful for repurposing many assets at once with this same transformation, say converting all image files into JPEGs for a Web site.
A user is a person who uses NetX. From a technical perspective, a user is a recognized account within NetX, consisting of a login, password, email, and other information about that person. Users are further defined by their user level. NetX provides for many levels of functionality that can be defined per user. That is, you want certain people to administer NetX others, should merely be able to access assets without the capability to make modifications. User levels are distinct from asset and category permissions, which will be explained in another section. User levels deal exclusively with degrees of exposed functionality.
A Group is a named collection of users. Groups can be used in two ways: 1) a mechanism to email to particular groups of users; and 2) a mechanism for restricting access to particular assets and/or categories. While this section will not describe how to set up permissions (a later chapter does this), generally, the idea is to name a Group. Then, you add users to your named Group; creating a collection of users. Next, you can add this Group to either individual assets, or particular folder. This sequence then defines access permission, when wanting to restrict certain users from certain assets (or categories of assets). In other words, restricting users is done in the reverse: you actually define privileges, not limitations.
File Format ("File_Type")
NetX associates file formats by the file’s extension. Asset files must have a valid extension in order to import into NetX. The extension provides the ability for NetX to determine what action to take on the file during importation; also, it allows NetX to determine whether a particular file can be repurposed (for example, it can convert a TIFF to a JPEG, but it can’t convert a text file into a JPEG). NetX can be configured to reject certain file formats (for example you may want to block storage of EXE files). NetX provides an administrative section for managing file formats.
Storage Locations are defined as particular file storage facilities. That is, NetX’s repository can span more than a single hard disk. Additionally, Locations are further defined by type. Generally, there are online, offline, and nearline location types. Online locations are facilities that are directly accessible by NetX; most of the time, this means a mounted file system such as a hard disk, RAID device, NAS, SAN, etc. Offline locations are file systems that are not directly accessible to NetX. Nearline locations are something in-between an online location and an offline location; generally this is a device or resource that is not necessarily immediately available. NetX also has the ability to store assets remotely via HTTP; NetX also considers this storage as nearline because of the possibility of temporarily loosing the ability to directly access the asset if the network, the Web server, or any other factor fails. Essentially, a Location is just a place to store asset files within NetX.
ERD (Sort of)
Technically, this is not an ERD. This is offered to present the core object model, so you can see the relationships conceptually. If you need an ERD and have an on-premise installation of NetX, you are welcome to model the application schema in your favorite ERD program. Instead, this is presented to help you visualize how the objects are linked.