VSSo: a Vehicle Signal and Attribute Ontology for the Web of Things

Tracking #: 2085-3298

Authors: 
Benjamin Klotz
Raphael Troncy
Daniel Wilms
Christian Bonnet

Responsible editor: 
Guest Editors Sensors Observations 2018

Submission type: 
Full Paper
Abstract: 
Application developers in the automotive domain have to deal with thousands of different signals and attributes, represented in highly heterogeneous formats, and coming from various car architectures. This situation limits the development of modern applications. We hypothesize that a formal model of car signals, in which the definition of signals are uncorrelated with the physical implementations producing them, as well as a common data layer, would improve interoperability between connected cars and their ecosystem. In this paper, we propose VSSo, a vehicle signal and attribute ontology that builds on the automotive standard VSS, and that follows the SSN/SOSA design pattern for representing observations and actuations. We also describe a more general driving context ontology supporting the description of events. VSSo is comprehensive while being extensible for OEMs, so that they can use additional private signals in an interoperable way. We developed a simulator for interacting with data modeled using VSSo is available at http://automotive.eurecom.fr/simulator/query.
Full PDF Version: 
Tags: 
Reviewed

Decision/Status: 
Major Revision

Solicited Reviews:
Click to Expand/Collapse
Review #1
By Alessandro Oltramari submitted on 07/Feb/2019
Suggestion:
Minor Revision
Review Comment:

This paper describes a formal model of car signals that uses SSN/SOSA as reference ontology. As the authors point out, such a model is required to overcome the present landscape, where different car architectures used different data models, hindering interoperability and reusability.
The paper is technically sound, very well written and organized. My recommendation is acceptance with minor revisions, as follows.

p.1., line 37: "effort to do" --> "effort to make"
p.3, line 2: footnote to be moved from main text

p, 5., line 47-48: signals are either produced by sensors, or consumed by actuators. Although from a linguistic standpoint, elliptical sentences don't constitute a problem, from an ontological perspective, omitting sensors and actuators may wrongly convey an interpretation according to which observability and actuatability are inherent properties of signals, and not necessarily dependent on the existence of, respectively, sensors and actuators.

p.12, section 3.4.2.: the need for an ontology of the driving context is well explained in section 3.4.1, but section 3.4.2 doesn't really provide much details about the main distinctions assumed by the "driving context ontology". For instance, :WeatherState is aligned to wo:WeatherState in the Weather Ontology and seas:WeatherForecast ontology: but if, as the authors point out, these ontologies have different approaches to describe a weather state, how doest this alignment concretely work? A sound "driving context ontology" should not only include the basic primitives that represent the driving domain, but clearly defines the inter-categorial semantic relations that bind those primitives together. Such inter-categorial semantic relations would be much needed to capture complex situations, e.g. when a snow storm affects the road conditions, affecting a driver's state of anxiety and stress. Given that section 3.4.2 doesn't play a major role in the paper, I'd suggest the authors to introduce a diagram to better visualize the inter-dependencies in the "driving context ontology", and conclude the section by acknowledging/addressing the issue raised here.

p.13, section 5.1: reference to Section number is missing (replace "??")
p.14, section 5.2: reference to Section number is missing (replace "??")

p.15: I don't see much value in having qualitative assessments in table 2 (e.g., "High", "Limited"), and point to the number of attributes or numbers of signals in the main text. I'd strongly suggest to incorporate numeric coverages in the table.

p.16: lines 21-27: how did you empirically evaluate that non-experts understood the information parsed from the car? Without a more extensive description of the experimental settings, methods, and results, it's hard to justify the claim that your hypothesis that non-experts can interact with cars in the WoT was "empirically validated"

Review #2
By Antoine Zimmermann submitted on 12/Mar/2019
Suggestion:
Major Revision
Review Comment:

[This manuscript was submitted as 'full paper' and should be reviewed along the usual dimensions for research contributions which include (1) originality, (2) significance of the results, and (3) quality of writing.]

Summary:
The paper describes the Vehicle Signal Specification ontology (VSSo) which can describe information from all kinds of sensing and acting devices in automobile vehicles, as well as the data that they produce, and how they can be interacted with, in a WoT-like fashion.

I think that the paper is much closer to what we expect from an ontology description paper, than a "full paper". As such I propose that the paper be revised to better fit such kind of paper, and I reproduce here the guidelines for "Descriptions of ontologies" found on the Semantic Web Journal website:

