Resource Registration Sample Clauses
The Resource Registration clause establishes the requirement for parties to formally record or register specific resources, such as intellectual property, assets, or data, with a designated authority or system. In practice, this may involve submitting documentation, completing online forms, or providing evidence of ownership or control over the resource in question. By mandating this process, the clause ensures that all relevant resources are properly accounted for and recognized, thereby reducing disputes over ownership and facilitating clear management and oversight.
Resource Registration. At Buyer’s sole discretion and sole expense, Seller shall assist Buyer in any reasonable manner to register the Project as a participating resource in CAISO or another applicable resource entity. All required metering will be provided by Seller to CAISO or such other applicable resource entity and Buyer for the purposes of such registration.
Resource Registration. 3.1 The Service Provider must register its Demand Response Resource as set out in section 2 of Market Manual 1.2: Facility Registration, Maintenance, and De-registration in order to participate in the demand response pilot program.
3.2 The registration process must be completed on or before April 7, 2017.
3.3 The registration process will be deemed complete when the Service Provider receives a registration approval notification (RAN) document, or equivalent, from the IESO.
Resource Registration. SC semantics can be described using ontology - a funda- mental concept for describing the knowledge of a domain, represented by a set of concepts and relationships among them. The SC semantics ontology can be designed using Web Ontology Language (OWL) specifications2. In order to design an ontology, concepts and entities of a domain must be identified, which are defined as OWL classes. Relationships between classes as object properties and those between class instances and literals as data properties are denoted accord- ingly in the ontology. Protege3, the popular ontology editor and knowledge-base framework, is used to construct the SC semantics ontology. We demonstrate the ontology design by considering a use- case that defines the eligibility criteria of a user to access an IoT device using a SC (illustrated in Fig. 2). A user is required to register an account along with a public address and an associated private key - which will be parameters for calling the SC. Therefore, the proposed ontology is designed to have a class called User which is associated with an Ethereum account, an attributes account, an address, a private key, and other details. For this purpose, a new ontology class called EthereumContractsConcepts is implemented containing Ethereum contract data property. Similarly, the ContractAccount class is implemented including the license number, expiration date, information about the IoT and SC owner, and the current status. Finally, the SC ontology is extended with the ”access condition” vocabulary, as a general domain-based ontology. In this regard, the query ”get enforce- ment policies SCs related to IoT device with ID” with specific conditions (e.g, ”a specific access condition set”) shows SCs that satisfy all the criteria of the query. 2▇▇▇▇▇://▇▇▇.▇▇.▇▇▇/OWL/ 3▇▇▇▇▇://▇▇▇▇▇▇▇.▇▇▇▇▇▇▇▇.▇▇▇/ as an RDF triple based on an extension of OWL-S ontology. Table I shows the extended OWL-S vocabulary that we used for describing the SCs.