User talk:Dzonatas Sol/AWG Asset

The identifier for an asset OUTSIDE a specific domain (trust domain, region domain, region, etcetera) is not a UUID, it's a URL. The form of the URL is unspecified, except that the host-part is the address of the asset server responsible for that asset, and that the asset can be manipulated with POST and GET commands passing standard URI-encoded parameters.

Within a domain the identifier of an asset is a UUID that is unique within that dmain and other domains sharing the same trust environment.

Assets hosted in other domains are mapped to UUIDs in a manner that is up to the domain. The expected technique is to create a new instance of the asset, containing a location property with the URI of the original asset, with all other properties copied from theoriginal, and with the asset data possibly cached in the local asset server.

• • • -- Argent Stonecutter 19:11, 23 October 2007 (PDT)

The inside/outside view of the identifier is true for what you say with and without the URL. The technique to create a new instance all depends on if the properties allow. A non-copiable tangible asset may have only a single instance in the entire grid, but there may be several referential assets to allude back to the single non-copiable instance. (See: #The Chair)

• • • Dzonatas Sol 19:31, 23 October 2007 (PDT)

The Chair

This where the "chair" question came about. What happens if the chair is made up of copiable and non-copiable assets where each piece of the chair being separate intellectual property and each IP owned individually by different people. Let's say the chair was manufactured by buying the seat separately from the base, and separately from the feet, and separately from the textures, so the chair then was assembled together by a person who bought all those pieces from different people. The assembled chair then is set to sell. How does one buy it? What are the steps to perform this? How does each step look in the databases for where each asset exists?

• • • Dzonatas Sol 19:31, 23 October 2007 (PDT)

Primary Database Thoughts

• In a decentralized system, there is always the potential net splits to occur. Methods need to be developed to prevent irrational assets or even broken referential assets. For example, one could require the complete form of an intellectual property be stored all in a single primary database with all related assets that constitute that form instead of being allowed to exist in multiple primary databases. Dzonatas Sol 23:07, 22 October 2007 (PDT)

• It is obvious that movement of tangible assets from one primary database to another primary database needs a cHTTP basis to communicate the move. Dzonatas Sol 23:07, 22 October 2007 (PDT)

• One way to avoid irrational assets is to allow secondary database be local to a primary database such that the secondary database stores abstract assets instead of the attempt to create irrational assets. I've done a similar scheme like this before on a very small scale, and I already know it is test cases with abstract assets are not as simple as to allow irrational assets. There are, however, less redundant sanity checks are needed with abstract assets locally to the primary database, and it reduces a load on the primary database with assets that would become tangible but actually remain transient. Dzonatas Sol 23:07, 22 October 2007 (PDT)