"""
Descriptions of ontologies – short papers describing ontology modeling and creation efforts. The descriptions should be brief and pointed, indicating the design principles, methodologies applied at creation, comparison with other ontologies on the same topic, and pointers to existing applications or use-case experiments. It is strongly encouraged, that the described ontologies are free, open, and accessible on the Web. If this is not possible, then the ontologies have to be made available to the reviewers. For commercial ontologies, exceptions can be arranged through the editors. These submissions will be reviewed along the following dimensions: (1) Quality and relevance of the described ontology (convincing evidence must be provided). (2) Illustration, clarity and readability of the describing paper, which shall convey to the reader the key aspects of the described ontology.
"""

In my opinion, the paper is rather convincing in terms of relevance and quality (with a few minor suggestions detailed below) and illustrate well and clearly the key aspects of the ontology. However, it is not a short paper and is presented as a "full paper" contribution. In that regard, it fails to prove the significance of its results as the evaluation is rather weak and the so-called "research questions" are pretty close to engineering questions instead.

Regarding research questions:
- "How to design an ontology describing vehicle data?" -> this is not what the paper is answering. The paper describes how VSSo was designed, explains the design choices, but in no way tell the reader how *any* vehicle ontology should be designed. This looks like a situation where some authors have built a car, and report on how they did it, what choices they made and why, and then pretend that there was a research question "How to design a car?" in an article submitted to a scientific journal. I think that the paper presents one way of designing such an ontology, as well as *some* general principles.
- Idem for the second research question. Regardless, assuming it is effectively the goal of the paper to answer such questions, the evaluation is not convincing me that the contribution properly address them.

Regarding the evaluation:
- One part of the evaluation is based on competency questions. Most of these questions are rather trivial, and the queries that give answers to them are simple too. Some queries are flawed (see below). To show the expressiveness of the model, the evaluation should insist on the more difficult queries, possibly really hard ones. Some ideas are "What was the average speed of the vehicle for the past hour, considering that I have several speed sensors?" "What sensors give me pressure data and how can I query them?" "How do I close/open each of the windows in function of the inside and outside temperature?" etc.
- Sec.5.2 looks like a second state of the art section, with the addition of comparison to the proposed approach. This seems redundent with Sec.2
- The application scenarios are good for an ontology description papers, but do not suffice to give a convincing evaluation for a full paper

My advice is to shorten the paper, taking into account the guidelines for ontology papers, cover related work a bit more concisely, reduce the evaluation part, and address the minor comments below.

Minor comment:
General: Footnote markers should be place after punctuation, like so: "and safety-enhancing systems.\footnote{ .... }"
There is an awful lot of footnotes with hyperlinks. While some of them are very welcome, there are also some that are anecdotical and contain links to web pages that will most certainly dissappear in the future. Some of the notes could be replaced by bibliographic references.
The prefixes used in Turtle code are not defined. While it's fine to use rdf:, rdfs:, owl:, or xsd:, since they come from the standards, other prefixes should be given once explicitly

Sec.1:
- footnote 2 could be a bibliographic reference
- "Advance Driver Assistance Systems" -> Advanced
- "The 2000s have seen developed" -> strange formulation, put in active voice "ACC, LD and new sensors were developed in the 2000s"
- "OEM hire" -> "OEMs hire" or "OEM hires"
- "a requirement: a vehicle data model should be ... and follow best modeling practices" -> these are 2 requirements
- "cross-industries applications" -> cross-industry applications
- "using semantic web technologies 2" -> there must be a missing "Section"

Sec.2:
- 2.1.1 "that enable to access to" -> that enable access to
- "a wide range of Web Servicesfootnotehttps://ifttt.com/bmwlabs" -> missing curly brackets
- 2.1.2 "that enable to access to"
- "among others" -> other what?
- 2.2.1: "a set of vehicle signal data stream and static database" -> streams ... databases
- "How old is this car?." "... does this car contain?." "What is the curent gear?." "... on the driver side?." -> double punctuation
- Sec.2.3: "with connect things" -> with connected things
- 2.3.1 "The are applciations built using them ..." -> citation needed
- 2.3.2: "In addition to that wot:Property instances" -> ...to that, \texttt{wot{:}Property}...

