SEMANTIC HYPERCAT MICHALIS GEORGIOU A thesis submitted to the University of Huddersfield in partial fulfilment of the requirements for the degree of Master of Science by Research September 2018 AbstractThe rapidly increasing number of sensor networks and smart devices contributed to the generation of a huge amount of information

SEMANTIC HYPERCAT
MICHALIS GEORGIOU
A thesis submitted to the University of Huddersfield in partial fulfilment of the requirements for the degree of Master of Science by Research
September 2018

AbstractThe rapidly increasing number of sensor networks and smart devices contributed to the generation of a huge amount of information. Information that is generated by various sources and is published in different formats highlights interoperability as one of the key prerequisites for the success of the Internet of Things (IoT). Hypercat is a specification defining a lightweight JSON-based hypermedia catalogue, designed to serve the needs of the industry. In this thesis, I extend the existing work on semantic enrichment of Hypercat by defining a JSON-LD based catalogue. The proposed JSON-LD specification provides a mapping mechanism between JSON and JSON-LD catalogues, while highlighting the fact that JSON-LD could be seamlessly adopted by the Hypercat community.

We Will Write a Custom Essay Specifically
For You For Only $13.90/page!


order now

We Will Write a Custom Essay Specifically
For You For Only $13.90/page!


order now

AcknowledgementsFirst of all, I would like to thank my supervisor Professor Grigoris Antoniou of the School of Computing and Engineering at the University of Huddersfield. His office was always open for me when I needed him or had a question regarding my research or writing. Professor Antoniou was always happy to discuss with me anything about my master or my daily life outside the University.
Furthermore, I would like to express my gratitude to my co-supervisor Dr. Ilias Tachmazidis for introducing me to the topic from the beginning of my master and helping me every time I run into trouble with the programming part of my master. Without his help this master, and thesis would not have been possible.

I would also like to thank both of my above supervisors who gave me the opportunity to write with them a research paper for the MIWAI Conference 2018.
In the end, I want to thank my parents, my grandparents and my girlfriend for providing me with constant support and encouragement throughout this year and all of my years of study.
Thank you.

