Web Content with server-side script
The Neuronยฎ supports server-side script in multiple types of documents that are used in web applications. This article provides a short overview.
| File types supporting server-side script | ||
|---|---|---|
| Extension | Type | Description |
.md |
Markdown | Markdown files can embed server-side script in two forms, both inline, between single { and }, or preprocessed between {{ and }}. |
.cssx |
CSS | Extended (x) CSS files that can include preprocessed script between ยค characters. Inline script is not supported. |
.htmlx |
HTML | Extended (x) HTML files that can include preprocessed script between {{ and }}. Inline script is not supported. |
.jsx |
JavaScript | Extended (x) JavaScript files that can include preprocessed script between {{ and }}. Inline script is not supported. |
.ws |
Web Service | A script file that can be executed when called as a web service. |
Note: Preprocessed script can alter the structure of the document, as it is processed before the document is parsed. Inline script however, is embedded into the document after the document structure has been parsed, and can therefore not alter the underlying document structure.
Adding custom HTTP headers to web resources
You can add custom HTTP response headers to content hosted by the TAG Neuron® in different ways: If you publish content using Markdown you can use (meta-data tags)(/Markdown.mdmetadata) to add custom HTTP response headers when the page is displayed. But if you publish other types of content which the Neuron® simply forwards to web clients (such as HTML pages) you can configure custom default HTTP Response headers anyway. You can define them in general, for all content in the Root folder, or you can specify them specifically for content in specific file folders. All these configurations are done in the Gateway.config file in the program data folder, and require the Neuron® to be restarted after configuration. You can edit the contents of this configuration file from the web-based Admin interface (or other admin interfaces) available on the Neuron®.
Note: One reason to configure custom default HTTP headers, is if you want to configure Cross-Origin Resource Sharing (CORS) for your site.
To edit the configuration file, find the Sources & Nodes command in the Data section on the main menu:
When clicking on the button, a new page appears with available Data Sources and their nodes, in a tree structure. What data sources and nodes are available here, depends on earlier configuration and available software modules, as they can extend the types of sources and nodes you can use. Find the Gateway configuration data source, and expand it, and then select the WebServer node, and then click the Add button. This command will display types of nodes you can add to the Web Server.
To add the CORS header Access-Control-Allow-Origin, and allow javascript to call resources on any domain, click the Default HTTP Header button. This will add a new node of this type to the selected node (the WebServer node). Adding a Default HTTP Header to the Web Server node, will create a default HTTP header for all resources in the Neuron® root folder. You can also add Default HTTP Header nodes to specific file folder nodes. In that case, the default HTTP header will only be added for resources in that file folder.
Press the Create button to create the node. The rule will not be applied before you restart the Neuron®, so restart it when you are ready. After a restart, you can navigate to any resource in the root folder and check the HTTP headers in the response, using the browser’s developer tools, to see that your custom default HTTP response header is available in your responses.
Web folders for sub-domains
The the Neuron® now facilitates distribution of content packages for sub-domains. The integrated web server publishes files from in the C:\ProgramData\IoT Gateway\Root folder (a.k.a. the Root folder) on the web. If the Neuron® supports multiple domains, you can put domain-specific files in subfolders having the same name as the corresponding domain name. A Neuron® with domain name example.com and alternative domain name example.org would publish the contents of the Root folder on both names. But files in the Root\example.org folder would be accessible only to clients getting files from the example.org domain name. (Files are also accessible from the example.com domain name, if the file names are preceded by the alterantive domain name. For example, https://example.org/Folder/File.html would also be accessible on https://example.com/example.org/Folder/File.html).
From build 2023-08-25, this feature has been extended to sub-domains. If the Neuron® also has an alternative domain sub.example.com, files in the Root\sub folder would be available when viewing contents on the sub.example.com domain.
This simplifies the distribution of software packages across the Neuron®-network, whose content is supposed to be accessible on sub-domains on the corresponding Neurons. As all Neurons have different domain names, folders using the full domain name would complicate distribution. However, by using on the subdomain as folder name, the software package would be successfully delivered to all neurons, regardless of each one’s main domain name.
Note: If adding a domain or a subdomain to a Neuron®, don’t forget to add the domain (or subdomain) to the list of alternative domain names, under Admin / Communication / Domain, and create a new certificate.
Semantic Web technologies for real-time Web of Things
The following video is a recording of a presentation, where I introduce the new support for Semantic Web technologies in the TAG Neuron®, and how it can be used to query, join and consolidate information that is available in both external and local data sources (graphs), as well as real-time communication devices, such as sensors and actuators. The Semantic Web technologies presented are standardized by the W3C, so the solution (the only solution in the world?) provides a query language for stored and real-time information in a federated network that is 100% built on standards. No proprietary languages or APIs necessary, reducing costs and complexity of implementaton.
Neurons now incorporate a SPARQL endpoint
TAG Neuron®s now incorporate a SPARQL endpoint (as of build-time 2023-07-03). SPARQL is a standardized SQL-like federated query language for information in the semantic web. SPARQL allows you to ask the entire federated network a query, which is processed in a decentralized manner, and consolidated into one response, without having to resort to collecting information into centralized repositories. With this new SPARQL endpoint, you can build systems and services that use 100% standardized interoperable queries to process information in a decentralized federated Neuron®-network. Processing information in this way represents the highest category of linked data for the web, sometimes also referred to as the five stars of open data. Combining federated web standards for the semantic web with the federated and secure nature of XMPP allows for both flexibility, interoperability and security.
Use cases
SPARQL is suitable for a wide range of applications: Consolidating information across boundaries, for instance in open data or smart city solutions, where data from different organizations need to be joined. As the semantic web standards are joined with XMPP (using the httpx URI scheme from XEP-0332), confidential and personal information can also be processed securely, without risking the data end up in the wrong hands. Queries can be processed in the secure context of digital identities of users, processors and controllers, assuring access is only granted to authorized entities.
Real-time data
The TAG Neuron® also provides access to real-time data from devices via semantic resources, making it possible to join data stored in graph data stores, with real-time data directly from the devices, without collecting and storing them in data lakes. This maximizes privacy and security, minimizes latency, and saves on communication resources and bandwith, as access to devices is only necessary when someone actually requires access, not as a means to have a relatively recent value available in a database, should someone want to access it.
Access
Access to the SPARQL endpoint is through the standardized /sparql resource on the Neuron®. Access rights to the resource needs to be granted. On a TAG Neuron® you can request access via the /Feedback.md page. You can access these on the Lab-Neuron®, via the following links:
- SPARQL Endpoint on the Lab Neuron®, also accessible via a web form.
- Request Access to the Lab Neuron®. Make sure to state full name, e-mail and purpose.
- You can also download, install and host your own Neuron®.
Graph Store (Graph Database)
The TAG Neuron® also supports the SPARQL Graph Store Protocol, which allows authorized entities to use the Neuron® to store semantic graphs on the Neuron®. They can add, update, retrieve, delete, and query such graphs. Once a graph has been added to the graph store, the URI of that graph will point to the graph stored in the graph store, and no HTTP GET to the URL will be performed, when querying the graph. This also allows for the creation of graphs with URIs that do not point to actual semantic data sources.
The resource used for accessing the graph store, is the /rdf-graph-store resource, as shown in the W3C standard specification of the graph store protocol. On the Lab Neuron®, this corresponds to https://lab.tagroot.io/rdf-graph-store. There’s a web form you can use, that interacts with the underlying graph store API also.
The default graph in the graph store consists of references to graphs in the graph store. This can be used to loop through graphs in queries, using the GRAPH pattern.
Privileges
To access the different featured mentioned, the following privileges are required to be held by the entity performing the actions:
| Action | Privilege Required |
|---|---|
| SPARQL Query | Admin.Graphs.Query |
| Create Graph | Admin.Graphs.Add |
| Update Graph | Admin.Graphs.Update |
| Delete Graph | Admin.Graphs.Delete |
| Get Graph | Admin.Graphs.Get |
Standardized/Interoperable Data formats
Data formats for semantic information vary. Apart from internal processing and transformation (for example for real-time data from sensors), and bespoke data formats, the following formats/representations are supported in federated queries, for interoperability:
- Semantic Information (Graphs)
- SPARQL Query
- SPARQL Results
Data representation format is indicated using the HTTP Header Content-Type, while response type is requested using the Accept header.
Example
The following example shows a simple query for a sensor data from semantic information stored in a graph, hosted in a GitHub repository. The query does not select the graph in this example, instead it is provided via an additional input on the form. (Graphs can be specified both in the query directly, or via one or more input fields.)
Click Execute to execute the query. The result is shown dynamically below the buttons, in the format requested.
While this example is done via the web form available on the Neuron®, it can be automated via the standardized /sparql resource as well.
Posts tagged #web
No more posts with the given tag could be found. You can go back to the main view by selecting Home in the menu above.