Sec.3:
- Sec.3.2: "vsso:AmbientAirTemperature is a signal" -> it seems strange that a temperature is a signal... surely, temperature can be used and interpreted as a signal for something (like "a high temperature in a human body is a signal for a disease or infection") but to say that that air temperature itself is a signal is a bit of a stretch. Anyway, whether it is a signal or not can depend on the definition of signal used by the authors, which is never given, neither in the paper, nor in the ontology document, nor in the ontology specification online
- footnotes 39 and 40 are references to 2 versions of the same ontology. Why provide 2 versions?
- 3.3.2: it is strange to say that sosa:ObservableProperty and sosa:ActuatableProperty are readable or writable. How is the brightness of the Sun "readable"? How is the position of the cup of tea on my desk "writable"?
- 3.4.1 "are of interests" -> interest
- "modelling" -> "modeling" (the rest of the paper uses American spelling)
- "interact one with another" -> "interact with one another"
- "participants - mostly cars and people - as well" -> replace dashes with ndashes ("--" in LaTeX)
- "behavioral States" -> "states"? why capital letter?
- 3.4.2 "passenger State" -> state?

Sec.4:
- Sec.4.1 "serialised" -> "serialized"
- prefix vss: is used, while vsso: was used before
- "all vss:ObservableSignal instances are not writable" -> don't you mean "not all instances of vsso:ObservableSignal are writable" (or equivalent "some instances of vsso:ObservableSignal are not writable"). In Sec.3.3.2, it is said that some signals are both readable (observable) and actuatable (writable).
- Listing 4 defines the prefix vsso: that it does not use, and use vss: that it does not define

Sec.5:
- Sec.5.: "Section ??"
- It seems Table 1 and Table 2 are not referenced in the text (in fact, Table 1 is reference, but much later in the text, move it to Sec.6). What are they showing?
- "FILTER(?time = NOW())" seems to be a strange way to get the latest value for a signal. Only in extremely rare circumstances, the observation will occur exactly at the time of querying. Something like "ORDER BY DESC(?time) LIMIT 1" would be better
- footnote 54: "we assume we can define the current time with a function NOW()" -> delete. There is no need to assume anything, NOW() is part of the SPARQL standard
- Sec.5.2: "(Section ??)"
- "Only the Web of Things model is independent from [the automotive domain]" -> SSN is also independent from it
- "of a vehicles" -> vehicle
- "hence a tenth of attributes" -> ???
- In Table 2, there are missing spaces before the bibliographic references, e.g., "its sources[24]"
- "OBD-II and the Extended Vehicle, despite of some reported usage, focus on diagnosis" -> I don't understand why the focus on diagnosis is *in spite of* reported usage??
- "with a possibility to developers" -> for developers
- "a single car was parsed" -> how do you "parse" a car??
- "From those experience, we get the empirical validation of our hypothesis" -> ??? you need to show the results, the protocol, the number of participants, etc.

Sec.6:
- Sec.6.1: "A public sparql" -> SPARQL
- "a interfacing server" -> an

Sec.7:
- "we will work to make it more complete" -> why? what's missing?
- "and consistent" -> what's inconsistent?

References:
- [5] "internet of things" -> Internet of Things
- reference [7] is used in Sec.1 as a ref to the VSS standard. That's not the right ref
- [8,9,12,13] -> in place of the authors, there is the name of a company or standard number.
- [11] -> where is it published?
- [24] -> "Schema. org" -> delete extra space
- [26] is not under review anymore
- [28] -> when and where was it published?
- [34] is not a PhD thesis
- [35,37] -> where published?
- [39] -> remove dot after title.

Other comments:
vsso: namespace used, but the .ttl file on github has {vss: vann:preferredNamespacePrefix "vss"}
3.4.1 "WGS84 Geo Positioning Ontology" -> in the data at eurecom simulator/data, it's geosparl:lat (which does not exist in the geosparql vocabulary)
Listing 6: "48.151099"^^xsd:long !!
In the data:
* the literals with type xsd:dateTime are ill-typed: "2019-03-08 08:25:17"^^xsd:dateTime should be "2019-03-08T08:25:17"^^xsd:dateTime
* the geo prefix is for the geosparql vocabulary, which does not contain geo:lat / geo:long
* the literals with types cdt:* are ill-typed: there must be at least one space between the numerical value and the unit

