Data Mapping Guide for MVP

Overview

Data mapping is the crucial foundation that enables interoperability between different components of the Skyocean platform. It defines how information moves between systems and ensures that data maintains its meaning and relationships throughout its lifecycle.

Why Data Mapping Matters:

Enables seamless communication between on-chain and off-chain systems
Preserves data integrity across different technological domains
Creates a standardized knowledge representation framework
Facilitates trusted knowledge asset trading without central intermediaries

Understanding Data Flow in Knowledge Asset Trading

Knowledge assets in Skyocean move through multiple systems with different data models:

Creation and Registration - Data originates in user applications
Transformation - Data is standardized into platform schemas
Storage - Data is distributed across blockchain and DKG
Verification - Data integrity is confirmed through multi-party validation
Transaction - Asset ownership transfer is executed and recorded

Each transition requires precise data mapping to maintain consistency and meaning.

Architecture Components and Their Data Roles

1. Edge Node Layer

Purpose: Creates standardized knowledge asset representations in the DKG

Why it matters:

The Edge Node translates domain-specific data into universal, interoperable formats
Uses JSON-LD to create machine-readable, semantically rich data representations
Preserves contextual meaning of data through ontology references
Enables discoverability through knowledge graphs

Data transformation responsibilities:

Converting raw knowledge assets into JSON-LD format
Assigning unique identifiers compatible with DKG standards
Embedding semantic relationships through context definitions
Publishing assets to the DKG network

2. Middleware Layer

Purpose: Bridges the semantic web of the DKG with the deterministic world of blockchain

Why it matters:

Smart contracts require specific, well-defined data structures
DKG uses flexible, context-rich semantic structures
Without middleware translation, these systems cannot interoperate
Provides crucial abstraction that shields applications from underlying complexity

Data transformation responsibilities:

Extracting critical identifiers and metadata from DKG assets
Converting semantic properties to contract-compatible structures
Maintaining bidirectional references between on-chain and off-chain data
Handling state synchronization across systems

3. Smart Contract Layer

Purpose: Provides tamper-proof record of ownership, transfers, and verification status

Why it matters:

Blockchain data must be minimal for cost and efficiency reasons
Only essential data points and references are stored on-chain
Smart contracts enforce business rules and transaction logic
Blockchain provides the source of truth for ownership and verification status

Data storage responsibilities:

Maintaining minimal asset references with verification status
Recording ownership and transaction history
Storing cryptographic proofs of larger off-chain data sets
Emitting events that trigger middleware synchronization

4. Web Application Layer

Purpose: Translates complex underlying data into intuitive user interfaces

Why it matters:

End users interact with complex multi-system data through simplified interfaces
UI requires aggregation of data from multiple sources
User actions must be translated into technical operations across systems

Complete Transaction Data Workflow

The following diagram illustrates how data flows through a complete knowledge asset transaction:

Seller

WebApp

Middleware

EdgeNode

DKG

SmartContracts

Buyer

Seller uploads knowledge asset to WebApp
WebApp sends raw asset data to Middleware
Middleware formats and sends asset metadata to EdgeNode
EdgeNode creates JSON-LD asset and publishes to DKG
DKG returns Universal Asset Locator (UAL) to EdgeNode
EdgeNode passes UAL and metadata to Middleware
Middleware registers asset on SmartContracts
SmartContracts return Asset ID to Middleware
Middleware confirms registration to WebApp
WebApp confirms asset listing to Seller
Buyer requests to purchase asset via WebApp
WebApp sends purchase request to Middleware
Middleware creates transaction record on SmartContracts
SmartContracts return Transaction ID to Middleware
Middleware requests asset details from EdgeNode
EdgeNode queries asset from DKG by UAL
DKG returns complete asset data to EdgeNode
EdgeNode provides asset data to Middleware for Buyer
Middleware sends transaction details to WebApp
WebApp requests payment confirmation from Buyer
Buyer sends payment via WebApp
WebApp confirms payment to Middleware
Middleware completes transaction on SmartContracts
SmartContracts update ownership and notify Middleware
Middleware requests EdgeNode to update DKG
EdgeNode updates asset metadata in DKG
Middleware confirms completion to WebApp
WebApp grants access to purchased asset to Buyer

Schema Mapping Implementation Details

Why JSON-LD for DKG Integration?

