Review Comment:
This paper describes the Open 311 ontology that has been developed by the authors to represent data about 311 calls for various cities in North America. As such, the paper is evaluated according to the set of criteria that are proposed in the journal for ontology papers (http://www.semantic-web-journal.net/reviewers#types).
First of all, it should be pointed out that the paper may not be actually categorized as a short paper, as requested for this type of papers. It is 15 pages long and probably some of the details that are provided in the description may be summarized a bit to reduce the size of the paper and make the descriptions more brief and pointed, as requested in the aforementioned evaluation criteria.
The design principles behind the development of the ontology are described, although I must admit that I see the number of competency questions a bit too small to introduce all the types of needs and requirements that the ontology developers were considering in the development process. The methodological process is clear, and follows a well known method for ontology development, which has been used for the development of some influential ontologies, and which relies on the use of competency questions for capturing requirements and evaluating the resulting ontology later. The analysis done for existing datasets is adequate, although probably a bit too biased to North American cases, while 311-like data are also available in cities from other geographical areas and which have some important differences (for instance, in the organisation of cities into neighborhoods, or in the organisation of city councils). In any case, the use cases that are provided also make sense according to what 311 data can be used for, and I have myself experienced with other cities using this type of data the need to address similar types of problems.
The ontology is freely available on the Web (although the URI that has been applied is not following the most recent common practices in the publication of ontologies on the Web (e.g., not using the suffix .owl after the general URI of the ontology). However, there are no real cases identified where data has been actually transformed and are published (as Linked Data or in a SPARQL endpoint) according to this ontology. Only a few examples are provided, which are nice to understand how data from several cities can be transformed according to the ontology, but it would be nice to have these complete datasets available and provide links to the datasets.
The competency questions are also transformed into SPARQL, as a good practice.
Moving into the analysis of ontology quality, I have several concerns that may need to be addressed:
- One of the first concerns is related to the problem of interoperability between data from different sites. This concern is really important in terms of the types of services and requests that are modeled in the ontology. The authors propose one classification, but every data source that they have analysed has different sets of categories, as the authors have acknowledged. However, they are not clear about how these disparate sets of services provided as strings are mapped to this classification, and why they think that the classification is rich enough.
- From the competency questions it is not clear why the types of services and requests need to be encoded as OWL taxonomies, instead of using, for instance, SKOS concept schemes, which may fit better into a context as open as these sets of services.
- There are many elements in the original data sources that may be converted into URIs, such as for instance the divisions, section units, etc. It is not clear how they could be converted into URIs, making the datasets more linked to other potential datasets from the cities.
- On the related ontologies, some of the design decisions are not clearly expressed. The authors just say that they reuse ontology X, ontology Y, but they do not specify why. For instance, why aren’t they using the W3C Organisation ontology for the description of organizations? This ontology is inspired by the one that is used here, and they are both compatible. The same applies to the iContact ontology, whereas other ontologies may have been used, such as schema.org properties or vCard. And for transportation, Linked GTFS (and schema.org) is already providing some concepts that may be used.
- It is not clearly described either why the cardinality of has311Type is one for ServiceRequest. Isn’t it really possible to have several types? Or several handling agencies?
- All properties may also use camelCase notation, although this is a minor comment, obviously.
On the readability side of the paper, we have the following aspects that may need to be considered:
- It may be good to explain briefly in the abstract what 311 is about, since readers from different cultural backgrounds may not understand what the 311 service is.
- In general, there are many typos and grammar errors throughout the paper.
- In the references to open data sites from North-American cities, the links only provide links to the open data sites, but not to the specific datasets where 311 data is provided.
|