Author
Michalis Georgiou
Table of Contents
TOC o “1-3” h z u Abstract PAGEREF _Toc523917452 h 1Acknowledgements PAGEREF _Toc523917453 h 2Chapter 1 PAGEREF _Toc523917454 h 4Introduction PAGEREF _Toc523917455 h 4Research Contribution PAGEREF _Toc523917456 h 5Thesis Structure PAGEREF _Toc523917457 h 5Chapter 2 PAGEREF _Toc523917458 h 7Background PAGEREF _Toc523917459 h 7Semantic Web PAGEREF _Toc523917460 h 7HVD & BT hubs PAGEREF _Toc523917461 h 8Hypercat 3.00 Specification PAGEREF _Toc523917462 h 9Hypercat Ontology PAGEREF _Toc523917463 h 10BT Hypercat Ontology PAGEREF _Toc523917464 h 12JSON-LD – JSON for Linking Data PAGEREF _Toc523917465 h 13Chapter 3 PAGEREF _Toc523917466 h 15Hypercat JSON to Hypercat JSON-LD PAGEREF _Toc523917467 h 15Hypercat BT JSON-based to JSON-LD based PAGEREF _Toc523917468 h 19Example from JSON to JSON-LD based catalogue PAGEREF _Toc523917469 h 26Hypercat JSON-based to JSON-LD based catalogue parser PAGEREF _Toc523917470 h 33Chapter 4 PAGEREF _Toc523917471 h 36Hypercat JSON-LD Specification PAGEREF _Toc523917472 h 36Chapter 5 PAGEREF _Toc523917473 h 41Semantic Search PAGEREF _Toc523917474 h 41Chapter 6 PAGEREF _Toc523917475 h 44Conclusion PAGEREF _Toc523917476 h 44References PAGEREF _Toc523917477 h 45
List of Figures
TOC h z c “Figure” Figure 1: The Hypercat Ontology PAGEREF _Toc523875844 h 11Figure 2: The BT Hypercat Ontology PAGEREF _Toc523875845 h 12Figure 3: A Linked Data graph PAGEREF _Toc523875846 h 14Figure 4: Semantic Search Implementation’s Design PAGEREF _Toc523875847 h 43
List of Tables
TOC h z c “Table” Table 1: Hypercat Core properties mapped to existing JSON properties PAGEREF _Toc518650902 h 11Chapter 1IntroductionIn 2014, eight industry-led projects were funded by Innovate UK (the UK’s innovation agency) as part of the Internet of Things Ecosystem Demonstrator programme in order to deliver IoT `clusters’, where each cluster is based on a data hub that aggregates and exposes data feeds from multiple sensor types. Addressing interoperability was a major objective of the programme leading to Hypercat, a standard for representing and exposing Internet of Things data hub catalogues over web technologies, to improve data discoverability and interoperability (Davies ; Fisher, 2015). Hypercat facilitates the combined usage of distributed data repositories (hubs), thus allowing applications to query hubs’ catalogues in a uniform machine-readable format in order to identify and access the needed data. According to the specification of Hypercat, interoperability is based on the same principles on which linked data and the web are built. Such principles include data accessibility through standard web protocols and formats (HTTPS, JSON, REST), the identification of resources through URIs, and the establishment of common, shared semantics for the descriptors of datasets. From this kind of view, Hypercat can be a practical beginning to solve the issues of managing multiple data sources, aggregated inside numerous data hubs, through linked-data and web approaches. Hypercat incorporates a lightweight, JSON-based approach based on a technology stack used by a large population of web developers. A Hypercat catalogue lists and annotates any number of URIs that typically identify data sources, having a set of relation-value pairs (metadata) associated with it. Thus, a given server has the ability to advertise a set of semantically annotated resources, while there is only a small set of core mandatory metadata relations that a Hypercat catalogue must include, thus providing developers with the freedom to define any set of annotations suits their needs (Beart, 2016). There is also a Hypercat community with open source tools available in Github with the link “https://hypercatiot.github.io/”. Dealing with the complexity and diversity of IoT data sets highlighted linked data and Semantic Web technologies as prominent solutions (Antoniou & Harmelen, 2008). Linked data enable the integration of data into a common, browsable and accessible knowledge graph while leaving data distributed and managed in different systems, under the control of different contributors. The effective use of linked data technologies in many different cases and collect information from different sources to put them together in a general way, it can enable a diversity of applications, with no need of encoding the constraints of the applications in the data model. Semantic Web technologies add to this the ability to apply meaningful data models (ontologies) both to improve interoperability between systems and to enable improved data analysis (Lecue et al, 2014). Therefore, it is very normal to start thinking and start studying how the Hypercat standard and its specification could be serialised in a semantic language/form and to examine the advantages that could happen from such a materialization, this is the aim of this research to develop a semantically-enriched Hypercat system. One can envisage a more expressive catalogue where data policies, as well as the data flows that relate to them (d’Aquin et al, 2014) are represented as machine readable information. It is therefore natural to consider how the Hypercat specification could be serialised in a semantic language such as JSON-LD. Why JSON-LD? Simply because JSON-LD is very friendly to the developer and has familiar outfit of JSON syntax. There is also a previous work of a semantically enriched Hypercat catalogue which is developed in RDF, but the Hypercat RDF-based catalogue has not been adopted because is making transition to whole different format. According to (Sporny,2014) one of the primary JSON-LD creators, in his blog, he discusses that JSON-LD it is based on a technology that most developers use today. In addition, the current JSON-based Hypercat developers can embrace the change easily and translate their current JSON-based Hypercat catalogues to JSON-LD based catalogues. Thus, with the new Hypercat JSON-LD based catalogue, the Semantic Search can be proposed. This type of search allows SPARQL-like queries on semantic Hypercat catalogues that capture the semantic hierarchy of classes and properties. In this research thesis, I propose a semantic enrichment of the Hypercat specification that increases interoperability by defining a JSON-LD based catalogue. Catalogue information is published based on an ontology providing a mapping mechanism between existing JSON and proposed JSON-LD properties. A systematic translation of an existing Hypercat JSON catalogue into a Hypercat JSON-LD catalogue is presented. In addition, various aspects of the proposed Hypercat JSON-LD specification are studied in comparison to the existing Hypercat JSON specification.

Research ContributionThe aim of this research is to develop a semantically-enriched Hypercat system, and the objectives are to:
Establish familiarity with the Hypercat standard (JSON and RDF).

Establish familiarity with the JSON-LD.

Develop a JSON-LD equivalent for the Hypercat specification.

Develop a parser translating Hypercat JSON-based catalogue to Hypercat JSON-LD based catalogue.

Design and propose a Semantic Search mechanism.

Thesis StructureThe rest of the thesis is organized as follows. Chapter 2 delivers background on Semantic Web technologies, an explanation of BT Hub, it also provides the current Hypercat 3.00 specification, descriptions of the Hypercat Ontology and BT Hypercat ontology and in the end, it introduces the JSON-LD. Chapter 3 describes the translation of a JSON-based catalogue to JSON-LD based catalogue, as long with an example of the translation of BT Hypercat JSON-based catalogue with each properties and aspects to a JSON-LD catalogue and a description of the Hypercat JSON-based to Hypercat JSON-LD based catalogue parser. There is also a small sample of how a BT Hypercat JSON based catalogue can be translated into a BT Hypercat JSON-LD based catalogue. At the end of Chapter 3 it can be seen a description of how the parser from a BT Hypercat JSON to BT Hypercat JSON-LD is working. Chapter 4 presents the Hypercat JSON-LD specification, while Chapter 5 describes the Semantic Search. The conclusion is in Chapter 6 following by the references.

Chapter 2BackgroundSemantic WebThe Semantic Web evolved out of the Web with the aim to represent Web content in a form that is machine understandable and processable (Antoniou ; Harmelen, 2008). Today, Web content, in HTML format, retrieved using search engines is typically suitable for human consumption, while content that is generated automatically from databases is usually presented without the original structural information of a given database. Machines encounter problems understand data which is in format where humans can understand it, such as HTML. The semantic web challenges the problem from the Web page side by replacing the HTML format to a more structured and machine understandable language. Thus, the key idea is to use machine-processable Web information (Antoniou ; Harmelen, 2008).

Formats such as JSON are used for data exchange in a structured way, enabling machines to parse and generate data (JSON, N/A). However, even these formats do not address the following problem: the meaning of Web content is not machine-accessible. Machine-readable semantics of concepts of an application domain can be defined using Semantic Web standards. Specifically, an ontology is an explicit and formal specification of a conceptualization and describes formally a domain discourse. An ontology consists of definitions of concepts (classes of objects) of the domain and relationships between these concepts (e.g., class hierarchies), and can be defined using the Web Ontology Language OWL (Antoniou ; Harmelen, 2004). OWL is a W3C standard and the current version is OWL 2 (W3C, 2012).
Ontologies can also deliver a shared understanding of the domain but with such a shared understanding is essential to differ in the terminology. For example, in one application’s zip code might be the same as another application’s area code. The next problem is when two applications might use the same term but with different meanings. This kind of problems can be solved by mapping the specific terminology to a common ontology or by defining straight mappings among the ontologies. Nevertheless, ontologies can support semantic interoperability(Antoniou ; Harmelen, 2008). Ontologies can be used for the organization and the navigation of Web sites. Most of the Web sites exposed to the page’s top levels of a concept hierarchy of terms, and the user can use them to expand the subclasses. In addition, ontologies are usable for meliorating the precision of Web Searchers. The search engines can find pages that mention the specific concept in an ontology rather than gathering all pages that are not certain and where the keywords occur (Antoniou & Harmelen, 2008).
Facts about application domain objects and their relations can be asserted in JSON-LD website. Moreover, Web resources represented in OWL could allow for automatically interfering implied facts about these resources. Automatic inference and retrieval is very important when data is voluminous and changes fast (e.g., streaming data), which is a typical case in the Internet of Things (IoT) scenarios (Gubbi et al, 2013).

HVD & BT hubsBT Hypercat Data Hub is a platform which enables information from a large range of sources and presents them to the users or developers in a reliable way. The data hub’s portal delivers an interface to the user who can use the specific data, where they can browse a data catalogue and then choose or subscribe to the data feeds they need. Additionally, a JSON-based Hypercat machine readable catalogue is also offered, there is also a propose of a Hypercat RDF-based catalogue by Tachmazidis et al, 2016. An API authorizes admission to data feeds, secured by API keys, whilst a relational, GIS capable, database allows complicated queries that data can be filtered based on a huge number of criteria. A range of last technology adapters allows the information to insert into the data hub and to be converted to a standard format for usage inside the platform’s core. The data hub offers a steady method to integration among data exposed by sensors, systems, and people through communication networks and the applications that can use this information to advance decision making, such as, in control systems. The set of adapters which are included in the hub are for ingress (input) and egress (output). These adapters are used for specified data source or application feed and may be carried out in different cases. There is also a need to decode data among arbitrary external formats and the data formats internally. The cause of Hypercat is to represent and expose Internet of Things data hub catalogues through web technologies and improve the data interoperability and discoverability. Of course, the main reason is to allow distributed data repositories (data hubs) to be used combined by several applications and make possible to query their catalogues in a uniform of machine-understandable format. This can make knowledge graph around the available datasets across numerous hubs that applications can be used and query to find and access the wanted data, whatever the data hub in which they are held. Considering this, Hypercat can be a starting point to solve the problems of managing numerous data sources, in a total of numerous data hubs, thru linked data and semantic web methods (Tachmazidis et al, 2017).

Hypercat 3.00 SpecificationIn this subsection, it can be found the basic notions of the Hypercat 3.00. Hypercat is a lightweight JSON-based hypermedia catalogue format for exposing collections of URIs, with each URI having any number of RDF-like triple statements about it. By definition, a Hypercat catalogue is a file representing an unordered collection of resources on the web, with each item in the catalogue referring to a single resource by its URI. Thus, a Hypercat catalogue may expose a collection of resources, such as data feeds, and provide links to external Hypercat catalogues.

Although the definition of a catalogue within a catalogue is not allowed, catalogues may be linked by referring to other catalogue URIs. In addition, a given catalogue may provide metadata about itself and each catalogue item. The structure of a Hypercat catalogue is defined based on a Catalogue Object, which is a JSON object.

A given Catalogue Object must contain the following properties: (a) items, which is a list of items (JSON array of zero or more Item Objects), and (b) catalogue-metadata, which is an array of Metadata Objects describing the catalogue object (JSON array of Metadata Objects).

An Item Object (from the items array) is a JSON object, which contains the following properties: (a) href, which is an identifier for the resource item (URI as a JSON string), and (b) item-metadata, which is an array of Metadata Objects describing the resource item (JSON array of Metadata Objects). Both catalogue-metadata and item-metadata arrays must contain as a minimum one metadata object for each of the compulsory Metadata Object relationships. The catalogue-metadata and item-metadata arrays may contain numerous metadata objects with the similar rel (and val) properties (they are bags/multisets of features).
A Metadata Object is a JSON object, which describes a single relationship between the parent object (either the catalogue or catalogue item) and some other entity or concept denoted by a URI, such a relationship is applicable to both the catalogue itself and each catalogue item. A Metadata Object contains the following properties: (a) rel, which is a relationship between the parent object and a target noun, expressed as a predicate (URI of a relationship as a JSON string), and (b) val, the entity (noun) to which the rel property applies (JSON string, optionally the URI of a concept or entity). There are also two mandatory metadata relationships which must be included in every catalogue such as: (a) rel urn:X-hypercat:rels:hasDescription:en meaning that the resource has human readable description in English (JSON string), and (b) rel, urn:X-hypercat:rels:isContentType which means that the data which is provided by resource is of the given MIME type (the val of this relationship: application/vnd.hypercat.catalogue+json). The (b) relationship must be included in every top-level of the catalogue-metadata objects (describing the catalogue object). The structure that is described above constitutes the basic core of any given Hypercat catalogue. However, the Hypercat 3.00 specification defines a far more detailed model compared to the above description. Thus, in the next chapters of this thesis, there is a definition of each aspect of the Hypercat 3.00 specification while providing the corresponding semantically enriched solution based on an OWL ontology, which is asserted in RDF format.

Hypercat OntologyIn this subsection, there is a description of the Hypercat ontology (Tachmazidis et al, 2016), which captures the above-mentioned Hypercat structure, thus providing a translation mechanism from a JSON-based to a JSON-LD based catalogue. The proposed Hypercat ontology is available with the uri:
http://portal.bt-hypercat.com/ontologies/hypercat
and captures the core properties that would enable the development of JSON-LD based catalogues. Namespaces for the Hypercat ontology can be written prefixing concepts and properties with “hypercat:”, which corresponds to the uri “http://portal.bt-hypercat.com/ontologies/hypercat”.
Currently, it is part of an IoT Data Hub https://portal.bt-hypercat.com/, while as a next step it will be proposed to the Hypercat community for standardization. Providing catalogues in JSON-LD, based on a well-defined ontology, its believed that it would further increase interoperability and offer intelligent reasoning capabilities. The Hypercat ontology consists of a class hierarchy that is depicted in Figure 1, a range of properties that are included in Table 1. The core hierarchy is rich enough to capture the corresponding constructs of the JSON-based catalogue while providing the flexibility for further extensions. The Hypercat ontology consist of class MetadataAnnotator (having two subclasses, Catalogue and Items) and class Search. As described above, a Metadata Object is applicable to both the catalogue itself and each catalogue item. Hence the class MetadataAnnotator, which captures metadata properties that are applicable to both Catalogue Objects and Item Objects. Note that the Hypercat 3.00 specification defines certain properties as applicable to either Catalogue Objects or Item Objects, but not both, as such properties cannot be included in the definition of class MetadataAnnotator.
Subsequently, class MetadataAnnotator has two subclasses, namely class Catalogue and class Item. In essence, class Catalogue models a Catalogue Object defining properties that are applicable only to the catalogue’s metadata, while class Item models an Item Object defining properties that are applicable only to an item’s metadata. In order to build a semantically enriched catalogue, class Catalogue is related to class Item through property hasItem, which means that a given Catalogue may contain a collection of Items. Class Search models the various types of searches that are supported by a given Catalogue, with the two classes being related through property supportsSearch. The set of currently supported searches is defined through individuals of class Search. Note that the details of supported search types will be covered below.

JSON-based JSON-LD based
urn:X-hypercat:rels:hasDescription:enhttps://www.w3.org/2000/01/rdf-schema#comment
urn:X-hypercat:rels:supportsSearchhypercat:supportsSearchurn:X-hypercat:rels:isContentTypehypercat:isContentTypeurn:X-hypercat:rels:hasHomepagehypercat:hasHomepageurn:X-hypercat:rels:containsContentTypehypercat:containsContentTypeurn:X-hypercat:rels:hasLicensehypercat:hasLicenseurn:X-hypercat:rels:acquireCredentialhypercat:acquireCredentialurn:X-hypercat:rels:eventSourcehypercat:eventSourceurn:X-hypercat:rels:hasRobotstxthypercat:hasRobotstxturn:X-hypercat:rels:accessHinthypercat:accessHinturn:X-hypercat:rels:lastUpdatedhypercat:lastUpdatedurn:X-hypercat:search:simplehypercat:SimpleSearchurn:X-hypercat:search:geoboundhypercat:GeoboundSearchurn:X-hypercat:search:lexrangehypercat:LexrangeSearchurn:X-hypercat:search:multihypercat:MultiSearchurn:X-hypercat:search:prefixhypercat:PrefixSearchurn:X-hypercat:search:semantichypercat:SemanticSearchTable SEQ Table * ARABIC 1: Hypercat Core properties mapped to existing JSON properties
Figure SEQ Figure * ARABIC 1: The Hypercat OntologyBT Hypercat OntologyBT Hypercat Ontology is an ontology which extends the core of the Hypercat specification. Thus, this is an example of how the ontologies extent to the Hypercat core ontology and specification. This ontology will be also an example to the translator for JSON-LD based Hypercat catalogue to the following chapter. The data enrichment in the BT Hypercat Data Hub can succeed in by representing data in RDF using properties and concepts defined in an OWL ontology. Figure 2 demonstrates the top-level concepts of the BT Hypercat Ontology.

Figure SEQ Figure * ARABIC 2: The BT Hypercat OntologyIt can be seen that; the Feed is the top-level class for every data feed that is declared in the knowledge base. It has the semantic properties of feeds such as feed id, creator, update date, title, url, status, description, location name, domain and disposition. Moreover, there are also three subclasses of class Feed, which are: SensorFeed, EventFeed, and LocationFeed which represent the feeds for sensors, events and location respectively. The modelled data has been merged into the BT Hypercat Data Hub and it can be one of the following feed types: (a) SensorFeed, (b) EventFeed, and (c) LocationFeed. In brief, every data source can present their available information over the BT Hypercat Data Hub by delivering a single feed. A feed should be understood as a source of sensor readings, events or locations. Inside every feed, there is data which is available over datastreams, its defined by the class Datastream which has two subclasses specifically: SensorStream and EventStream representing the datastreams for sensors and events respectively. Therefore, a feed can deliver a set of datastreams that are narrowly related, for example, a data feed for a weather can have different datastreams that may deliver sensor readings for temperature, humidity and visibility. The information about locations can be considered by a feed type of LocationFeed and it can provide information straight by returning locations, i.e. locations are attached to and provided by a given feed.
The BT Hypercat Ontology has been developed and is available online with the uri:
http://portal.bt-hypercat.com/ontologies/bt-hypercat
There are also BT Hypercat online catalogues both in JSON and RDF a work by Tachmazidis et al, 2016-2017. These catalogues are available to find with the uris “http://portal.bt-hypercat.com/cat” and “http://portal.bt-hypercat.com/cat-rdf ” respectively. These catalogues contain details about the feeds and information sources sideways with extra metadata like tags, which let better-quality search and discovery (Tachmazidis et al, 2017).

JSON-LD – JSON for Linking DataJSON-LD is attempting to create a simple method to express Linked Data in JSON and the same time add semantics to JSON documents. The designing of JSON-LD is very simple and human understanding. The main goal was to be very easy for the developers to understand it and translate their JSON documents to semantically JSON-LD. Thereafter, a triple-centric approach was followed, and it was looking more or less like a direct translation from Turtle to JSON. For this reason, to the latest versions of JSON-LD, the syntax was transformed and allows the serialization of data to be more indiscernible from traditional JSON. The only thing that a developer needs to know to develop a simple JSON-LD document is plain JSON and two keywords which are (@context and @id) to use the basic functionality of JSON-LD. While JSON-LD is 100% compatible with plain JSON, can let the developers use their current libraries and tools. This can also be very helpful and important for businesses because it let them add meaning to their existing JSON documents without making troubles to their processes and is clear to their customers. Meanwhile, JSON-LD can support every major RDF concept (Lanthaler & Gült, 2012). Figure 3 demonstrates a JSON-LD’s data model, which is a Linked Data graph. It can be seen that the nodes in the graph are named subjects and objects while the edges are named properties (predicates in RDF). The node which has at least one leaving edge is the subject while an object is a node where has at least one received edge. This means that a node can be a subject and an object simultaneously. A subject to be identified and refundable should be labelled with an IRI. This may be not a mandatory requirement because JSON-LD can support unlabelled node. However, this kind of nodes does not achieve the requirements of Linked Data they can be supported because they can let certain use cases which need just locally referenceable data. Again, the same goes for the properties (edges): if they are labelled by IRI then they are referenceable and makes them Linked Data; if not they are just JSON properties that have only meaning in the specific document. In the other hand for the objects is deferent, if the object is labelled by an IRI, then it is called object, but if it is labelled by something else that is not IRI such as numbers, it is called value, for example, RDF’s literal (Lanthaler & Gült, 2012).

Figure SEQ Figure * ARABIC 3: A Linked Data graph
Chapter 3Hypercat JSON to Hypercat JSON-LDIn this chapter, there is a description of the translation of every aspect of Hypercat specification from JSON to JSON-LD. Note that JSON-LD is equivalent to both JSON and RDF. The mapping of the JSON properties it already been provided by a previous translation of Hypercat JSON to RDF. Table 1 was used in order to create a translator from a JSON-based catalogue to a JSON-LD based catalogue. The core idea behind the translation follows the same rational as for RDF, while the transformation of subjects, predicates and objects follows the JSON-LD format. For example, for the JSON-based catalogue with the uri http://portal.bt-hypercat.com/cat
the following catalogue-metadata, namely metadata about the catalogue itself:
“rel”: “urn:X-hypercat:rels:isContentType”
“val”: “application/vnd.hypercat.catalogue+json”
will be translated in JSON-LD, using Table 1:
“@id”: “http://portal.bt-hypercat.com/cat-json-ld”,
“http://portal.bt-hypercat.com/ontologies/hypercat#isContentType”: “application/ld+json”
It is worth noting that, the MIME type of the JSON-LD based catalogue is “application/ld+json”. The keyword “@id” identifies the unique things that are being described in the document with IRIs. Thus, each Item Object is translated from “href”: “http://api.feed” to “@id”: “http://api.feed”.

Similar translation should be applied to most properties in Table 1, with several exceptions that include supportsSearch, which is a property where, for the JSON-based catalogue, both rel and val are URIs. Moreover, note that class Search represents semantically the various types of searches as named individuals, which in JSON-LD should be translated using the keyword “@id”.

Thus, for the JSON-based catalogue http://portal.bt-hypercat.com/cat, the following catalogue-metadata:
“rel”: “urn:X-hypercat:rels:supportsSearch”
“val”: “urn:X-hypercat:search:simple”
will be translated in JSON-LD, using Table 1:
“@id”: “http://portal.bt-hypercat.com/cat-json-ld”,
“http://portal.bt-hypercat.com/ontologies/hypercat#supportsSearch”: {
“@id”: “http://portal.bt-hypercat.com/ontologies/hypercat#SimpleSearch”}
The translation of the property “https://www.w3.org/2000/01/rdf-schema#comment” needs to include both the language of the current document, using the keyword “@language”, and the text of the description, using the keyword “@value”. The “@language” keyword is to specify the language of the string value which the description is typed, and the “@value” keyword is the text of the description.
Thus, for the JSON-based catalogue http://portal.bt-hypercat.com/cat, the following catalogue-metadata:
“rel”: “urn:X-hypercat:rels:hasDescription:en”
“val”: “Hypercat DataHub Catalog”
will be translated in JSON-LD, using Table 1:
“@id”: “http://portal.bt-hypercat.com/cat-json-ld”,
“http://www.w3.org/2000/01/rdf-schema#comment” : {
“@language”: “en”,
“@value”: “Hypercat DataHub Catalog”}
The translation of the property hypercat:lastUpdated needs to include both datatype, using the keyword “@type”, and relevant data, using the keyword “@value”.

The “@type” keyword is used to set the datatype of a node or typed value. In this situation, the type information is the “http://www.w3.org/2001/XMLSchema#dateTime”. The “@value” keyword is used again to specify the data that is related to the actual property.

Thus, the following Item Object (in items):
“href”: “http://api.bt-hypercat.com/sensors/feeds/UUID”
and “item-metadata” containing
“rel”: “urn:X-hypercat:rels:lastUpdated”
“val”: “2018-05-08T00:00:00Z”
will be translated in JSON-LD, using Table 1:
“@id”: “http://api.bt-hypercat.com/sensors/feeds/UUID”,
“http://portal.bt-hypercat.com/ontologies/hypercat#lastUpdated”: {
“@type”: “http://www.w3.org/2001/XMLSchema#dateTime”,
“@value”: “2018-05-08T00:00:00Z”}
The keyword “@graph” must be added to the top of the document. The document itself is expanded, which means all prefixes and terms are in full IRIs. The use of this mechanism is very useful since the number of nodes that exist at the document’s top level share the same context. The entire catalogue must be included inside a graph’s array ({@graph:Hypercat JSON-LD catalogue}). Note that the keyword “@context” is optional, thus it can be omitted within a given catalogue.
For the translation of the BT Data Hub’s JSON-based catalogue, it’s been used as an extension of the core ontology which was developed and made available with the urihttp://portal.bt-hypercat.com/ontologies/bt-hypercat
The namespaces for the BT Hypercat ontology can be written with “bt-hypercat:”. In this way, “item-metadata” containing
“rel”: “urn:X-bt:rels:feedTitle”,
“val” : “Met Office Datapoint Observations”
this property will be translated to JSON-LD using the BT Hypercat ontology and not the core Hypercat ontology:
“@id”: “http://api.bt-hypercat.com/sensors/feeds/UUDI”,
“http://portal.bt-hypercat.com/ontologies/bt-hypercat#feed_title”:
“Met Office Datapoint Observations”
One more change which must take place from the JSON-based BT Hypercat to JSON-LD-based is the type class:
“rel”: “http://www.w3.org/1999/02/22-rdf-syntax-ns#type”
The above class shows the type of each feed, so for the JSON-LD must change to the keyword “@type”. Again, for the item-metadata containing :
“rel”: “http://www.w3.org/1999/02/22-rdf-syntax-ns#type”,
“val”: “http://portal.bt-hypercat.com/ontologies/bt-hypercat#sensors”
will be translated to the following:
“@id”: “http://api.bt-hypercat.com/sensors/feeds/UUDI”,
“@type”: “http://portal.bt-hypercat.com/ontologies/bt-hypercat#sensors”
Duplicate keys are not allowed in JSON-LD. In order to avoid such duplicates in any given JSON-LD based catalogue, catalogue’s and items’ descriptions must be stored as a separate JSON object (one per unique subject), while each property must be included once with multiple values being added into an array.

For example, if we get the following supportsSearch:
{“rel”: “urn:X-hypercat:rels:supportsSearch”,
“val”: “urn:X-hypercat:search:simple” },
{“rel”: “urn:X-hypercat:rels:supportsSearch”,
“val”: “urn:X-hypercat:search:geobound” }
will be translated in JSON-LD: (storing supported searches into an array): the searches must be entered into an array and the property must be provided once, like the following:
“@id”: “http://portal.bt-hypercat.com/cat-json-ld”,
“http://portal.bt-hypercat.com/ontologies/hypercat#supportsSearch”:
{“@id”: “http://portal.bt-hypercat.com/ontologies/hypercat#SimpleSearch”},
{“@id”: “http://portal.bt-hypercat.com/ontologies/hypercat#GeoboundSearch”}
the same goes for every property that is repeated in a given Catalogue such as hypercat:isContentType:
{“rel”:”urn:X-hypercat:rels:isContentType”,
“val”:”application/json”},
{“rel”:”urn:X-hypercat:rels:isContentType”,
“val”:”application/xml”},
{“rel”:”urn:X-hypercat:rels:isContentType”,
“val”:”text/xml”},
{“rel”:”urn:X-hypercat:rels:isContentType”,
“val”:”text/csv”}
and the translation is the following:
“http://portal.bt-hypercat.com/ontologies/hypercat#isContentType”:
“application/json”,
“application/xml”,
“text/xml”,
“text/csv”

For properties that are not provided in Table 1, Hypercat JSON-LD developers are encouraged to develop their own OWL ontology by extending the one proposed in the project of Tachmazidis et al, 2016 the Hypercat RDF: Semantic Enrichment for IoT. Thus, the newly defined ontology would capture the meaning of their catalogue, by defining additional properties, and would enable the full translation of their JSON-based catalogue into a JSON-LD based catalogue. Alternatively, Hypercat JSON-LD developers could develop and translate only the main properties, using Table 1, which would result in. Even though in this case the JSON-LD based catalogue would contain less information compared to the JSON-based catalogue, it would still be a minimal yet valid Hypercat JSON-LD catalogue.

Hypercat BT JSON-based to JSON-LD basedThe following examples are the JSON-based properties from the core Hypercat and how with the help of Table 1. We can translate them from JSON property to RDF property and then use them for the JSON-LD translation with the full ontology uri:
Table 1.

“rel”:”urn:X-hypercat:rels:hasDescription:en”,
“val”:”Test Hypercat Catalogue”
to :
“https://www.w3.org/2000/01/rdf-schema#comment “: {
“@language”: “en”,
“@value”: “Test Hypercat Catalogue”}
{ “rel”:”urn:X-hypercat:rels:isContentType”,
“val”:”application/vnd.hypercat.catalogue+json”}
to:
“http://portal.bt-hypercat.com/ontologies/hypercat#isContentType”: “application/vnd.hypercat.catalogue+json”
{“rel”:”urn:X-hypercat:rels:hasHomepage”,
“val”:”http://home.page.com”}
to:
“http://portal.bt-hypercat.com/ontologies/hypercat#hasHomepage”: {
“@id”: “http://home.page.com”}
{“rel”:”urn:X-hypercat:rels:containsContentType”,
“val”:”text/xml”}
to:
“http://portal.bt-hypercat.com/ontologies/hypercat#containsContentType”: “text/xml”
{“rel”: “urn:X-hypercat:rels:hasLicense”,
“val”: “http://licence.html”}
to:
“http://portal.bt-hypercat.com/ontologies/hypercat#hasLicense”: {
“@id”: “http://licence.html”}
{“rel”: “urn:X-hypercat:rels:acquireCredential”,
“val”: “http://request.credentials.html”}
to:
“http://portal.bt-hypercat.com/ontologies/hypercat#acquireCredential”: {
“@id”: “http://request.credentials.html”}
{“rel”: “urn:X-hypercat:rels:eventSource”,
“val”: “http://event.source.html”}
to:
“http://portal.bt-hypercat.com/ontologies/hypercat#eventSource”: {
“@id”: “http://event.source.html”}
{ “rel”: “urn:X-hypercat:rels:hasRobotstxt”,
“val”: “http://catalogue/robots.txt”}
to:
“http://portal.bt-hypercat.com/ontologies/hypercat#hasRobotstxt”: {
“@id”: “http://catalogue/robots.txt”}
{“rel”: “urn:X-hypercat:rels:accessHint”,
“val”: “http://access.hint.html”}
to:
“http://portal.bt-hypercat.com/ontologies/hypercat#accessHint”: {
“@id”: “http://access.hint.html”}
{“rel”: “urn:X-hypercat:rels:lastUpdated”,
“val”: “2017-12-01T00:00:00Z”}
to:
“http://portal.bt-hypercat.com/ontologies/hypercat#lastUpdated”: {
“@type”: “xsd:dateTime”,
“@value”: “2017-12-01T00:00:00+00:00”}
The following are the search individuals of the catalogue. To avoid the duplicate key found the search individuals must be entered into an array with a single key (predicate).
{“rel”:”urn:X-hypercat:rels:supportsSearch”,
“val”:”urn:X-hypercat:search:simple”},
{“rel”:”urn:X-hypercat:rels:supportsSearch”,
“val”:”urn:X-hypercat:search:geobound”},
{“rel”:”urn:X-hypercat:rels:supportsSearch”,
“val”:”urn:X-hypercat:search:lexrange”},
{“rel”:”urn:X-hypercat:rels:supportsSearch”,
“val”:”urn:X-hypercat:search:multi”},
{“rel”:”urn:X-hypercat:rels:supportsSearch”,
“val”:”urn:X-hypercat:search:prefix”},
{“rel”:”urn:X-hypercat:rels:supportsSearch”,
“val”:”urn:X-hypercat:search:semantic”}
to:
“http://portal.bt-hypercat.com/ontologies/hypercat#supportsSearch”:
{“@id”: “http://portal.bt-hypercat.com/ontologies/hypercat#SimpleSearch”},
{“@id”: “http://portal.bt-hypercat.com/ontologies/hypercat#GeoboundSearch”},
{“@id”: “http://portal.bt-hypercat.com/ontologies/hypercat#LexrangeSearch”},
{“@id”: http://portal.bt-hypercat.com/ontologies/hypercat#MultiSearch”},
{“@id”: “http://portal.bt-hypercat.com/ontologies/hypercat#PrefixSearch”},
{“@id”: “http://portal.bt-hypercat.com/ontologies/hypercat#SemanticSearch”}
Next, we have all BT Hypercat JSON-based catalogue properties where we use again the ontology from the RDF translation, to translate them to JSON-LD. The following are template examples with every possible translation from BT Hypercat JSON-based catalogue to BT Hypercat JSON-LD-based catalogue.
For the first template the property is defined in a full URI and an object that is a string value:
Core Hypercat
“http://portal.bt-hypercat.com/ontologies/hypercat#isContentType”: “application/ld+json”
“http://portal.bt-hypercat.com/ontologies/hypercat#containsContentType”: “text/xml”,
Class: Feed
“http://portal.bt-hypercat.com/ontologies/bt-hypercat#feed_id”: “feedId”,
“http://portal.bt-hypercat.com/ontologies/bt-hypercat#feed_creator”: “feedCreator”,
“http://portal.bt-hypercat.com/ontologies/bt-hypercat#feed_title”: “feedTitle”,
“http://portal.bt-hypercat.com/ontologies/bt-hypercat#feed_status”: “feedStatus”,
“http://portal.bt-hypercat.com/ontologies/bt-hypercat#feed_private”: “feedPrivate”,
“http://portal.bt-hypercat.com/ontologies/bt-hypercat#feed_description”: “feedDescription”,
“http://portal.bt-hypercat.com/ontologies/bt-hypercat#feed_email” : “feedEmail”,
“http://portal.bt-hypercat.com/ontologies/bt-hypercat#feed_tag”: “feedTag”,
“http://portal.bt-hypercat.com/ontologies/bt-hypercat#feed_location_name”: “feedLocationName”,
“http://portal.bt-hypercat.com/ontologies/bt-hypercat#feed_exposure”: “feedExposure”,
“http://portal.bt-hypercat.com/ontologies/bt-hypercat#feed_domain” : “feedDomain”,
“http://portal.bt-hypercat.com/ontologies/bt-hypercat#feed_disposition”: “feedDisposition”,
“http://portal.bt-hypercat.com/ontologies/bt-hypercat#feed_the_geom”: “feedTheGeom”,
Class: DataStream
“http://portal.bt-hypercat.com/ontologies/bt-hypercat#datastream_id”: “datastreamId”,
“http://portal.bt-hypercat.com/ontologies/bt-hypercat#datastream_tag”: “datastreamTag”,
“http://portal.bt-hypercat.com/ontologies/bt-hypercat#datastream_max_value”: “datastreamMaxValue”,
“http://portal.bt-hypercat.com/ontologies/bt-hypercat#datastream_min_value”: “datastreamMinValue”,
“http://portal.bt-hypercat.com/ontologies/bt-hypercat#datastream_unit_symbol”: “datastreamUnitSymbol”,
“http://portal.bt-hypercat.com/ontologies/bt-hypercat#datastream_unit_text”: “datastreamUnitText”,
The second template is where the object is a string/dateTime, so the “@type” keyword must be added with the “http://www.w3.org/2001/XMLSchema#dateTime” to define the dateTime type:
Core Hypercat
“http://portal.bt-hypercat.com/ontologies/hypercat#lastUpdated”: {
“@type”:”http://www.w3.org/2001/XMLSchema#dateTime”,
“@value”: “2018-05-08T00:00:00Z”},
Class: Feed
“http://portal.bt-hypercat.com/ontologies/bt-hypercat#feed_updated”: {
“@type”:”http://www.w3.org/2001/XMLSchema#dateTime”,
“@value”: “2018-05-08T00:00:00Z”},
Class: DataStream
“http://portal.bt-hypercat.com/ontologies/bt-hypercat#datastream_current_time”: {
“@type”:”http://www.w3.org/2001/XMLSchema#dateTime”,
“@value”: “datastreamCurrentTime”},
The third template is where that is necessary to add the object as a string/anyURI , so the “@type” keyword must be added with the “http://www.w3.org/2001/XMLSchema#anyURI” to define the anyURI type.
Class: Feed
“http://portal.bt-hypercat.com/ontologies/bt-hypercat#feed_url”: {
“@type”:”http://www.w3.org/2001/XMLSchema#anyURI”,
“@value”: “/feed/uri”},
“http://portal.bt-hypercat.com/ontologies/bt-hypercat#feed_icon”: {
“@type”:”http://www.w3.org/2001/XMLSchema#anyURI”,
“@value”: “/feed/icon”},
“http://portal.bt-hypercat.com/ontologies/bt-hypercat#feed_website”: {
“@type”:”http://www.w3.org/2001/XMLSchema#anyURI”,
“@value”: “feed/website”},
The following template is the one where the object is a URL and must come with the keyword “@id” and the following are the properties where their values should be translated with this template:
Core Hypercat
“http://portal.bt-hypercat.com/ontologies/hypercat#hasHomepage”: {
“@id”: “http://home.page.com”},
“http://portal.bt-hypercat.com/ontologies/hypercat#hasLicense”: {
“@id”: “http://licence.html”},
“http://portal.bt-hypercat.com/ontologies/hypercat#acquireCredential”: {
“@id”: “http://request.credentials.html”},
“http://portal.bt-hypercat.com/ontologies/hypercat#eventSource”: {
“@id”: “http://event.source.html”},
“http://portal.bt-hypercat.com/ontologies/hypercat#hasRobotstxt”: {
“@id”: “http://catalogue/robots.txt”},
“http://portal.bt-hypercat.com/ontologies/hypercat#accessHint”: {
“@id”: “http://access.hint.html”},
Class: EventStream”http://portal.bt-hypercat.com/ontologies/bt-hypercat#hasEventStream”: {
“@id”: “http://api.test.datastream”},
Class: EventFeed”http://portal.bt-hypercat.com/ontologies/bt-hypercat#belongsToEventFeed”: {
“@id”: “http://api.test.feed”},
Class: SensorStream”http://portal.bt-hypercat.com/ontologies/bt-hypercat#hasSensorStream”: {
“@id”: “http://api.test.datastream”},
Class: SensorFeed”http://portal.bt-hypercat.com/ontologies/bt-hypercat#belongsToSensorFeed”: {
“@id”: “http://api.test.feed”},
The “@id” template must also be used for the supportSearch property, but if there are more than one search types then they must be entered in an array just like the following example:
“http://portal.bt-hypercat.com/ontologies/hypercat#supportsSearch”:
{“@id”: “http://portal.bt-hypercat.com/ontologies/hypercat#SimpleSearch”},
{“@id”: “http://portal.bt-hypercat.com/ontologies/hypercat#GeoboundSearch”},
{“@id”: “http://portal.bt-hypercat.com/ontologies/hypercat#LexrangeSearch”},
{“@id”: http://portal.bt-hypercat.com/ontologies/hypercat#MultiSearch”},
{“@id”: “http://portal.bt-hypercat.com/ontologies/hypercat#PrefixSearch”},
{“@id”: “http://portal.bt-hypercat.com/ontologies/hypercat#SemanticSearch”}
The last template is for the property of types of each class and comes with the keyword “@type” this comes for each JSON-based (href) where in the JSON-LD changes to “@id” and it defined the type of each “@id”:
Class: EventFeed
For every “EventFeed” should have the following JSON-LD @type:
“rel”:”http://www.w3.org/1999/02/22-rdf-syntax-ns#type” “val”:”http://portal.bt-hypercat.com/ontologies/bt-hypercat#EventFeed”
to: “@type”: “http://portal.bt-hypercat.com/ontologies/bt-hypercat#EventFeed”
Class: LocationFeedEvery “LocationFeed” should have the following JSON-LD @type:
“rel”:”http://www.w3.org/1999/02/22-rdf-syntax-ns#type” “val”:”http://portal.bt-hypercat.com/ontologies/bt-hypercat#LocationFeed”
to: “@type”: “http://portal.bt-hypercat.com/ontologies/bt-hypercat#LocationFeed”
Class: SensorFeedEvery “SensorFeed” should have the following JSON-LD @type:
“rel”:”http://www.w3.org/1999/02/22-rdf-syntax-ns#type” “val”:”http://portal.bt-hypercat.com/ontologies/bt-hypercat#SensorFeed”
to: “@type”: “http://portal.bt-hypercat.com/ontologies/bt-hypercat#SensorFeed”
Class: EventStreamEvery “EventStream” should have the following JSON-LD @type:
“rel”:”http://www.w3.org/1999/02/22-rdf-syntax-ns#type” “val”:”http://portal.bt-hypercat.com/ontologies/bt-hypercat#EventStream”
to: “@type”: “http://portal.bt-hypercat.com/ontologies/bt-hypercat#EventStream”
Class: SensorStreamEvery “SensorStream” should have the following JSON-LD @type:
“rel”:”http://www.w3.org/1999/02/22-rdf-syntax-ns#type” “val”:”http://portal.bt-hypercat.com/ontologies/bt-hypercat#SensorStream”
to: “@type”: “http://portal.bt-hypercat.com/ontologies/bt-hypercat#SensorStream”
Example from JSON to JSON-LD based catalogue
This is an example from a BT Hypercat JSON based catalogue to a BT Hypercat JSON-LD based catalogue to help the readers of the above translation understand how it works. It starts with the introduction of a BT Hypercat JSON-based catalogue sample, with several search types into the catalogue following by items.

{ “catalogue-metadata”:
{“rel”:”urn:X-hypercat:rels:isContentType”,
“val”:”application/vnd.hypercat.catalogue+json”},
{“rel”:”urn:X-hypercat:rels:hasDescription:en”,
“val”:”BT Hypercat DataHub Catalog”},
{“rel”:”urn:X-hypercat:rels:supportsSearch”,
“val”:”urn:X-hypercat:search:simple”},
{“rel”:”urn:X-hypercat:rels:supportsSearch”,
“val”:”urn:X-hypercat:search:prefix”},
{“rel”:”urn:X-hypercat:rels:supportsSearch”,
“val”:”urn:X-hypercat:search:multi”},
{“rel”:”urn:X-hypercat:rels:supportsSearch”,
“val”:”urn:X-hypercat:search:lexrange”},
{“rel”:”urn:X-hypercat:rels:supportsSearch”,
“val”:”urn:X-hypercat:search:geobound”},
“items”:
{“href”:”http://api.bt-hypercat.com/sensors/feeds/fa899552-044a-48e2-bdbe-0076292fd4a2″,
“item-metadata”:{
“rel”:”urn:X-hypercat:rels:hasDescription:en”,
“val”:”Met Office Datapoint UK hourly site-specific observations for Killowen as recorded in real time by the Met Office UK Monitoring System. Parameters reported are based on the instrumentation installed at each site.”},
{“rel”:”urn:X-bt:rels:feedTitle”,
“val”:”Met Office Datapoint Observations – 99015 (Killowen)”},
{“rel”:”urn:X-bt:rels:feedTag”,
“val”:”weather”},
{“rel”:”urn:X-bt:rels:hasSensorStream”,
“val”:”http://api.bt-hypercat.com/sensors/feeds/fa899552-044a-48e2-bdbe-0076292fd4a2/datastreams/0″},
{“rel”:”urn:X-bt:rels:hasSensorStream”,
“val”:”http://api.bt-hypercat.com/sensors/feeds/fa899552-044a-48e2-bdbe-0076292fd4a2/datastreams/1″},
{“rel”:”urn:X-bt:rels:hasSensorStream”,
“val”:”http://api.bt-hypercat.com/sensors/feeds/fa899552-044a-48e2-bdbe-0076292fd4a2/datastreams/2″},
{“rel”:”urn:X-bt:rels:hasSensorStream”,
“val”:”http://api.bt-hypercat.com/sensors/feeds/fa899552-044a-48e2-bdbe-0076292fd4a2/datastreams/3″},
{“rel”:”http://www.w3.org/2003/01/geo/wgs84_pos#lat”,
“val”:”54.067″},
{“rel”:”http://www.w3.org/2003/01/geo/wgs84_pos#long”,
“val”:”-6.183″},
{“rel”:”urn:X-hypercat:rels:isContentType”,
“val”:”application/json”},
{“rel”:”urn:X-hypercat:rels:isContentType”,
“val”:”application/xml”},
{“rel”:”urn:X-hypercat:rels:isContentType”,
“val”:”text/xml”},
{“rel”:”urn:X-hypercat:rels:isContentType”,
“val”:”text/csv”},
{“rel”:”urn:X-hypercat:rels:hasLicense”,
“val”:”http://reference.data.gov.uk/id/open-government-licence”},
{“rel”:”http://www.w3.org/1999/02/22-rdf-syntax-ns#type”,
“val”:”http://portal.bt-hypercat.com/ontologies/bt-hypercat#sensors”},
{“rel”:”urn:X-hypercat:rels:lastUpdated”,
“val”:”2017-02-22T17:36:32Z”}
},
{“href”:”http://api.bt-hypercat.com/sensors/feeds/fa899552-044a-48e2-bdbe-0076292fd4a2/datastreams/0″,
“item-metadata”:{
“rel”:”urn:X-bt:rels:belongsToSensorFeed”,
“val”:”http://api.bt-hypercat.com/sensors/feeds/fa899552-044a-48e2-bdbe-0076292fd4a2″},
{“rel”:”urn:X-bt:rels:datastreamMaxValue”,
“val”:”max_value=50″},
{“rel”:”urn:X-bt:rels:datastreamMinValue”,
“val”:”min_value=-30″},
{“rel”:”urn:X-bt:rels:datastreamUnitText”,
“val”:”degrees Celsius”},
{“rel”:”urn:X-bt:rels:datastreamUnitSymbol”,
“val”:”degrees Celsius”},
{“rel”:”urn:X-bt:rels:datastreamUnitType”,
“val”:”derivedSI”},
{“rel”:”urn:X-bt:rels:datastreamTag”,
“val”:”temperature”},
{“rel”:”http://www.w3.org/1999/02/22-rdf-syntax-ns#type”,
“val”:”http://portal.bt-hypercat.com/ontologies/bt-hypercat#SensorStream”}
},
{“href”:”http://api.bt-hypercat.com/sensors/feeds/fa899552-044a-48e2-bdbe-0076292fd4a2/datastreams/1″,
“item-metadata”:{
“rel”:”urn:X-bt:rels:belongsToSensorFeed”,
“val”:”http://api.bt-hypercat.com/sensors/feeds/fa899552-044a-48e2-bdbe-0076292fd4a2″},
{“rel”:”urn:X-bt:rels:datastreamUnitText”,
“val”:”16 point compass”},
{“rel”:”urn:X-bt:rels:datastreamUnitType”,
“val”:”contextDependentUnits”},
{“rel”:”urn:X-bt:rels:datastreamTag”,
“val”:”winddirection”},
{“rel”:”http://www.w3.org/1999/02/22-rdf-syntax-ns#type”,
“val”:”http://portal.bt-hypercat.com/ontologies/bt-hypercat#SensorStream”}
},
{“href”:”http://api.bt-hypercat.com/sensors/feeds/fa899552-044a-48e2-bdbe-0076292fd4a2/datastreams/2″,
“item-metadata”:{
“rel”:”urn:X-bt:rels:belongsToSensorFeed”,
“val”:”http://api.bt-hypercat.com/sensors/feeds/fa899552-044a-48e2-bdbe-0076292fd4a2″},
{“rel”:”urn:X-bt:rels:datastreamUnitText”,
“val”:”miles per hour”},
{“rel”:”urn:X-bt:rels:datastreamUnitSymbol”,
“val”:”mph”},
{“rel”:”urn:X-bt:rels:datastreamUnitType”,
“val”:”derivedUnits”},
{“rel”:”urn:X-bt:rels:datastreamTag”,
“val”:”windspeed”},
{“rel”:”http://www.w3.org/1999/02/22-rdf-syntax-ns#type”,
“val”:”http://portal.bt-hypercat.com/ontologies/bt-hypercat#SensorStream”}
},
{“href”:”http://api.bt-hypercat.com/sensors/feeds/fa899552-044a-48e2-bdbe-0076292fd4a2/datastreams/3″,
“item-metadata”:{
“rel”:”urn:X-bt:rels:belongsToSensorFeed”,
“val”:”http://api.bt-hypercat.com/sensors/feeds/fa899552-044a-48e2-bdbe-0076292fd4a2″},
{“rel”:”urn:X-bt:rels:datastreamUnitText”,
“val”:”miles per hour”},
{“rel”:”urn:X-bt:rels:datastreamUnitSymbol”,
“val”:”mph”},
{“rel”:”urn:X-bt:rels:datastreamUnitType”,
“val”:”derivedUnits”},
{“rel”:”urn:X-bt:rels:datastreamTag”,
“val”:”windspeed”},
{“rel”:”urn:X-bt:rels:datastreamTag”,
“val”:”gust”},
{“rel”:”http://www.w3.org/1999/02/22-rdf-syntax-ns#type”,
“val”:”http://portal.bt-hypercat.com/ontologies/bt-hypercat#SensorStream”}
}
}
Furthermore, it continues with the same Hypercat catalogue sample but in JSON-LD based translation. It can be seen that the whole catalogue now is inside a graph, the content type of the catalogue has changed to JSON-LD and there are also changes to the properties showing their full URI by following the ontology’s changes of namespaces. In addition, a new property bt-hypercat:hasItem took place into the beginning of the catalogue having all items in an array (@id/ subject, ID’s). This is happening to serve the ontology’s property “hasItem”.

{“@graph” : {
“@id”: “http://localhost:8080/Hypercat-jsonld-full1/cat/Test1.json”,
“http://portal.bt-hypercat.com/ontologies/hypercat#isContentType” : “application/ld+json”,
“https://www.w3.org/2000/01/rdf-schema#comment”: {“@language” : “en”,
“@value”: “BT Hypercat DataHub Catalog”},
“http://portal.bt-hypercat.com/ontologies/hypercat#hasItem”:
{“@id”: “http://api.bt-hypercat.com/sensors/feeds/fa899552-044a-48e2-bdbe-0076292fd4a2”},
{“@id”:”http://api.bt-hypercat.com/sensors/feeds/fa899552-044a-48e2-bdbe-0076292fd4a2/datastreams/0″},
{“@id”:”http://api.bt-hypercat.com/sensors/feeds/fa899552-044a-48e2-bdbe-0076292fd4a2/datastreams/1″},
{“@id”:”http://api.bt-hypercat.com/sensors/feeds/fa899552-044a-48e2-bdbe-0076292fd4a2/datastreams/2″},
{“@id”:”http://api.bt-hypercat.com/sensors/feeds/fa899552-044a-48e2-bdbe-0076292fd4a2/datastreams/3″}
,
“http://portal.bt-hypercat.com/ontologies/hypercat#supportsSearch” :
{“@id”:”http://portal.bt-hypercat.com/ontologies/hypercat#SimpleSearch”},
{“@id”:”http://portal.bt-hypercat.com/ontologies/hypercat#PrefixSearch”},
{“@id”:”http://portal.bt-hypercat.com/ontologies/hypercat#MultiSearch”},
{“@id”:”http://portal.bt-hypercat.com/ontologies/hypercat#LexrangeSearch”},
{“@id”:”http://portal.bt-hypercat.com/ontologies/hypercat#GeoboundSearch”}
},
{“@id”: “http://api.bt-hypercat.com/sensors/feeds/fa899552-044a-48e2-bdbe-0076292fd4a2”,

“https://www.w3.org/2000/01/rdf-schema#comment” : {“@language” : “en”,
“@value”: “Met Office Datapoint UK hourly site-specific observations for Killowen as recorded in real time by the Met Office UK Monitoring System. Parameters reported are based on the instrumentation installed at each site.”},
“http://portal.bt-hypercat.com/ontologies/bt-hypercat#feed_title”:”Met Office Datapoint Observations – 99015 (Killowen)”,
“http://portal.bt-hypercat.com/ontologies/bt-hypercat#feed_tag” : “weather”,
“http://portal.bt-hypercat.com/ontologies/bt-hypercat#hasSensorStream” :
{“@id”:”http://api.bt-hypercat.com/sensors/feeds/fa899552-044a-48e2-bdbe-0076292fd4a2/datastreams/0″},
{“@id”:”http://api.bt-hypercat.com/sensors/feeds/fa899552-044a-48e2-bdbe-0076292fd4a2/datastreams/1″},
{“@id”:”http://api.bt-hypercat.com/sensors/feeds/fa899552-044a-48e2-bdbe-0076292fd4a2/datastreams/2″},
{“@id”:”http://api.bt-hypercat.com/sensors/feeds/fa899552-044a-48e2-bdbe-0076292fd4a2/datastreams/3″}
,
“http://www.w3.org/2003/01/geo/wgs84_pos#lat” : “54.067”,
“http://www.w3.org/2003/01/geo/wgs84_pos#long” : “-6.183”,
“http://portal.bt-hypercat.com/ontologies/hypercat#isContentType” :
“application/json”,
“application/xml”,
“text/xml”,
“text/csv”,
“http://portal.bt-hypercat.com/ontologies/hypercat#hasLicense” : {
“@id”: “http://reference.data.gov.uk/id/open-government-licence”},
“@type” : “http://portal.bt-hypercat.com/ontologies/bt-hypercat#sensors”,
“http://portal.bt-hypercat.com/ontologies/hypercat#lastUpdated” : {
“@type”:”http://www.w3.org/2001/XMLSchema#dateTime”,
“@value”: “2017-02-22T17:36:32Z”}
},
{“@id”:”http://api.bt-hypercat.com/sensors/feeds/fa899552-044a-48e2-bdbe-0076292fd4a2/datastreams/0″,
“http://portal.bt-hypercat.com/ontologies/bt-hypercat#belongsToSensorFeed” : {
“@id”: “http://api.bt-hypercat.com/sensors/feeds/fa899552-044a-48e2-bdbe-0076292fd4a2”},
“http://portal.bt-hypercat.com/ontologies/bt-hypercat#datastream_max_value”:”max_value=50″,
“http://portal.bt-hypercat.com/ontologies/bt-hypercat#datastream_min_value”:”min_value=-30″,
“http://portal.bt-hypercat.com/ontologies/bt-hypercat#datastream_unit_text”: “degrees Celsius”,
“http://portal.bt-hypercat.com/ontologies/bt-hypercat#datastream_unit_symbol”:”degrees Celsius”,
“http://portal.bt-hypercat.com/ontologies/bt-hypercat#datastream_unit_type”: “derivedSI”,
“http://portal.bt-hypercat.com/ontologies/bt-hypercat#datastream_tag”: “temperature”,
“@type” : “http://portal.bt-hypercat.com/ontologies/bt-hypercat#SensorStream”},
{“@id”:”http://api.bt-hypercat.com/sensors/feeds/fa899552-044a-48e2-bdbe-0076292fd4a2/datastreams/1″,
“http://portal.bt-hypercat.com/ontologies/bt-hypercat#belongsToSensorFeed” : {
“@id”: “http://api.bt-hypercat.com/sensors/feeds/fa899552-044a-48e2-bdbe-0076292fd4a2” },
“http://portal.bt-hypercat.com/ontologies/bt-hypercat#datastream_unit_text”:”16point compass”,
“http://portal.bt-hypercat.com/ontologies/bt-hypercat#datastream_unit_type”: “contextDependentUnits”,
“http://portal.bt-hypercat.com/ontologies/bt-hypercat#datastream_tag”: “winddirection”,
“@type” : “http://portal.bt-hypercat.com/ontologies/bt-hypercat#SensorStream”},
{“@id”:”http://api.bt-hypercat.com/sensors/feeds/fa899552-044a-48e2-bdbe-0076292fd4a2/datastreams/2″,
“http://portal.bt-hypercat.com/ontologies/bt-hypercat#belongsToSensorFeed” : {
“@id”: “http://api.bt-hypercat.com/sensors/feeds/fa899552-044a-48e2-bdbe-0076292fd4a2”},
“http://portal.bt-hypercat.com/ontologies/bt-hypercat#datastream_unit_text”: “miles per hour”,
“http://portal.bt-hypercat.com/ontologies/bt-hypercat#datastream_unit_symbol”: “mph”,
“http://portal.bt-hypercat.com/ontologies/bt-hypercat#datastream_unit_type”: “derivedUnits”,
“http://portal.bt-hypercat.com/ontologies/bt-hypercat#datastream_tag”: “windspeed”,
“@type”: “http://portal.bt-hypercat.com/ontologies/bt-hypercat#SensorStream”},
{“@id”:”http://api.bt-hypercat.com/sensors/feeds/fa899552-044a-48e2-bdbe-0076292fd4a2/datastreams/3″,
“http://portal.bt-hypercat.com/ontologies/bt-hypercat#belongsToSensorFeed” : {
“@id”: “http://api.bt-hypercat.com/sensors/feeds/fa899552-044a-48e2-bdbe-0076292fd4a2”},
“http://portal.bt-hypercat.com/ontologies/bt-hypercat#datastream_unit_text”: “miles per hour”,
“http://portal.bt-hypercat.com/ontologies/bt-hypercat#datastream_unit_symbol”: “mph”,
“http://portal.bt-hypercat.com/ontologies/bt-hypercat#datastream_unit_type”: “derivedUnits”,
“http://portal.bt-hypercat.com/ontologies/bt-hypercat#datastream_tag” :
“windspeed”,
“gust”,
“@type” : “http://portal.bt-hypercat.com/ontologies/bt-hypercat#SensorStream”}

}
Thus, following the above example of the BT Hypercat JSON to JSON-LD based catalogue and the ontology, anyone can translate its catalogue easily without any problems.
Hypercat JSON-based to JSON-LD based catalogue parserFor the complete translation of a given Hypercat JSON-based catalogue to JSON-LD based catalogue two parsers have been develop using the JavaScript programming language. The parsers are running through the Apache Tomcat server. The parsers collect the text from the JSON file where the catalogue is inside, then with the help of the specific functions, it sets (in mind) the href, the properties and the objects of the JSON-based catalogue to a triple-centric text. For example, the JSON-based Hypercat will look like the following in the JSON file :
{“href”:”http://api.bt-hypercat.com/sensors/feeds/fa899552-044a-48e2-bdbe-0076292fd4a2/datastreams/1″,
“item-metadata”:{
“rel”:”urn:X-bt:rels:belongsToSensorFeed”,
“val”:”http://api.bt-hypercat.com/sensors/feeds/fa899552-044a-48e2-bdbe-0076292fd4a2″
},{
“rel”:”urn:X-bt:rels:datastreamUnitText”,
“val”:”16 point compass”
},{
“rel”:”http://www.w3.org/1999/02/22-rdf-syntax-ns#type”,
“val”:”http://portal.bt-hypercat.com/ontologies/bt-hypercat#SensorStream”}
}
The triple-centric will look like the following, the first line is the subject following by the predicate and in the end is the object:
(SUBJECT)http://api.bt-hypercat.com/sensors/feeds/fa899552-044a-48e2-bdbe-0076292fd4a2/datastreams/1
(PREDICATE)urn:X-bt:rels:belongsToSensorFeed(OBJECT) http://api.bt-hypercat.com/sensors/feeds/fa899552-044a-48e2-bdbe-0076292fd4a2
(SUBJECT)http://api.bt-hypercat.com/sensors/feeds/fa899552-044a-48e2-bdbe-0076292fd4a2/datastreams/1
(PREDICATE)urn:X-bt:rels:datastreamUnitText(OBJECT) 16 point compass
(SUBJECT)http://api.bt-hypercat.com/sensors/feeds/fa899552-044a-48e2-bdbe-0076292fd4a2/datastreams/1
(PREDICATE) http://www.w3.org/1999/02/22-rdf-syntax-ns#type
(OBJECT) http://portal.bt-hypercat.com/ontologies/bt-hypercat#SensorStream
Additionally, the JSON-LD text can be created by JavaScript tables, so each table can have a unique subject/href following with the predicates/rels and objects/vals of the specified subject/predicate just like the JSON-LD. The following example it is how the (in mind) process of the parser works. It can be seen that in the first row there is the Subject-1 following by Predicate-1 and Object-1 but in the second row the Subject-1 is deleted. This is because is the same subject, so it does not need to be shown in the JSON-LD syntax again. Then the Predicate-2 and Object 2 follows. The same goes for the predicates. If a predicate is the same for the same subject just like the Subject-2, then the parser deletes the predicate and shows only the object. To be more precise, the Object-2 and Object-3 of Subject-2 will be set into an array to avoid the ‘duplicate key’ of JSON-LD.
SUBJECT PREDICATE OBJECT
SUBJECT-1 PREDICATE-1 OBJECT-1
SUBJECT-1 PREDICATE-2 OBJECT-2
SUBJECT-1 PREDICATE-3 OBJECT-3
SUBJECT-2 PREDICATE-1 OBJECT-1
SUBJECT-2 PREDICATE-2 OBJECT-2
SUBJECT-2 PREDICATE-2 OBJECT-3
SUBJECT-2 PREDICATE-3 OBJECT-4
Meanwhile, it transforms the plain properties to full URIs following the specified ontology. This triple-centric text is now the subjects, predicates and objects of the JSON-LD based catalogue, but without the correct keywords, it reminds of TURTLE. Then with another function, the parser sets the specific JSON-LD keywords such as “@id”, “@type” and “@value” to complete a valid translation. In the end, the parser prints the JSON-LD based catalogue to the HTML page. The following is an example of JSON-LD based:
{“@id”:”http://api.bt-hypercat.com/sensors/feeds/fa899552-044a-48e2-bdbe-0076292fd4a2/datastreams/1″,
“@type”: “http://portal.bt-hypercat.com/ontologies/bt-hypercat#SensorStream”,
“http://portal.bt-hypercat.com/ontologies/bt-hypercat#belongsToSensorFeed”: {
“@id”: “http://api.bt-hypercat.com/sensors/feeds/fa899552-044a-48e2-bdbe-0076292fd4a2” },
“http://portal.bt-hypercat.com/ontologies/bt-hypercat#datastream_unit_text”:”16 point compass”}
The parsers also collect the unique subjects of every item into the catalogue to add them into an array to the beginning of the catalogue to serve the ontology’s property hasItem. Thus, every catalogue will have a hasItem property in the beginning just like the following example:
“http://portal.bt-hypercat.com/ontologies/hypercat#hasItem”:
{“@id”: “http://api.bt-hypercat.com/events/feeds/ee9d9cd9-6953-4584-a59f-ea6fe5156ebb”},
{“@id”:”http://api.bt-hypercat.com/events/feeds/ee9d9cd9-6953-4584-a59f-ea6fe5156ebb/datastreams/1″},
{“@id”:”http://api.bt-hypercat.com/events/feeds/ee9d9cd9-6953-4584-a59f-ea6fe5156ebb/datastreams/2″},
{“@id”:”http://api.bt-hypercat.com/events/feeds/ee9d9cd9-6953-4584-a59f-ea6fe5156ebb/datastreams/3″},
{“@id”:”http://api.bt-hypercat.com/events/feeds/ee9d9cd9-6953-4584-a59f-ea6fe5156ebb/datastreams/4″},
{“@id”: “http://api.bt-hypercat.com/sensors/feeds/a78d4c54-15ec-4a60-a7e8-492fc36143d0”}
The second parser does the same job with the first one but with slight differences. It can translate every JSON-based catalogue to ‘extended’ JSON-LD based catalogues, this means that every object it is into an array for the developers who want the fully expanded form of their Hypercat catalogues.

{“@id”:”http://api.bt-hypercat.com/sensors/feeds/fa899552-044a-48e2-bdbe-0076292fd4a2/datastreams/1″,
“@type”: “http://portal.bt-hypercat.com/ontologies/bt-hypercat#SensorStream”,
“http://portal.bt-hypercat.com/ontologies/bt-hypercat#belongsToSensorFeed”: {
“@id”: “http://api.bt-hypercat.com/sensors/feeds/fa899552-044a-48e2-bdbe-0076292fd4a2” },
“http://portal.bt-hypercat.com/ontologies/bt-hypercat#datastream_unit_text”: “16 point compass”}
A future function that will be added to the parsers is to download the catalogue to a JSON-LD file. The parsers have been also uploaded to the Github’s website to encourage the large community of developers to use them and translate their Hypercat JSON-based catalogues to JSON-LD based. This is the link to the Github repository which includes the parsers “https://github.com/Mikegeo/hypercat-json-ld-parser”.
Chapter 4Hypercat JSON-LD SpecificationIn this chapter, is the inspection of every aspect of the Hypercat JSON-LD specification by following the structure of (the JSON-based) Hypercat 3.00 specification.

Hypercat File Format Specification: In the previous section we have provided the guide on how to develop a JSON-LD based catalogue, and we have already presented all standard semantic properties and their equivalent to JSON properties. Nevertheless, additional aspects need to be covered as well. For example, every instance of class MetadataAnnotator requires the mandatory property “https://www.w3.org/2000/01/rdf-schema#comment”, and may contain the non-compulsory properties hypercat:isContentType, hypercat:hasHomepage, hypercat:containsContentType and hypercat:supportsSearch. Moreover, the mandatory property hypercat:isContentType must be included in all instances of the Catalogue. However, each JSON-LD based catalogue has been defined in JSON-LD format with the MIME type to “application/ld+json”. The same terms of extensibility are followed along the lines of the Hypercat 3.00 specification: (a) an unknown metadata relationship should be ignored, (b) new search method can be added when it is supported by a catalogue server, (c) for human readable descriptions, a language can be added, (d) old style catalogues may point to a new style and vice versa without version ambiguity, and (e) the catalogue may contain any number of other properties classes, provided that they are defined in an ontology, according to developer’s needs.

Hypercat Server API Specification: Any JSON-LD based Hypercat server should follow the JSON-based Hypercat server specification with minor changes. Any JSON-LD based catalogue server should provide a publicly readable “/cat-json-ld” endpoint to serve a Hypercat document declared in JSON-LD. The requests into a JSON-LD based Hypercat server such as update, insert and delete can be executed them in the same way as for a JSON-based Hypercat server, but the response will be a JSON-LD based catalogue instead of a JSON-based catalogue. The search mechanisms, such as simple or multi can be performed in the same way, on top of the JSON-LD based catalogues. For a given JSON-LD based catalogue http://portal.bt-hypercat.com/cat-json-ld, simple search mechanism support can be advertised by including the following:
“@id”: “http://portal.bt-hypercat.com/cat-json-ld”,
“http://portal.bt-hypercat.com/ontologies/hypercat#supportsSearch”: {
“@id”: “http://portal.bt-hypercat.com/ontologies/hypercat#SimpleSearch”}
All of the query parameters must be URL encoded and are all optional. If there are numerous search parameters, the server must return the intersection of items where the search parameters match in a single item, combining parameters with boolean AND. The Simple search supports the following parameters: (a) s, which is the JSON-LD subject into the linked data graph, (b) p, which is the property (predicate in RDF), and (c) o, which is the JSON-LD object or value. Note that, if the (c) o, is labelled by an IRI, then it is called object, but if it is labelled by something else that is not IRI such as numbers, it is called value (Lanthaler & Gült, 2012). The following is an example of how we can query a given catalogue. Note that all query parameters must be URL encoded and are all optional.

?s=http://portal.bt-hypercat.com/ItemID
?p=http://portal.bt-hypercat.com/ontologies/hypercat#isContentType
?p=http://portal.bt-hypercat.com/ontologies/hypercat#supportsSearch&
o=http://portal.bt-hypercat.com/ontologies/hypercat#SimpleSearch
?o=2018-05-08T00:00:00Z
Hypercat Subscription: The specification of Hypercat 3.00 defines a simple subscription system, delivering an API for polling catalogues. A client with a subscription from a Hypercat server which provides a stream of events will receive a stream of events and every event will contain an event name and a body. By first fetching a catalogue and then accumulate the events that are in the catalogue, a client can keep a synchronized copy of a given catalogue. The existing Hypercat subscription mechanism can be used for a JSON-LD based catalogue with minor changes. A JSON-LD based catalogue that can be used for subscription, must have the property hypercat:eventsource. For events of a specific catalogue item in the catalogue, the event name is the (unique) JSON-LD’s subject (coming with the keyword @id) for the specified item. Furthermore, the event body for an item update event is the set of JSON-LD properties that are related to the specified item, whereas, for an item deletion event, the event body is an empty string.

Hypercat Resource Subscription: Hypercat offers the ability to link to resources through URIs. This kind of resources might contain real-time data mandatory for various applications. In the field of IoT, numerous use-cases are found where client applications required real-time data feeds from devices, hubs and other services. An option considered in the past was to place all data directly into Hypercat catalogues, but the idea was unsuitable due to the simple data model of a JSON-based catalogue. In contrast, a JSON-LD based catalogue could solve the problem of importing data straight into the Hypercat catalogue, assuming that imported data is semantically enriched and is provided in JSON-LD syntax.

Hypercat Signing: Hypercat Signing for a JSON-LD based catalogue can be done in a similar way to a JSON-based catalogue, since JSON-LD is fully compatible with plain JSON (Lanthaler ; Gült, 2012). For each item in the JSON-LD based catalogue, the signature may be added after the unique item’s @id. In this case, the digest can cover the @id and the item. For the entire Hypercat JSON-LD based catalogue, the signature may be added to the top of the document under the catalogue’s @id. In this case, the digest covers both catalogue and all items. A detailed description of signing and verification is referred to future work.

Hypercat Security Access Hints: The systems that support Hypercat should deliver open data with traversable links when possible. However, there are numerous systems that will possibly deliver resources or catalogues only to authenticated clients. Furthermore, where resources or catalogues are discoverable, but not available without authentication, authentication information can be provided to the clients. The property hypercat:accessHint should point to either machine or human readable description. A related point to consider is that, if there are multiple hypercat:accessHint declarations, the client should assume that the resource can be retrieved using multiple authentication systems. Hypercat Security Credential Acquisition: To access catalogues and resources, a Hypercat catalogue can support numerous methods of acquiring access credentials. Consequently, a catalogue or item, can use the property hypercat:acquireCredential to point at a self-describing web page or resource that will the client acquire credentials. A related point to consider is that if there are multiple hypercat:acquireCredential declarations, the client should assume that credentials can be acquired in multiple ways.

Hypercat Geographic Bounding Box Search: The geographic search permits the filtering of items that fall within a geographic region, which can be defined by a bounding box. The JSON-LD properties that a JSON-LD based catalogue may reuse are:
http://www.w3.org/2003/01/geo/wgs84pos#lat
http://www.w3.org/2003/01/geo/wgs84pos#long
and are defined by an external ontology. Additionally, a given JSON-LD based catalogue can let the client know that geographic bounding box search is supported, by adding the following:
“@id”: “http://portal.bt-hypercat.com/cat-json-ld”,
“http://portal.bt-hypercat.com/ontologies/hypercat#supportsSearch”: {
“@id”: “http://portal.bt-hypercat.com/ontologies/hypercat#GeoboundSearch”}
Geographic search supports the following parameters: (a) geobound-minlat, which is the inclusive lower bound of latitude of bounding box, (b) geobound-maxlat, which is the inclusive upper bound of latitude of bounding box, (c) geobound-minlong, which is the inclusive lower bound of longitude of the bounding box, (d) geobound-maxlong, which is the inclusive upper bound of longitude of the bounding box. Geographic search can be submitted by providing the above-mentioned parameters.

Hypercat Lexicographic Range Search: The lexicographic search allows searching for items which, when sorted lexicographically, fall between a minimum and maximum. Additionally, a given JSON-LD based catalogue can let the client know that lexicographic range search is supported, by adding the following
“@id”: “http://portal.bt-hypercat.com/cat-json-ld”,
“http://portal.bt-hypercat.com/ontologies/hypercat#supportsSearch”: {
“@id”: “http://portal.bt-hypercat.com/ontologies/hypercat#LexrangeSearch”}
Moreover, the property hypercat:lastUpdated could be used for dates and time. The Lexicographic search supports the following parameters: (a) lexrange-p, which is the JSON-LD’s property to search on, (b) lexrange-min, which is the lower bound of range to return (inclusive), and (c) lexrange-max, which is the upper bound of range to return (non-inclusive). Lexicographic search can be submitted by providing the above-mentioned
parameters.

Hypercat Robots Exclusion Search: A Hypercat JSON-LD catalogue can provide information to the client about a related robots.txt file, using the property hypercat:hasRobotstxt, which can be used by websites to connect with web crawlers and additional web robots. Note that if there is a robots exclusion _le, it must be located at the BASE URL of a catalogue and it must have the name robots.txt, namely JSON-LD’s object should have a URI of the form BASE URL/robots.txt”.

Hypercat Multi-Search: Hypercat can support various search extension types. These extensions are mostly variations of the simple search, and they can only allow for simple interactions with the catalogue. In order to combine geographic search and lexicographic range search two independent queries can be submitted and their results can be merged manually by the client, resulting in an inefficient solution. The multi-search lets the client to combine single or multiple search mechanisms supported by a server in order to retrieve the items of interest. A JSON-LD based catalogue can notify the client that multi-search is supported, by having the following:
“@id”: “http://portal.bt-hypercat.com/cat-json-ld”,
“http://portal.bt-hypercat.com/ontologies/hypercat#supportsSearch”: {
“@id”: “http://portal.bt-hypercat.com/ontologies/hypercat#MultiSearch”}
A multi-search query for a JSON-LD based catalogue can be submitted as a single JSON object. Multi-search supports the following parameters: (a) query, which is a JSON object, holding a URL query string as passed to underlying search mechanism, (b) intersection, which is a JSON array of objects that could contain query, intersection or union, and (c) union, which is a JSON array of objects that could contain query, intersection or union. All searches can be nested to allow complex mixing of union and intersection.

Hypercat Prefix Match Search: The prefix search allows searching for items where the search parameter is a prefix match of a catalogue item. Additionally, a given JSON-LD based catalogue can let the client know that prefix match search is supported, by adding the following:
“@id”: “http://portal.bt-hypercat.com/cat-json-ld”,
“http://portal.bt-hypercat.com/ontologies/hypercat#supportsSearch”: {
“@id”: “http://portal.bt-hypercat.com/ontologies/hypercat#PrefixSearch”}
If there are multiple search parameters, the server must return the intersection of items where search parameters match a single item, combining parameters with boolean AND. The prefix match search supports the following parameters: (a) prefix-s, which is a prefix of the JSON-LD’s subject, (b) prefix-p, which is a prefix of the JSON-LD’s property, and (c) prefix-o, which is a prefix of JSON-LD’s object.

Hypercat Linked Data rel: The Hypercat JSON rel for defining that the item at hand is an instance of an RDF class, is the keyword @type. Thus, no new property needs to be added.

Hypercat License rel: Hypercat catalogues or linked resources can be accessible under a specific license. Moreover, the property hypercat:hasLicense within a given catalogue allows the clients to determine the license under which the data is released. This property should point at a machine or human readable version of the license. In the case of multiple hypercat:hasLicense declarations, the client should assume that the resource is accessible under multiple licenses.

Chapter 5Semantic SearchSemantic search allows SPARQL-like queries on top of semantically enriched Hypercat catalogues, providing a searching mechanism that captures the underlying semantic hierarchy. As it mentioned above, JSON-LD can support every RDF major concept that’s why SPARQL can be used to query every JSON-LD based catalogue. Any valid JSON-LD catalogue is semantically enriched, thus supporting queries that return all catalogue items belonging to a specific class or its subclasses. Given a query where the rel (or JSON-LD predicate) is ‘@type’ (rdfs:type) and val (or JSON-LD object) is bt-hypercat:SensorFeed, with BT catalogue’s ontology defining that is bt-hypercat:SensorFeed is a subclass of bt-hypercat:Feed, semantic search will return all catalogue items that are instances of both bt-hypercat:Feed and bt-hypercat:SensorFeed. For example, it can return the bt-hypercat:belongsToSensorFeed, bt-hypercat:feed_title, bt-hypercat:feed_tag of each catalogues items and help the searcher find relatively items with the same bt-hypercat:SensorFeed of the given query. This would not be possible without the usage of the Hypercat JSON-LD to encode the subclass ontology and work with it. A given JSON-based catalogue can inform a client that semantic search is supported, by including the following rel, val pair:
“rel”: “urn:X-hypercat:rels:supportsSearch”
“val”: “urn:X-hypercat:search:semantic”
while a given JSON-LD based catalogue must include the following:
“@id”: “http://portal.bt-hypercat.com/cat-json-ld”,
“http://portal.bt-hypercat.com/ontologies/hypercat#supportsSearch”: {
“@id”: “http://portal.bt-hypercat.com/ontologies/hypercat#SemanticSearch”}
If multiple search parameters are supplied, the server must bind them to a single triple pattern and run a SPARQL query, including reasoning based on both catalogue’s ontology and catalogue itself. Semantic search supports the following parameters for JSON-based (resp. JSON-LD based) catalogues: (a) sem-href (resp. sem-s), which is a resource URI (resp. the subject), (b) sem-val (resp. sem-p), which is a semantic metadata relation (resp. predicate), and (c) sem-rel (resp. sem-o), which is a semantic metadata value (resp. object).

The Semantic search it is important and a useful addition to the Hypercat catalogue. This kind of search can understand the user’s intention and find relative items to the one the user search for and show them to the results. For Hypercat Semantic search can also find relative sensors, datasreams and events to the one the user search for, and then show a results list not only of the item the user search and its meta-data but also every single item and its meta-data which has a relative connection. For example, searching for a particular sensor, datastream and event into the Hypercat catalogue:
?sem-s=http://portal.bt-hypercat.com/ItemID
the result will not only show that item, but it will get the “@type” which is:
“@type”: “http://portal.bt-hypercat.com/ontologies/bt-hypercat#EventStream”
and the property :
“http://portal.bt-hypercat.com/ontologies/bt-hypercat#belongsToEventFeed” : {
“@id”: “http://api.bt-hypercat.com/FeedID” },
it will show all of its meta-data such as:
“http://portal.bt-hypercat.com/ontologies/bt-hypercat#belongsToEventFeed” : {
“@id”: “http://api.bt-hypercat.com/FeedID “},
“http://portal.bt-hypercat.com/ontologies/bt-hypercat#feed_title” : “”,
“http://portal.bt-hypercat.com/ontologies/bt-hypercat#feed_tag” : “event”,
“http://portal.bt-hypercat.com/ontologies/bt-hypercat#datastream_tag” : “roadworks”,
“@type” : “http://portal.bt-hypercat.com/ontologies/bt-hypercat#EventStream”,
“http://portal.bt-hypercat.com/ontologies/hypercat#lastUpdated” : {
“@type”:”http://www.w3.org/2001/XMLSchema#dateTime”,
“@value”: “2016-03-02T12:55:31Z”}
but it does not stop here, with the help of the ontology, it will also show the relatively items who have the same properties such as:
“@type”: “http://portal.bt-hypercat.com/ontologies/bt-hypercat#EventStream”
and same:
“http://portal.bt-hypercat.com/ontologies/bt-hypercat#belongsToEventFeed” : {
“@id”: “http://api.bt-hypercat.com/FeedID” }
with their meta-data improving the search and helping the user with easier user experience.
The implementation of the semantic search has not been tested yet in a real server because of the lack of time, but the following paradigm of the design of how a semantic search can work with a Hypercat JSON-LD based catalogue. The Mongo-DB it is used in order to perform SPARQL-like queries over JSON data and the reasoning over the ontology can be achieved using the typical reasoners Pellet and HermiT. The Hypercat JSON-LD catalogue can be stored into a MongoDB following the instructions of (Kellogg, 2012) telling that Mongo-DB can work and query perfectly with JSON-LD because MongoDB document model is a normal fit for JSON-LD. The Figure 4 shows the Semantic search workflow from the JSON to JSON-LD, then following the ontology to the reasoners additionally from the reasoners to Mongo-DB and at the end to the front-end webpage.

Figure SEQ Figure * ARABIC 4: Semantic Search Implementation’s DesignAnother paradigm of the semantic search is once the JSON-LD and the Ontology pass from the reasoner the JSON-LD will be stored into the Mongo-DB and will stay there to be queried. There will be no more reasoning after the first time because then it will get all the details and information from the subclass hierarchy. In addition, when a user gives a query then the query will go only to the database and then return with the results in the front-end webpage. Thus, for a given query where the user searches for all of the Datastreams into the catalogue, the Semantic search through Mongo-DB it returns not only the directed Datastreams but all of the derived Datastreams (through reasoning), such as SensorStream and EventStream.
Chapter 6ConclusionIn this work, it has been presented a semantic enrichment of the Hypercat specification, which allows the definition of a JSON-LD based catalogue. Moreover, it was showed how existing JSON-based catalogues can be translated into JSON-LD based catalogues in an automated fashion. It is worth noting that, the Hypercat system its written in JSON language so it is easier for a JSON developer to assimilate and translate or even create the catalogue to JSON-LD and having all the semantic features, instead of translating it to any other language. The challenge was to create a Semantic Hypercat system which has the ability of high interoperability, without losing everything from the main Hypercat specification and JSON syntax. Additionally, to enchase the catalogues with semantic search and to complete the whole translation from a JSON-based catalogue to JSON-LD based catalogue with the minimum requirements, such as removing the ‘context’ from the JSON-LD and develop the catalogue in a more extended form. In future work, there is a plan to standardize the Hypercat JSON-LD specification by working closely with the Hypercat community. Furthermore, there will be an intention to collaborate with existing partners in order to provide a publicly available converter from JSON-based to JSON-LD based catalogues. There will be also an implementation of the Semantic search mechanism with real IoT data in a real Datahub. In this way, rich Hypercat catalogues will provide a high degree of interoperability.

ReferencesAntoniou, G. & Harmelen, F. v. (2004). Web Ontology Language: OWL. 67-92.

Antoniou, G. & Harmelen, F. v. (2008). A semantic web primer (2nd ed.). Cambridge, Mass: MIT Press.

Beart, P. (2016). Hypercat 3.00 Specification.

d’Aquin, M., Adamou, A., Daga, E., Liu, S., Thomas, K., & Motta, E. (2014). Dealing with Diversity in a Smart-City Datahub. 68-82.

Davies, J. & Fisher, M. (2015). Internet of things – Why now?. 9. 35-42.

Gubbi, J., Buyya, R., Marusic, S. & Palaniswami, M. (2013). Internet of things (IoT): A vision, architectural elements, and future directions. Future Generation Comp. Syst., 29(7), 1645-1660.

JSON. (N/A). Introducing JSON . Retrieved from http://www.json.org/.

Kellogg, G. (2012). JSON-LD and MongoDB, NoSQL Now! 2012, San Jose, CA, USA. Retrieved from https://www.slideshare.net/gkellogg1/jsonld-and-mongodb.
Lanthaler, M. & Gült, C. (2012). On Using JSON-LD to Create Evolvable RESTful Services. In Proceedings of the Third International Workshop on RESTful Design, Lyon, France, Retrieved from https://json-ld.org/learn.html.

Lecue, F., Tucker, R., Bicer, V., Tommasi, P., Tallevi-Diotallevi, S., & Sbodio, M,L.(2014). Predicting Severity of Road Traffic Congestion Using Semantic Web technologies. 611-627.

Sporny, M. (2014, January 21). JSON-LD and Why I Hate the Semantic Web Web log post. Retrieved from http://manu.sporny.org/2014/json-ld-origins-2/.

Tachmazidis, I., Davies, J., Batsakis, S., Antoniou, G., Duke, A., & Stincic Clarke, S. (2016). Hypercat RDF: Semantic Enrichment for IoT.

Tachmazidis, I., Davies, J., Batsakis, S., Antoniou, G., Duke, A., & Stincic Clarke, S. (2017). A Hypercat-enabled Semantic Internet of Things Data Hub: Technical Report.

W3C. (2012). OWL 2 Web Ontology Language Document Overview (Second Edition). Retrieved from https://www.w3.org/TR/owl2-overview/.

x

Hi!
I'm Dora

Would you like to get a custom essay? How about receiving a customized one?

Check it out
x

Hi!
I'm Barry!

Would you like to get a custom essay? How about receiving a customized one?

Check it out