JSON-LD (JSON for Linked Data) is critical for our platform because:

Semantic Richness - Properties have well-defined meanings across systems
Flexible Extension - New data types can be added without breaking existing systems
Decentralized References - Enables linking to external knowledge systems
Standards Compatibility - Aligns with W3C and schema.org standards
Machine Readability - Supports automated processing and AI integration

1. Edge Node Mapping Process

// Location: edge-node/mappings/assetMapper.js
const mapKnowledgeAsset = (rawData) => {
  // Convert application-specific data to universal JSON-LD format
  return {
    "@context": {
      "schema": "http://schema.org/",  // Reuse existing standards
      "skyocean": "https://skyocean.io/ontology/"  // Custom domain ontology
    },
    "@type": "skyocean:KnowledgeAsset",  // Define asset type from our ontology
    "schema:identifier": rawData.assetId, // Unique ID
    "schema:name": rawData.title,
    "schema:description": rawData.description,
    "skyocean:assetType": rawData.type,  // Domain-specific property
    "skyocean:contentHash": rawData.hash, // Integrity verification
    "skyocean:ownerAddress": rawData.owner, // Blockchain reference
    "skyocean:creationDate": new Date().toISOString(), // Temporal metadata
    "skyocean:keywords": rawData.tags.map(tag => ({ "@value": tag })), // Searchable properties
    "skyocean:licenseType": rawData.license // Governance metadata
  }
};

What happens during mapping:

Application-specific data is transformed into standardized format
Properties are qualified with ontology prefixes (schema:, skyocean:)
Complex structures (arrays, nested objects) are preserved
Data validation occurs during mapping
The result is semantically precise, machine-readable data

2. Middleware Transformation Process

// Location: middleware/transformers/dataTransformer.js

// Transform DKG data to blockchain-compatible format
const transformForBlockchain = (dkgData) => {
  // Extract only essential data for on-chain storage
  return {
    assetId: dkgData["schema:identifier"],
    metadata: {
      title: dkgData["schema:name"],
      description: dkgData["schema:description"],
      assetType: dkgData["skyocean:assetType"]
    },
    contentHash: dkgData["skyocean:contentHash"],
    owner: dkgData["skyocean:ownerAddress"]
  };
};

// Transform blockchain event data to DKG-compatible format
const transformFromBlockchain = (event) => {
  // Create or update DKG asset with blockchain data
  return {
    "@context": {
      "schema": "http://schema.org/",
      "skyocean": "https://skyocean.io/ontology/"
    },
    "@type": "skyocean:BlockchainTransaction",
    "skyocean:transactionHash": event.transactionHash,
    "skyocean:blockNumber": event.blockNumber,
    "skyocean:eventType": event.event,
    "skyocean:assetReference": event.args.assetId,
    "skyocean:newOwner": event.args.buyer,
    "skyocean:timestamp": new Date().toISOString()
  };
};

What happens during transformation:

Complex DKG data is simplified for blockchain storage
Only essential properties are extracted, reducing gas costs
Blockchain events are captured and converted to DKG-compatible formats
References are maintained to link on-chain and off-chain data
Bidirectional mapping enables synchronization between systems

Ontology Design for Maximum Interoperability

Skyocean’s ontologies define the formal vocabulary for knowledge asset trading. They serve as the semantic contract between systems, ensuring consistent understanding of data across components.

Core Ontology Design Principles

Reuse existing standards - Leverage schema.org, Dublin Core, and other established vocabularies
Minimize custom terms - Only create custom terms for domain-specific concepts
Hierarchical organization - Establish clear parent-child relationships between concepts
Clear property definitions - Each property has explicit range, domain, and cardinality
Version management - Support ontology evolution without breaking existing data

Core Ontologies

Asset Ontology

skyocean:KnowledgeAsset: description: “A tradable unit of knowledge with defined ownership and verification” subClassOf: schema:CreativeWork properties: - skyocean:assetType: description: “The type of knowledge asset (dataset, algorithm, document)” range: skyocean:AssetType - skyocean:contentHash: description: “Cryptographic hash of the asset content for verification” range: xsd:string - skyocean:ownerAddress: description: “Blockchain address of current owner” range: xsd:string - skyocean:verificationStatus: description: “Current verification state of the asset” range: skyocean:VerificationStatus - skyocean:tradingStatus: description: “Current trading state (listed, sold, restricted)” range: skyocean:TradingStatus
Transaction Ontology

