StyleBooks, or StyleContracts, are analogous to "smart contracts" except that you build them in your presentation layer, instead of in your application layer (think "OSI model, but with an opinionated vantage to writing formal input specification languages: embeddings, links, templates for hypermedia purposes).
There are many kinds of digital or virtual contracts. "Smart" means little other than that one is developing a digital or virtual contracts such that it connects to a server, or thereabouts a digital or virtual (infocological) network. Ethereum discusses "embeddings" (mappings), "links" (functionings), and "templates" (eventings). But also your waiter at a restaurant is a "virtual server". A node on the Ethereum network or the Bitcoin network is a "digital server"; an Ethereum contract, ontologically non-autopositioned, would be a "virtual server" between two digital servers, surrogates to humans, generally somewhere on the planet, or some remote other spatiotemporal designation. Indeed, these two ontologically diametrically opposed entities can exist within the same automation framework formally expressed with rules, properties as relations, refinements, constraints, etc.
So, we see Ethereum essentially analogizes to a (REST-ful) HATEOAS Affordance API Specification:
Contract writing is one thing. Another matter is the problems being addressed. Grammuelle is concerned with the Discovery layer overall. You can choose ODRL or Ethereum's ERC specification. But generally anything that can be expressed in ODRL can be expressed in ERC, even if it might be an incoherent concept in the language of blockchain ownership for the "Party" function, or if the conceptual relationship between parties is simply not meaningful in a blockchain, one might choose ODRL without loss of granularity. One can express their entire domain problem in the affordance API manner, and if transfer is needed, that can be chosen on a unique basis because renegotiation and invalidation cyclonomic complexity depends on a blockchain specifically. Don't throw a whole blockchain world computer at your infrastructure if it can be written in a few lines of code in nodeland and deployed at an endpoint microservice.
So now each link relation binds as a Function in this analogy to ERC. Templates might be Simple! Now we have an entire lingua franca of "ERC" extensions to interplay with constraints, counterparties, assets, and duties subtended by permissions of policies.
Can we say each endpoint has a "Policy"? Well, it might fall under one, in just the way some endpoint might fall under an ERC Contract. A Policy might govern multiple ERC Contracts, or a contract might appeal to some behavior of a policy. It depends on the needs of the parties and their corroborations with templexity and cyclonomic complexity.
Basically, you can think about your technological (MVP) and businessinvestment in terms of cyclonomic (cyclomatic) complexity
StyleBooks, or StyleContracts, are analogous to "smart contracts" except that you build them in your presentation layer, instead of in your application layer (think "OSI model, but with an opinionated vantage to writing formal input specification languages: embeddings, links, templates for hypermedia purposes).
There are many kinds of digital or virtual contracts. "Smart" means little other than that one is developing a digital or virtual contracts such that it connects to a server, or thereabouts a digital or virtual (infocological) network. Ethereum discusses "embeddings" (
mappings), "links" (functionings), and "templates" (eventings). But also your waiter at a restaurant is a "virtual server". A node on the Ethereum network or the Bitcoin network is a "digital server"; an Ethereum contract, ontologically non-autopositioned, would be a "virtual server" between two digital servers, surrogates to humans, generally somewhere on the planet, or some remote other spatiotemporal designation. Indeed, these two ontologically diametrically opposed entities can exist within the same automation framework formally expressed with rules, properties as relations, refinements, constraints, etc.So, we see Ethereum essentially analogizes to a (REST-ful) HATEOAS Affordance API Specification:
Contract writing is one thing. Another matter is the problems being addressed. Grammuelle is concerned with the Discovery layer overall. You can choose ODRL or Ethereum's ERC specification. But generally anything that can be expressed in ODRL can be expressed in ERC, even if it might be an incoherent concept in the language of blockchain ownership for the "Party" function, or if the conceptual relationship between parties is simply not meaningful in a blockchain, one might choose ODRL without loss of granularity. One can express their entire domain problem in the affordance API manner, and if transfer is needed, that can be chosen on a unique basis because renegotiation and invalidation cyclonomic complexity depends on a blockchain specifically. Don't throw a whole blockchain world computer at your infrastructure if it can be written in a few lines of code in nodeland and deployed at an endpoint microservice.
So now each link relation binds as a
Functionin this analogy to ERC. Templates might be Simple! Now we have an entire lingua franca of "ERC" extensions to interplay with constraints, counterparties, assets, and duties subtended by permissions of policies.Can we say each endpoint has a "Policy"? Well, it might fall under one, in just the way some endpoint might fall under an ERC Contract. A Policy might govern multiple ERC Contracts, or a contract might appeal to some behavior of a policy. It depends on the needs of the parties and their corroborations with templexity and cyclonomic complexity.
Basically, you can think about your technological (MVP) and business investment in terms of cyclonomic (cyclomatic) complexity