Review #3
By Jose María Alvarez-Rodríguez submitted on 26/Mar/2019
Suggestion:
Major Revision
Review Comment:

Authors present in this paper the definition of an ontology for the management of vehicle signals and attributes. They have explored the need of data interoperability in the context of car engineering and manufacturing and, more specifically, the need of controlling multiple sensors and actuators with different data formats, protocols, etc. that usually make difficult the integration of data and the development process. They aim at creating a data layer on top of that that can ease the management of different data sources providing an integrated view for developers. To do so, they follow a typical semantic-web, Linked Data approach defining a model of such data and creating a data service layer on top of all elements available in a car. This ontology is defined with Description Logics and provide a SPARQL endpoint as query mechanism for instances. Finally, they present some applications.

The introduction is well motivated making emphasis in the integration of data generated during both the engineering process and the operation of a complex system like a car. This is especially relevant for OEM that must deal with multiple technology (sw, hw) providers to cover the different views of the system (electronics, telecommunications, mechanics, etc.). They also define two research questions regarding the possibility of creating an ontology to address the challenge of integrating information and being able to interact with car components following a Web of Things approach. They claim that this approach will improve the efficiency in the development process.

Next section presents the state of the art. To do so, authors review the main architectures and APIs to access and manage car data. They mainly focus on existing automotive standards and data models currently available. The review is extensive covering multiple works.
However, existing works are not sufficiently evaluated in terms of some criteria. Authors are dealing with a problem of interoperability in both the engineering process and the operation of a complex system so it is necessary to establish a set of criteria that allows readers to understand which are the current problems in terms of interoperability (data, information, knowledge) or technical, syntax, semantic, process, etc. A conceptual framework to evaluate the interoperability is required to assess existing works and to, later, evaluate the current proposal. Furthermore, there is no reference to other types of models or approaches used in the systems engineering area such as SysML, OSLC, STEP, etc. that also serve as approaches to manage interoperability in the engineering process. References and evaluation of software product lines should also be included since they are a method to metamodel a complex system and to enable interoperability in the engineering process. It is necessary to describe the works in terms of a conceptual framework and to make the evaluation making a difference between engineering and operation of the system.
Moreover, there is a lack of alignment between processes such as those in ISO 15288, 26262 and the needs of interoperability to improve the engineering methods.

Afterwards, authors introduce the design of an ontology to model car. This ontology may cover the static (logical or descriptive) view and the dynamic (behavioral or analytical) view of the system. However, it is not clear why they have selected Description Logics. It is necessary to justify why a logics-based model is better than a SysML model (to infer new data, to check consistency, etc.). Furthermore, it is necessary to include which has been the process to model the ontology classes and properties (what is the knowledge source) and to what extent the ontology is complete. In general, it is necessary to motive the use of a formal ontology and how it is going to be integrated with other system artefacts generated during the development lifecycle.

Regarding the evaluation of the ontology, the creation of an ontology does not mean interoperability. It is necessary to define or use an existing conceptual framework for interoperability to evaluate the current situation and then, evaluate the gain of the proposed approach. E.g. Current status: technical interoperability Target: semantic interoperability and justify both conceptual (Why formal ontologies?) and technical decisions (Why Description logics?).

In the contest of applications, authors provide some examples and use cases in which a data interoperability layer makes sense. However, it will be necessary to document better a complete case study making an initial evaluation of the previous state and the new state. Which is the added value of having an ontology? Which is the added value of having a Sparql interface (if any in all examples)? Why not a simple JSON API? (like those defined with Swagger). Does your application really improve the development efficiency? How can you measure that? In general, developers are not usually convinced of using new data formats, query protocols, etc. so you must set an evaluation framework to be able to answer your research question about the efficiency in the development process in both levels: conceptual and technical.

Finally, authors present some interesting conclusions and outline future work to improve the ontology.

Other comments:
-Title is adequate.
-Abstract is adequate, although some acronyms are not easy to follow in the first reading.
-References are adequate and u to date. However, in the context of complex systems, there are many things to comments in terms of interoperability. Some successful case studies (such as those in NASA are not commented). Furthermore, the paper contains a lot of footnotes that may be moved to the references section.
-Figures and listing are correct. Perhaps listings should be framed (depending on the journal style)
-The paper is well written and structured. No typos have been found.