skyocean:TradeTransaction: description: “Record of knowledge asset transfer between parties” properties: - skyocean:transactionId: description: “Unique identifier of the transaction” range: xsd:string - skyocean:buyer: description: “Entity acquiring the knowledge asset” range: schema:Person or schema:Organization - skyocean:seller: description: “Entity transferring the knowledge asset” range: schema:Person or schema:Organization - skyocean:assetReference: description: “Reference to the traded knowledge asset” range: skyocean:KnowledgeAsset - skyocean:status: description: “Current state of the transaction” range: skyocean:TransactionStatus - skyocean:documents: description: “Supporting documents for the transaction” range: skyocean:Document cardinality: zero or more

Implementation in Different System Layers

1. Edge Node Implementation

The Edge Node uses the full ontological structure:

// Location: edge-node/config/ontology.js
const ontologyConfig = {
  baseContext: "https://skyocean.io/ontology/",
  mappings: {
    KnowledgeAsset: {
      type: "Asset",
      properties: [
        "identifier",
        "name",
        "description",
        "assetType",
        "contentHash",
        "ownerAddress",
        "verificationStatus",
        "tradingStatus",
        "creationDate",
        "keywords",
        "licenseType"
      ]
    },
    TradeTransaction: {
      type: "Transaction",
      properties: [
        "transactionId",
        "buyer",
        "seller",
        "assetReference",
        "status",
        "documents",
        "timestamp",
        "transactionHash",
        "blockNumber"
      ]
    }
  }
};

2. Smart Contract Implementation

Smart contracts use a minimal representation of the ontology:

// Location: contracts/KnowledgeAssetRegistry.sol
struct AssetMetadata {
    string assetType;
    string contentHash;
    address owner;
    VerificationStatus status;
}

enum VerificationStatus {
    Unverified,
    Pending,
    Verified,
    Rejected
}

// Mapping from asset ID to metadata
mapping(string => AssetMetadata) public assets;

Practical Implementation Process

1. Ontology Definition First

Before writing code, define the ontology:

Identify key concepts (Asset, Transaction, Document)
Define properties for each concept
Establish relationships between concepts
Document in machine-readable format (RDF, OWL)
Publish ontology at persistent URL

2. Schema Implementation

After ontology definition:

Create JSON-LD contexts that reference the ontology
Define schema mappings for each data source
Implement validation rules for schemas
Create example instances for testing

3. Middleware Development

With schemas defined:

Implement transformation functions between schemas
Create validation middleware
Build API endpoints for data access
Develop event handlers for blockchain events

4. Integration Testing

End-to-end testing for data flow:

Create test assets with known properties
Trace data transformation through each system
Verify property preservation
Test roundtrip conversions
Validate interoperability with external systems

Why This Approach Ensures Interoperability

Semantic Foundation - Ontologies provide shared understanding across systems
Standard Formats - JSON-LD enables interconnection with semantic web
Bidirectional Mapping - Data can flow between blockchain and DKG
Clear Boundaries - Each system has well-defined data responsibilities
Explicit Transformations - All data changes are documented and traceable

Next Steps for MVP Implementation

Define and publish the core Skyocean ontology
Implement base schema mappings for assets and transactions
Develop Edge Node configuration for DKG integration
Create middleware transformers for blockchain integration
Integrate with the web application
Run end-to-end tests for complete transactions
Monitor and optimize data flow through all systems

Data Mapping Guide for MVP

Overview

Understanding Data Flow in Knowledge Asset Trading

Architecture Components and Their Data Roles

1. Edge Node Layer

2. Middleware Layer

3. Smart Contract Layer

4. Web Application Layer

Complete Transaction Data Workflow

Schema Mapping Implementation Details

Why JSON-LD for DKG Integration?

1. Edge Node Mapping Process

2. Middleware Transformation Process

Ontology Design for Maximum Interoperability

Core Ontology Design Principles

Core Ontologies

Implementation in Different System Layers

1. Edge Node Implementation

2. Smart Contract Implementation

Practical Implementation Process

1. Ontology Definition First

2. Schema Implementation

3. Middleware Development

4. Integration Testing

Why This Approach Ensures Interoperability

Next Steps for MVP Implementation

References