The use of autonomous robots in both industry and every day life has increased significantly in the recent years. A growing number of robots is connected to and operated from networks, including the World Wide Web. Consequently, the Robotics community is exploring and adopting REST (Representational State Transfer) architectural principles and considers the use of Linked Data technologies as fruitful next step. However, we observe a lack of concise and stable specifications of how to properly leverage the RESTful paradigm and Linked Data concepts in the Robotics domain. Introducing the notion of Linked Robotic Things, we provide a minimalistic, yet well-defined specification covering a minimal set of requirements with respect to the use of HTTP and RDF.
Robotic systems are widely used in modern society and have significant impact to economics and social aspects. However, most of these robots are not able to act in a context aware manner. For example, many industry robots execute hard coded programs in a caged working space. With the increasing demand for flexibility in production processes and enhanced human-robot collaboration, robotic systems have to interact naturally with their environment, other robots and humans. To achieve this, robotic systems must acquire deeper knowledge about their environment, for example by tapping into other software and information systems.
In this respect, Kamei et al. [
SEMANTiCS 2017 workshops proceedings: LIDARI September 11-14, 2017, Amsterdam, Netherlands Consequently, the Robotics community is exploring and adopting REST (Representational State Transfer) architectural principles and considers the use of Linked Data technologies as fruitful next step. However, we observe a lack of concise and stable specifications of how to properly leverage the RESTful paradigm and Linked Data concepts in the Robotics domain.
In the scope of this paper, we identify a set of desiderata that we consider vital for successfully implementing Linked Data-driven robotic systems and applications. Introducing the notion of Linked Robotic Things, we provide a minimalistic, yet well-defined specification covering a minimal set of requirements with respect to the desiderata identified. Our contributions include in particular: (1) the Robotic Thing Model, a minimalistic core specification for truly RESTful “Web Robotics”. (2) the notion of Linked Robotic Things as a semantic extension of Web-enabled robots. (3) the Linked Robotic Thing Model, a basic contract allowing clients to automatically discover and interoperate with Linked Robotic Things.
The remainder of this paper is organized as follows. We outline the development of “Web Robotics” and report on recent research in the Linked Data community (cf. Section 2). Next, several high-level desiderata for Linked Data-driven robotic systems and applications (cf. Section 3) are discussed. Section 4 presents a minimal speciifcation of Web-enabled robots meeting the criteria for level 3 of the Richardson Maturity Model. We propose a semantic extension of Web-enabled robots in Section 5, and define the Linked Robotic Thing Model in Section 6. Future work is outlined in Section 7 , and we conclude with summary in Section 8. 2
Active since 1994, the UWA Telelabs Project ofers remote access to
an industrial robot for tele-manipulations in a blocks world and
initiated the subfield of “Internet Robotics” [
Following the very same line of argument, the Linked Data
community explores the relationship between software and information
systems and the Web. Initially focusing on aligning SPARQL with
REST architectural principles [
However, facing the lack of any standardization or widespread
adoption of Linked Services, a fatum shared with Semantic Web
Services [
Recent developments in Linked Data and Hypermedia research might help in setting priorities for a roadmap towards Linked Data in Robotics. In the following, we discuss several high-level desiderata for Linked Data-driven robotic systems and applications that we feel free to coin Linked Robotics.
RESTful interface designs in industry and academia is
focused on devising resource identifier schemes and discussing
the semantics of HTTP verbs in context thereof. Such designs
are oftentimes in violation with the “URI Opacity Axiom”
[
based computing play major roles in various topics in Robotics including real-time control, human-robot interactions or sensor perception and fusion. REST architectural principles, however, enforce stateless request-response messaging 1We use X-RMM as a shorthand for Level-X Richardson Maturity Model. patterns and, therefore, seemingly violate some core requirements of Robotics. Yet, there is a number of established RESTconformant techniques for providing event-triggered callbacks and protocol upgrades to full-duplex streaming communication. We believe these techniques to be potentially suitable, but they require further evaluation and elaboration in the Robotics domain.
D4 Semantic descriptions of robotic configurations and scenarios: With Linked Data we have the ability to integrate all addressable web resources with the Web representation of robotic systems. A real added value results from exposing the entire robotic world model with configurations, abilities, sensor data, knowledge about the environment and the current tasks of a robot in a semantically useful way. Additional resources can be integrated to provide a better understanding of the robotic world model for other Web-based systems.
tic description of robotic configurations and scenarios has
received some attention [
D6 Declarative integration: We aim to use declarative means
to describe robotic data and functionality, and wish to achieve
an ecosystem in which providers of data and functionality
interlink without the need for direct coordination. An ideal
system would automatically determine how to combine data
and functionality to ultimately arrive at the stated goal of a
user. However, such a system has proven elusive [
Despite considerable uptake of REST architectural principles
in the Robotics community [
Robotic Things (RT) are digital representations of robotic systems or applications accessible via RESTful interfaces. HTTP requests to access, modify, create or delete Robotic Things are accepted and processed by Robotic Thing servers. Such servers can manage two kinds of Robotic Things, those resources whose state is represented using RDF (cf. Section 5) and those using other formats. In the following, we specify the use of HTTP for accessing, updating, creating and deleting resources from servers that expose Robotic Things. R0.1 A RT server must at least be HTTP/1.1 conformant server. R0.2 A RT server should support secure connections with HTTP over TLS. RT servers that are exposed on the Internet must always implement HTTPS or other security mechanisms in addition or in place of HTTPS.
R0.3 A Robotic Thing must have a URI endpoint for itself and all of its sub-resources.
R0.4 A RT server must support GET on its root resource. R0.5 A RT server must support GET for retrieving resource representations, POST for resource creation, PUT for resource updates or state changes, and DELETE for resource removal. R0.6 A RT server must implement HTTP status codes 200, 400 and 500 providing at least generic indications for successful actions, client-side errors or server-side errors.
R0.7 A RT server should return a HTTP status code 204 for all successful PUT, POST, and DELETE requests.
R0.8 A RT server must use the response Location header field to provide information about the location of a newly created resource for all successful POST requests.
R0.9 A Robotic Thing must advertise associated sub-resources using the HTTP response Link header field, and a link relation type of related (that is, rel="related").
R0.10 A RT server must support OPTIONS for each of its exposed resources and must advertise permitted resource interactions in the response Allow header field.
R0.11 A RT server must use entity tags as response ETag header values for all responses that contain representations and for responses to HEAD requests.
R0.12 A RT server must implement the WebSocket protocol [
R0.14 A RT server must support the request Upgrade header field for subscription creation.
R0.15 A request Upgrade header field value of ‘websocket’ must
result in the creation of a WebSocket-based communication
as specified in [
R0.16 A request Upgrade header field value of ‘callback’ must result in the creation of a HTTP callback, and requires the request Callback header field to specify a callback URI.
R0.17 A RT server should support the Accept header field in subscription creation requests to allow for content-negotiation.
Discussion. Starting with basic requirements (R0.1-R0.3) for reaching 1-RMM, we satisfy the criteria for 2-RMM with (R0.4-R0.7), and employ best practices (R0.8-R0.10) in order to provide hypermedia controls at the protocol level. On the whole, we establish a maturity level of 3-RMM (D1). The semantics of HTTP operations is clarified (R.05), and their admissibility is either specified by default (R0.4) or advertised via the Options Header (R0.10). In conjunction with the definition of expectable HTTP return and error codes (R0.6-R0.7), we provide a simple, yet well-defined interaction model (D2). The ETag header (R0.11) is widely used for cache validation and conditional requests, and can be used for performance improvements of polling algorithms (D3). With the potential for protocol upgrades or event-triggered callback mechanisms (R0.12-R0.17), we strive for communication paradigms more suitable for event-driven and real-time data (D3). The remaining desiderata (D4-D6) can not be fulfilled within the Robotic Thing Model. We therefore extend the notion of Robotic Things in the next section. 2http://www.webhooks.org/ 3http://resthooks.org/ ros: RevoluteJointShape rdf: type sh: NodeShape ; sh: targetClass ros: RevoluteJoint ; sh: property [ sh: path [ sh: alternativePath ( ros: rotation hybrit : property ) ] ; sh: minCount "1"^^ xsd: integer ; sh: maxCount "1"^^ xsd: integer ; sh: class hybrit : Property ; sh: node spatial : AxisAngleShape ; ] ; sh: property [ sh: path [ sh: alternativePath ( ros: jointReferenceFrame hybrit : property ) ] ; sh: minCount "1"^^ xsd: integer ; sh: maxCount "1"^^ xsd: integer ; sh: class hybrit : Property ; sh: node maths : CoordinateSystemShape ; ] ; sh: property [ sh: path ros: preceedingLink ; sh: minCount "1"^^ xsd: integer ; sh: maxCount "1"^^ xsd: integer ; sh: class ros: Link ; ] ; sh: property [ sh: path ros: succeedingLink ; sh: minCount "1"^^ xsd: integer ; sh: maxCount "1"^^ xsd: integer ; sh: class ros: Link ; ] ; <right_s1 > rdf: type hybrit : RoboticThing , ros: RevoluteJoint ; hybrit : blueprint ros: RevoluteJointShape ; hybrit : subscriptions <right_s1 / subscriptions > ; hybrit : action <right_s1 / actions /rotate > ; hybrit : property <right_s1 / friction > , <right_s1 / rotation > , <right_s1 / jointReferenceFrame > ; rdfs : seeAlso <> ; dcterms : title " right_s1 " ; ros: friction <right_s1 / friction > ; ros: jointReferenceFrame <right_s1 / jointReferenceFrame > ; ros: rotation <right_s1 / rotation > ; xhv: prev <right_upper_shoulder > ; xhv: next <right_lower_shoulder > ; ros: preceedingLink <right_upper_shoulder > ; ros: succeedingLink <right_lower_shoulder > .
Linked Robotic Things are Robotics Things, but have the unique quality that at least one of their representations is based on RDF. Furthermore, Linked Robotic Things are often associated with a number of specific sub-resources that a client can use to learn about the Linked Robotic Thing’s topology and interface constraints, to discover and execute available actions, to access and manipulate a set of parameters, or to subscribe for event notifications in order to observe particular state changes.
Any useful interface definition for a Linked Robotic Thing should enable the definition of its RDF graph topology, allow to express structural constraints on its RDF representations, and communicate expected and expectable graph patterns for admissible RESTful interactions. <right_s1 / rotation > rdf: type spatial : AxisAngle , spatial : Rotation3D , hybrit : Property ; rdfs : seeAlso <right_s1 > ; spatial : rotationAngle [ rdf: type maths : Scalar ; vom: numericalValue "0"^^ xsd: float ; vom: unit maths : Radian ] ; spatial : rotationAxis [ rdf: type maths : Vector3D ; maths :x "0"^^ xsd: float ; maths :y "0"^^ xsd: float ; maths :z "1"^^ xsd: float ] .
Unfortunately, the formulation and validation of such interface constraints using RDF(S) or OWL2 is ineligible due to the Open World Assumption adopted by RDF(S) and OWL2, and the lack of a Unique Name Assumption. In fact, neither RDF(S) nor OWL2 provide constraint validation semantics in our sense.
However, RDF shape constraint languages [
We collect a number of such RDF shape expressions using a dereferenceable (sub-) resource of a Linked Robotic Thing, called its Blueprint. Blueprints provide completely machine-processable documentation about a Linked Robotic Thing and its interfaces. For illustrational purposes, we give a simple SHACL-based blueprint of a revolute joint (cf. Figure 2a) that can be used to validate the Linked Robotic Thing instance of Figure 2b.
Linked Robotic Things typically expose a collection of configuration parameters and dynamic variables governing overall behaviour and execution. Such configuration parameters and dynamic variables are essential components of a robotic system, hence, we make them uniquely identifiable and resolvable in form of so-called Properties.
A Property is a dereferenceable (sub-) resource of a Linked Robotic Thing that describes and keeps track of a specific parameter or variable, e.g. a joint’s rotation (cf. Figure 3) or a link’s moment of mass inertia, and enables clients to automatically inspect and potentially manipulate state and behaviour. Properties may detail on the type of the exposed quantity, its time-stamped values, units of measurement, dimensions or data types. Implementers are encouraged to re-use existing vocabularies such as QUDT4, VOM5 or UO6.
Besides plain GET requests on Robotic Things and their potentially time-varying Properties (cf. Section 5.2), a Robotic Thing server allows clients to subscribe to event notifications via the HTTP 4http://qudt.org/ 5http://vocab.arvida.de/2015/06/vom 6http://purl.bioontology.org/ontology/UO @base <http :// example .org/ baxter / right_s1 / subscriptions > . <> protocol upgrade mechanism. New subscriptions are created by issuing a GET request on the respective resource with the request Upgrade header field value set to ‘websocket’ or ‘callback’, and the request Accept header field set for proper content-negotiation. In case of creating a ‘callback’ subscription, the request Callback header field must specify a callback URI.
A Linked Robotic Thing provides minimalistic support for the management of subscriptions via a dereferenceable Subscriptions (sub-) resource. The Subscriptions resource is a Linked Data Platform container and allows to list current subscriptions using a GET request as well as cancelling a subscription using a DELETE request. For each current subscription, the Subscriptions resource must provide a RDF description (cf. Figure 4), e.g. detailing on the subscription type, additional protocol specific information, and the resource being subscribed to.
An Action enables a Linked Robotic Thing to advertise its potential resource state transitions to a client. These advertisements are exposed in dereferenceable Action (sub-) resources that provide the information necessary for a client to select and execute an appropriate Action so that a certain desired goal is achieved. Since we aim to exchange this information in a machine-processable way at runtime instead of being hardcoded into the client at design time, clients can be decoupled from the RT server and adapt to changes more easily.
An Action must efectively describe and constrain the data it may consume for and produce upon a successful invocation. Such specifications may link to a Linked Robotic Thing’s Blueprint (cf. Section 5.1), or directly given using a RDF shape expression (cf. Figure 5a). Regardless of the specific formulation, the client must expect the server to validate the client-provided input against the expressed constraints. The server may reject an invocation if this validation fails. The server may ignore any additional triples not covered by the formulated constraints.
A Binding describes a means that the client can use to execute an Action using a specific communication protocol stack. In the scope of this paper, Bindings are restricted to HTTP requests. The predicate hybrit:binding is used to a link an Action to one or more Bindings. Based on a chosen Binding, a client may employ simple code generation techniques in order to execute the associated Action (cf. Figure 5b).
As a final remark, we point out that Actions can be ofered at any level of abstraction, thus, they can be summarised to higher level Actions. _:body rdf:type http -core:Body . <right_s1 / action /rotate > rdf:type hybrit : Action , hybrit : AsynchronousAction ; hybrit : consumes [ rdf:type sh: NodeShape ; sh: targetNode _:body ; sh: targetClass maths : Scalar ; sh: property [ sh:path vom: numericalValue ; sh: minCount "1"^^ xsd: integer ; sh: maxCount "1"^^ xsd: integer ; sh: datatype xsd: float ; ] ; sh: property [ sh:path vom:unit ; sh: minCount "1"^^ xsd: integer ; sh: maxCount "1"^^ xsd: integer ; sh: minInclusive 0 ; sh: maxExclusive 360 ; sh: hasValue maths : Degree ; ] ; ] ; hybrit : produces <right_s1 / action / rotate / producesshape > ; hybrit : binding [ rdf:type http -core: Request ; http -core:mthd http - methods :PUT ; http -core: requestURI <right_s1 / action /rotate > ; http -core:body _:body ; ] .
The Linked Robotic Thing model is intended as a contract between clients and Linked Robotic Things exposed on the Web, thus, allowing clients to automatically discover and use their properties and action possibilities. In the following, we specify a set of simple rules and conventions for Linked Robotic Things.
R1.1 A Linked Robotic Thing is a Robotic Thing.
the requested Linked Robotic Thing, unless HTTP contentnegotiation requires a diferent outcome.
R1.3 Linked Robotic Things must have at least one rdf:type set explicitly in their RDF representations.
R1.4 In the absence of special knowledge of the application or domain, clients must assume that any RDF representation of a Linked Robotic Thing can have multiple rdf:type triples with diferent objects.
R1.5 RDF representations of Linked Robotic Things should reuse existing vocabularies instead of creating their own duplicate vocabulary terms. Standard vocabularies such as RDF and 7We prefer Turtle syntax for its legibility as default representation. Implementers are free to support more RDF surface syntaxes via HTTP content-negotiation. RDF Schema, Dublin Core or Linked Data Platform, should be used whenever possible.
R1.6 Clients should always assume that diferent Linked Robotic Things of the same type may not all have the same set of predicates in their RDF representations, and the set of predicates that are used in the state of any one Linked Robotic Thing is not limited to any pre-defined set.
R1.7 A RT server must not require clients to implement inferencing in order to recognize the subset of content defined by a Linked Robotic Thing’s RDF representation. Other specifications built on top of this may require clients to implement inferencing.
R1.8 A Linked Robotic Thing must expose a Subscriptions container resource using a RDF triple whose subject is the Linked Robotic Thing’s URI, whose predicate is hybrit:subscriptions and whose object is the URI for the Subscriptions container resource.
R1.9 A Linked Robotic Thing should expose a collection of Property resources using RDF triples whose subject is the Linked Robotic Thing’s URI, whose predicate is hybrit:property and whose objects are the URIs for the Property resources. R1.10 A Linked Robotic Thing should expose a collection of Action resources using RDF triples whose subject is the Linked Robotic Thing’s URI, whose predicate is hybrit:action and whose objects are the URIs for the Action resources.
R1.11 A Linked Robotic Thing may expose a Blueprint resource using an RDF triple whose subject is the Linked Robotic Thing’s URI, whose predicate is hybrit:blueprint and whose object is the URI for the Blueprint resource.
R1.12 A Linked Robotic Thing may provide additional meta data to precisely describe the meaning of individual building blocks of a model in a machine-understandable way.
Discussion. Linked Robotic Things are - by definition (R1.1R1.2) - a semantic extension of Robotic Things (D4). We specify some minimal expectations (R1.3-R1.6) regarding a Linked Robotic Thing’s description (D4), and furthermore provide a light-weight, intuitive conceptual model with standardized link relations (R1.8R1.11). This not only allows to (re-)use vocabularies and ontologies suitable for a more refined semantic descriptions (D4), but also serves as a minimalistic interaction model (D2) ofering hypermedia controls (D1) in addition to (R0.8-R0.10). Using HTTP content-negotiation (R1.2), a Linked Robotic Thing may be available in several diferent representations (R1.1) including binary formats (D5). We explicitly reflect the semantic aspects (R1.8, R0.12R.017) of available event-based and real-time interfaces (D3). Using Blueprints as machine-processable descriptions of Linked Robotics Things (R1.11) and Actions (R1.10) as advertisements of their potential state transitions, we aim for improved system interoperation (D6). 7
for event-driven and real-time communication arise. We intend a more detailed investigation and evaluation of these protocols in the context of the Linked Robotic Things (cf. D3, Section 3). 8https://datatracker.ietf.org/wg/quic/documents/
Robotic applications make heavy use of binary data, but there is surprisingly little work on generic mappings between applicationspecific binary data and RDF. We see possible research contributions on how to lower the barrier between binary data and Linked Data (cf. D5, Section 3).
The primary focus of this paper is on the design of Linked Robotic Thing servers. While we are convinced that our specifications will help to simplify the implementation of clients, we feel that the actual design of such clients, and how they eficiently integrate in a heterogeneous environment of Linked Robotic Things and other Web resources, should receive more attention.
The Linked Robotic Things Model does not make strong assumptions (R0.2) regarding any security or privacy concerns. At this point, we rely on the standard Web security mechanisms, such as HTTPS, and standard Web infrastructure. We thus see future research in how to include security and privacy aspects into the Linked Robotic Things Model. 8
Considering developments in the field of networked robotics, from ifrst tele-operated systems in the 1990’s, to nowadays cloud-based RESTful Robotics applications, we have identified how these RESTful Robotics applications may benefit from Linked Data approaches. Such have already been investigated in the Linked Service community, and have also been considered to be applied to Web Robotics applications. To overcome the lack of clear and concise specifications of how to employ Linked Data concepts in the field of Robotics, in this paper, we have made the following contributions:
We have proposed a number of desiderata for robotic systems in Linked Data Environments and have proposed a multi-layer model to address these: A protocol layer to ensure basic communication, and a (machine-readable) semantic layer that provides additional information about the resource. To ensure the basic communication on the protocol layer, we proposed a definition of a Robotic Thing. Building on that, we have defined a set of requirements on the semantic level to create a common understanding, how server and clients interact with each other and how we can explore the world model of a Linked Robot Thing in an eficient and simple way. Thus, the implementation and communication between systems using this model are much more robust, simpler and testable.
We have discussed the requirements on both levels, compared them to the previously stated desiderata, and shown that all desiderata can be fulfilled by the given requirements. We thus present an exhaustive, concise, well-defined specification for Linked Robotic Things as building blocks for Linked Robotic applications on the World Wide Web.
This work is supported by the Federal Ministry of Education and Research of Germany in the project Hybr-iT (Förderkennzeichen 01IS16026A).