An Approach to Support Data Integrity for Web ServicesUsing Semantic RESTful Interfaces

Hermano AlbuquerqueLira

SERPROAv. Pontes Vieira, 832,

CEP 60.130-240Fortaleza, CE, Brasil

hermano.lira@serpro.gov.br

José Renato VillelaDantasSERPRO

Av. Pontes Vieira, 832,CEP 60.130-240

Fortaleza, CE, Brasiljose.dantas@serpro.gov.br

Bruno de Azevedo MunizUniversity of Fortaleza

Av. Washington Soares, 1321J-30, CEP 60.811-341Fortaleza, CE, Brasil

brunoamuniz@gmail.com

Tadeu Matos NunesUniversity of Fortaleza

Av. Washington Soares, 1321J-30, CEP 60.811-341Fortaleza, CE, Brasil

tadeu.matos@gmail.com

Pedro Porfírio MunizFarias

University of FortalezaAv. Washington Soares, 1321

J-30, CEP 60.811-341Fortaleza, CE, Brasilporfirio@unifor.br

ABSTRACTIn the Web, linked data is growing rapidly due to its poten-tial to facilitate data retrieval and data integration. At thesame time, relational database systems store a vast amountof data published on the Web. Current linked data in theWeb is mainly read only. It allows for integration, naviga-tion, and consultations in large structured datasets, but itstill lacks a general concept for reading and writing. This pa-per proposes a specification, entitled Semantic Data Services(SDS), for RESTful Web services that provide data access.To provide linked data read-write capacity, SDS proposes amechanism for integrity checking that is analogous to thatused in relational databases. SDS implements the SemanticRestful Interface (SERIN) specification. SERIN uses anno-tations on classes in an ontology, describing the semanticweb services that are available to manipulate data. Thiswork extends SERIN specification adding annotations to al-low the adoption of data access integrity constraints.

Categories and Subject DescriptorsD.2.12 [SOFTWARE ENGINEERING]: Interoperabi-lity—Interface definition languages

Keywordssemantic web; linked data; RESTful semantic web service;semantic data service; SERIN

Copyright is held by the International World Wide Web Conference Com-mittee (IW3C2). IW3C2 reserves the right to provide a hyperlink to theauthor’s site if the Material is used in electronic media.WWW 2015 Companion, May 18–22, 2015, Florence, Italy.ACM 978-1-4503-3473-0/15/05.http://dx.doi.org/10.1145/2740908.2743042.

1. INTRODUCTIONIn the Web, linked data is growing rapidly due to its po-

tential to facilitate the data retrieval and the data integra-tion. At the moment, linked data is mostly read-only in theWeb[3]. While linked data allows integration, navigation,and large structured dataset query, it still lacks a generalconcept for data reading and writing. Garrote[6] states thatthe lack of support for data writing to the linked data repo-sitories imposes barriers to the adoption of this technology.

At the same time, relational database systems store a vastamount of structured relational data. To make this hugeamount of relational data available to the Web of data, it isnecessary to develop mechanisms to facilitate the exchangebetween relational databases (RDB) and the Web of Data.

In this scenario, several works provides APIs or systemsto map linked data formats to relational model formats.Mainly these APIs provides read access to data, stored inrelational database, in order to publish them on the Web.Few works describe read-write implementations with abilityto update information from Web in relational databases.

Part of the difficulty in integrating the Web of data withrelational databases is due to the use of differing assumpti-ons. The Web of data languages, like OWL and RDF, adoptsthe Open World Assumption (OWA) and the “not unique”designators. OWA makes the Web of data more open withless integrity constraints. On the other hand, relational da-tabases adopts the Closed World Assumption (CWA) andthe unique designators. These assumptions make relationaldatabase subject to strict rules of data integrity constraints.

In order to motivate our work, we imagine a scenariowhere several software agents, acting as clients, desire toinsert or update data in a server database. These agents areexternal to the server. All of them, clients and server, existon the Web. Lots of systems may fit this scenario as, forexample:

• On a e-commerce scenario where a client agent havethe task to buy a product with minimal human in-tervention. The agent must be able to identify which

1485

servers have the desired product, and to insert an orderin the chosen server database;

• On a government acquisition scenario, suppliers in-terested in selling their product automatically inserttheir proposals to the government base;

• A project manager needs to organize his team agen-das. For this, he wants a software agent with abilityto identify available dates for all team components andinsert/update some schedules.

On all these insert/update scenarios, it is desirable thatthe clients sends the data according to the data model adop-ted by the server. Moreover it is important that the dataattends to some integrity constraints considering that thedatabase follows a closed world assumption.

Considering the difficulties to mix both models, Web ofdata and relational databases, this paper proposes a spe-cification, entitled Semantic Data Services (SDS), for buil-ding RESTful Web services to provide data access. SDSadopts the local closed world assumption[10, 11] to overcomethe problem about differences between OWA and CWA.To provide a capacity for reading and for writing linkeddata, SDS proposes a mechanism for checking integrity cons-traints. This mechanism is analogous to those ones used inrelational databases.

Semantic data services are concrete implementations thatfollow the abstract SERIN semantic interfaces specification.SERIN (Semantic Restful Interfaces)[14] is an annotated on-tology whose classes and properties describe resources avai-lable in the Web. SERIN formally describes semantic Webservices that provide such resources. It makes use of anno-tations in ontology concepts (classes and properties). Theannotations specify the semantic web services that are avai-lable to manipulate any data resource in a data provider.

The present work proposes the inclusion of new annota-tions in SERIN specification to enable the adoption of in-tegrity constraints when accessing such data. These anno-tations formally describe which constraints an agent mustdeal with when it sends a request to manipulate data. Inturn, a data provider that follows SERIN specification mayimplements constraint checks in the services they provide.

This article is structured as follow: Section 2 presents ourmotivation and the background for this work. Section 3 pre-sents the proposal of semantic data services (SDS). Section4 outlines the constraint mechanism of data integrity ser-vices developed for semantic data. Section 5 presents fewexample scenarios where it is possible to apply the integrityconstraints. At least, section 6 gather the conclusions andproposals for future studies.

2. BACKGROUND AND MOTIVATIONThe main motivation for our work is the necessity to pro-

vide resources for a read-write linked data on the Web. Ourfocus is to define integrity constraints treatment for linkeddata access. A motivation scenario considers the existenceof a client software agent that is responsible to execute somejob. Some tasks, to get the job done, must insert or updatedata in a external host database on the Web. To ensure thatthe information is inserted in a useful and reliable way, thehost must check some constraints.

One difficulty in integrating Web of data with relationaldatabases is due to the use of differing assumptions. The

Web of Data utilizes the open-world assumption (OWA)while relational databases uses the closed-world assumption(CWA) subordinated to strict rules of integrity constraints.

Next subsections, we discuss this two aspects, i.e., read-write linked data and the differences between OWA andCWA.

2.1 Read-write linked dataLinked Data [7] refers a set of interrelated datasets on

the Web that is available in a standard format, managedby semantic tools. Four basic principles summarize thesepractices [2]:

1. Use URIs (Universal Resource Identification) as namesfor resources;

2. Use HTTP URIs so anyone can look up those names;

3. Provide useful information, using standards, when so-meone look up a URI;

4. Using links to other URIs so it is possible to find moreresources.

The adoption of linked data has advantages for data in-tegration and data retrieval on the Web. A dataset canintegrate data from different hosts using RDF and semanticmechanisms. In this sense, one can imagine the Web of dataas a large database [7].

Current linked data on the Web is mainly a read-onlydata. There is still the need for a general concept for readingand writing on the Web of Data. The lack of support forwriting to the linked data repositories imposes barriers tothe adoption of this technology.

Some proposals implement mechanisms to allow linkeddata reading and writing. Few good examples are LinkedData Basic Profile, Linked Data Platform, and oData. Nellyet al. [16] proposed Linked Data Basic Profile 1.0. This spe-cification adopts the four principles for linked data. It ex-tends them to be compatible with the REST architecturalstyle. For its turn, W3C created Linked Data Platform[18]as a standard to define a RESTful way to read and writelinked data. At last, Kirchhoff and Geihs proposes oData[9] as a data access protocol based on REST principles.

Despite all these services works fine in supply read-writeaccess to RDF and linked data, they still lack in provide in-tegrity constraints verification. In fact oData provides inte-grity constraints checking but it does not necessarily adoptsan ontology to describe the data schema.

2.2 Local Closed World AssumptionIn the closed world assumption, typically found in rela-

tional database systems, we consider that one single hostcontains all data, even if it adopts a distributed scheme. AData Definition Language (DDL) syntactically describes thedata schema. As DBAs and programmers are human agentsand non-software agent it is unnecessary to use a formalsemantic description of the data. System documentationsemantically describes the data schema for human readers.

In this context, an unique designator identifies each re-cord. Different designators are semantically mapped intodifferent objects in the real world. This architecture adoptsthe close world assumption. This assumption considers thatall objects in the domain are known. It allows users to expli-citly represent only positive facts. Information is considered

1486

false if it is not available in the database and if the factsavailable can not prove it [4].

Open world assumption states that the datasets that arenot present in a knowledge base and that can not be de-ducted as a logical consequence of the present data are notconsidered false, but unknown. This assumption matchesthe semantics traditionally used in first-order logic and theopen architecture typically used in the Web Linked DataWeb [7].

Ontologies normally do not work as database schema be-cause ontologies intend to be consistent but not complete.They specify classes, possibly incomplete, but may also con-tain instances. Thus, there is no clear distinction betweenthe data schema, or metadata, and the data itself. Themain focus of ontologies is to maintain logical consistencythat allows inferences.

These characteristics lead to significant challenges for dataintegration existing in more than one host. Some systemstry to bypass the data integration problem with a mappingamong different ontologies used by different hosts. Thesemappings are usually partial and inaccurate.

To overcome the differences between OWA and CWA, ourwork adopts the Local Closed World Assumption (LCWA)[11]. It meets our desirable open data scenario with severalhosts that operate their data in a closed world. Each hosthas its own particular dataset that can be queried to forma broader set of information.

In this scenario, we consider a composite network whereseveral hosts offer RESTful web services for data access anda set of clients that can manipulate these resources. Thesame semantic interface describes these features. Figure 1illustrates this scenario. It shows three servers, each onewith its own data following the same semantic classes definedin the interface.

Figure 1: Semantic Interfaces approach

We assume that each host has a complete knowledge aboutits own resources. Locally, for each host, it is a closed worldassumption, i.e., the resources that are not present for thathost are allegedly false. On the other hand, for clients whoaccess the resources, the world is considered open because

there will always exist hosts that are not known for a parti-cular client.

3. SEMANTIC DATA SERVICESThe present work defines the term “Data Services” as ac-

cess points to data sources through Web services. The maincharacteristic of data services is the data manipulation th-rough CRUD (Create, Read, Update and Delete) operations.Besides these, the data services does not perform any otherdata computing operation. These services act as data ac-cess layers, allowing abstracting data sources maintained byservers. Thus, an external agent can call these services toperform operations over their data.

In this work, we propose the adoption of Semantic DataServices (SDS). SDS are RESTful [5] web services endpointsto access linked data. They are described by SERIN[15]semantic interfaces.

A Semantic RESTful Interface (SERIN) is an annotatedontology, written in OWL[1]. Its classes and properties se-mantically describe resources and services available on ahost. Four annotation types can be added to the ontology:GET, POST, PUT, and DELETE. These annotations indi-cate the RESTful Web services that a host must implementfor each resource. A resource from a class with four anno-tations must thus implement a Web service to perform anoperation for each annotation.

SERIN interfaces have four essentials characteristics whichare the basis to SDS:

• Use of RDF (Resource Description Framework) [12]instances - SDS and its clients exchange these instancesthrough a valid RDF document containing one or moreinstances.

• Use of annotations for data manipulation - A set ofannotations, applied to the classes defined in SERINinterface, defines the operations for insertion, updateand removal of instances on a semantic data service.There are four types of annotations: GET, POST,PUT, and DELETE, mapped in the four correspon-ding HTTP verbs.

• Addressing convention - URIs follow a pattern that canrepresent three types of resources: a instance, a set ofinstances, or a property value.

• Separation between shared knowledge (abstract seman-tic interface) and particular instances within each host- The SERIN interfaces defines classes and instances.They are global constants, whose semantics is sharedwith hosts and clients. Though each host has its ownparticular resource base, which are instances of theinterface classes. Any client that adopts SERIN inter-faces may change these resources.

SERIN addressing convention defines a pattern to Webservices URLs. This pattern divides each URL into twoparts. The first part identifies the host. The second partidentifies the resource that the semantic interface describes.The basic format for a SERIN address is

http://{host URL}/{interface URI}/

{class name}/{resource URI}

where:

1487

• {host URL} - host address.

• {interface URI} - ontology URI, that represents thesemantic interface.

• {class name} - ontology class name.

• {resource URI} - resource to be consulted.

RDF and OWL specifications are quite promising for therepresentation and integration of data. They are adheringto the open world assumption technologies. They have astrong emphasis on the inference of new information andnot on checking data integrity. This feature may not be ap-propriate for many services that need to ensure the integrityfor the data that they enter into the host. Semantic inte-grity ensures that data entered into a host accurately reflectthe allowed values, in terms of structure and content.

4. SERIN INTEGRITY CONSTRAINTSMechanisms for verifying data integrity constraints are

fundamental to the success of any CWA data centered sys-tem. These mechanisms are necessary to guarantee thatCWA axioms remains true whenever new data is inserted orupdated. In contrast, in OWA these mechanisms traditio-nally are not present.

In languages such as OWL, adherent to OWA, despitethey have expressiveness that allows to represent efficientlya data model, they can not easily be used as a schema lan-guage. By adopting the OWA, the OWL axioms are mainlyto make inferences. They are not proper to check data cons-traints. Motik [13] argues about the advantages of extendingthe semantics of OWL language features with the closedworld. These extensions help to use either OWL inferenceas to data validation.

SDS extends the annotations provided in the SERIN spe-cification. We propose the addition of six new annotations:NotNull, Unique, Id, ForeignURI, Embedded, and Internal.The first five apply to ontology properties while the latterone applies to ontology classes. The semantics of most ofthese annotations is similar to integrity constraints found inrelational databases. With these new annotations, we intendprovide a formal mechanism for integrity data validation ina SERIN interface, along the lines of LCWA.

The present work propose the adoption of six annotations:

1. NotNull - not null restriction [17] prohibits insertinga null value for a given attribute. The annotationNotNull requires an instance to have an associationbetween a nonzero value with a annotated property.The annotation NotNull contributes to support LCWAin semantic data services. It brings data as completeas a data provider desire.

2. Unique - It checks if the values associated with a givenproperty are unique within a given host. This anno-tation does not obligates the values to be explicitlydefined for the property. It only checks whether theyare single or not, if these values are set. The UNIQUEspecification defines a set of attributes for a resource,such that no two resources have the same values forthis set of attributes [17]. This annotation helps tosupport the unique name assumption in semantic dataservices. With this annotation, it is possible to infer

that two instances are distinct one from another. TheOWL language, in its current version, does not allowthis assumption [8]. To do so, it is necessary to createan explicit statement stating that two instances relate(or not) to the same individual.

3. Id - The annotation Id has a relation with the relati-onal database primary key specification. The primarykey denotes one or more attributes as the principalmeans of identifying tuples within a table [17]. No twotuples in a table may have simultaneously the samevalue in the primary key attributes.

In RDF model, every instance is a set of triplets as-sociated with the same subject. This model providesURIs to identify subjects and predicates. Inside a sin-gle host, the subject URI represents an instance iden-tifier. In this context, SDS server is responsible tocontrol the creation and the use of these URIs. Howe-ver, in scenarios where multiple hosts are considered,the RDF model does not allow to infer whether twoinstances URIs maintained in different hosts may re-present the same entity. The annotation Id allows toinfer that different instances in different hosts repre-sent the same individual. To do so, it is necessary thatboth hosts share the same SERIN interface.

4. ForeignURI - It requires the annotated property valueto be an instance of a URI maintained either insidethe host database or inside the implemented SERINinterface. URIs outside the host and URIs that notfollow the interface can not be associated with thistype of property. An attempt to insert data whichviolates this rule imposes the SDS service launch areferential integrity failure.

This annotation follows the concept of relational data-base foreign keys. Foreign keys are mechanisms for re-ferential integrity constraint that guarantees that thevalues that appear in a relationship for a given ta-ble attributes set must also appear in another relati-onship for a set of equivalent attributes from anothertable[17].

5. Internal - Its purpose is to restrict the creation of newinstances in a host database, except when they aremembers of a parent instance. The Internal annotationapplies to classes rather than properties. As it is in theentity-relationship model, instances of Internal classesare weak entities, i.e., can only exist in the database ifthey participate in a relationship with a strong entity(the parent instance).

SDS does not allow an an HTTP POST request to di-rect persist an Internal instance. The addition of anew Internal instance should occur along with its pa-rent instance, via a HTTP PUT request. It is alsopossible to add a new Internal member for a parentinstance already present in the base. A HTTP DE-LETE request can not exclude the parent instance un-less it excludes all related Internal instances. This isnecessary to maintain such consistency.

6. Embedded - The purpose of this annotation is thatwhen a GET operation requests information about anobject, it responses information about this object with

1488

other objects that have relation with the requested ob-ject. The annotation Embedded over a object propertydefines this relation. This annotation therefore allowsto relate a set of instances that should always be re-turned in a single block.

The advantage in using the annotation Embedded, isthat with just an HTTP GET request is possible toobtain all necessary instances to generate the registra-tion document. Without this annotation, on the otherhand, several HTTP GET requests must be performed,one for each instance necessary to make the registra-tion document. The annotation Embedded allows tocombine instances in order to obtain a finer granularityrepresentation.

The main characteristic for the presented annotations is tovalidate incoming data in a semantic data service. This me-ans that whenever a data writing request (HTTP methodsPOST, PUT, or DELETE) is executed, the service mustcheck the integrity constraints.

5. INTEGRITY CHECKING TEST CASETo clearly illustrate the relevance of semantic data services

(SDS), it is necessary to contextualize a scenario where thereis a strong demand for linked data, and at the same time, animplicit need for these data are as complete and consistentas possible.

As an example scenario, let us suppose the following sce-nario: a software agent needs to automatically apply for agovernment acquisition. It needs to insert its proposal in thegovernment server database. Some basic information mustbe checked before the server saves the data.

At first, both server and client must agree about what datamay be inserted. The acquisition.owl defines the data mo-del. This ontology defines classes and properties to describethe concepts Company and Sell Proposal, among others notshown here. The classes and properties described bellow arejust part of the full model, not present here due to spacerestrictions.

Listing 1: Example of acquisiton.owl ontology clas-ses with SERIN annotations.<owl : Class rd f : about=”#Company”>

<s e r i n : get/><s e r i n : put/><s e r i n : post/>

</owl : Class>

<owl : Class rd f : about=”#S e l l P r o p o s a l ”><s e r i n : get/><s e r i n : put/><s e r i n : post/>

</owl : Class>

The acquisition ontology classes shown in listing 1 has re-ceived SERIN annotations that indicates possible operationsfor classes. The classes Company and SellProposal haveannotations indicating that is possible to send only HTTPGET, PUT, and POST requests. Note that is is not possi-ble to send DELETE requests since this annotation is notpresent on these classes definition.

The ontology section shown in listing 2 presents some in-tegrity constraint definitions for some properties. The classCompany is a domain for the properties registryNum-ber and name, each one with it own constraint annotati-ons. Also property hasCompany indicates a relationship,with a constraint, between Company and SellProposal.

Listing 2: Example of properties with integrity cons-traints annotations.<owl : DatatypeProperty

rd f : about=”#registryNumber”><s e r i n : id/><r d f s : domain rd f : r e s ou r c e=”#Company”/><r d f s : range rd f : r e s ou r c e=”&xsd ; s t r i n g ”/></owl : DatatypeProperty>

<owl : DatatypeProperty rd f : about=”#name”><s e r i n : notNul l/><r d f s : domain rd f : r e s ou r c e=”#Company”/><r d f s : range rd f : r e s ou r c e=”&xsd ; i n t e g e r ”/></owl : DatatypeProperty>

<owl : ObjectPropertyrd f : about=”#hasCompany”>

<s e r i n : fore ignURI/><r d f s : domain

rd f : r e s ou r c e=”#S e l l P r o p o s a l ”/><r d f s : range rd f : r e s ou r c e=”#Company”/></owl : ObjectProperty>

In this definition, a company registration number must beunique so it identifies the company. In this model, no othercompany can have the same id. The id may have a close anddirect relationship with a company URI.

The property name, also related to the class Company,has a notNull annotation. This indicates that all Companyinstances must have a value for the property name. Thisvalue does not need to be unique but it must exist.

The property hasCompany indicates the existence of arelationship between Company and SellProposal. The addi-tion of a SERIN annotation foreignURI states that theserelationship must be explicit defined in the database. Soevery SellProposal instance must have an association to aCompany instance, otherwise it violates this constraint.

As a last example, listing 3 shows an ontology sectionwith an example of annotation Embedded. The existenceof an annotation Embedded in the relationship betweenSellProposal and Product indicates that once a client re-quest SellProposal instance data, it receives together theProduct instances associated to the SellProposal instance.The advantage about this operation is that a client does notneed to send requests to receive information about each Pro-duct associated to a SellProposal. It is possible to receiveSellProposal and its products with only one request.

Based on this ontology, a host can implements the inte-grity constraint verification for every request it receives fromeach client agent. In this work, the OWL language was notexpanded to support integrity constraints checking. Thisstudy is subject of future work. For now, hosts that imple-ments the semantic interface can build algorithms for inte-grity constraints checking inside the web services methods.The algorithms should be developed also considering non-functional requirements.

1489

Listing 3: Example of a property with annotationEmbedded.<owl : ObjectProperty

rd f : about=”#hasProduct”><s e r i n : embedded/><r d f s : domain

rd f : r e s ou r c e=”#S e l l P r o p o s a l ”/><r d f s : range rd f : r e s ou r c e=”#Product”/>

</owl : ObjectProperty>

For its turn, when it needs to insert/update data in a host,the client agent can send the request with correct informa-tion because the data schema is already known. This cancontribute to improve performance requirements.

6. CONCLUSIONSThis article describes an approach to provide integrity

constraints to semantic data services. This approach adhe-res to the local closed world assumption.

This proposal is a step towards building a web of inter-connected data that is available for writing. It allows clientsto persist data in hosts databases without violating the es-tablished integrity constraints.

We have introduced a set of new annotations reachingthose used in the semantic interfaces that describe the se-mantic data services. These annotations provide an integrityconstraint analogous to the constraints found in relationaldata models. This mechanism allows SDS to validate thedata that they process.

Our implementation for this proposal 1 uses Java languageand the Jena framework. This implementation was evalua-ted against other data service proposals. Some related worksuse the closed world assumption without adopting semanticWeb standards. Other proposals have adhered to the Se-mantic Web but they still presents some challenges regar-ding the data write permission to the web services clients.SDS fills some gaps observed in these studies.

As future work, we intend to include a mechanism for ac-cess permission for data writing. Other possible studies are:the construction of data access concurrency control; transac-tion control; and the definition of URIs to run parameterizedqueries, e.g. paging and selection filters.

7. ACKNOWLEDGMENTSThe authors would like to thank SERPRO, Federal Data

Processing Service, for supporting this research.

8. REFERENCES[1] S. Bechhofer, F. van Harmelen, J. Hendler,

I. Horrocks, D. L. McGuinness, P. F. Patel-Schneider,and L. A. Stein. OWL Web Ontology LanguageReference, 2004.

[2] T. Berners-Lee. Linked Data - Design Issues, 2006.

[3] T. Berners-lee, R. Cyganiak, M. Hausenblas,J. Presbrey, O. Seneviratne, and O.-e. Ureche.Realising A Read-Write Web of Data. Technicalreport, 2009.

1An working example may be seen at http://opendataserin-unifor.rhcloud.com/.

[4] K. L. Clark. Negation as Failure. In H. Gallaire andJ. Minker, editors, Logic and Data Bases, pages292–322, New York, 1978. Plenum Press.

[5] R. T. Fielding. Architectural styles and the design ofnetwork-based software architectures. PhD thesis,University of California, Irvine, 2000.

[6] A. Garrote and M. N. M. Garcıa. RESTful writableAPIs for the web of Linked Data using relationalstorage solutions. In In WWW2011 Workshop: LinkedData on the Web (LDOW2011, 2011.

[7] T. Heath and C. Bizer. Linked Data: Evolving theWeb into a Global Data Space. Synthesis Lectures onthe Semantic Web. Morgan {&} Claypool Publishers,2011.

[8] P. Hitzler, M. Krotzsch, B. Parsia, P. F.Patel-Schneider, and S. Rudolph. OWL 2 WebOntology Language: Primer. W3C Recommendation,2012.

[9] M. Kirchhoff and K. Geihs. Semantic description ofOData services. In Proceedings of the Fifth Workshopon Semantic Web Information Management, SWIM’13, pages 2:1—-2:8, New York, NY, USA, 2013. ACM.

[10] M. Knorr, J. J. Alferes, and P. Hitzler. Local ClosedWorld Reasoning with Description Logics Under theWell-founded Semantics. Artif. Intell.,175(9-10):1528–1554, 2011.

[11] A. Krisnadhi, K. Sengupta, and P. Hitzler. LocalClosed World Semantics : Keep it simple , stupid!Proceedings of the 24th International Workshop onDescription Logics (DL), 2011.

[12] F. Manola and E. Miller. RDF Primer, 2004.

[13] B. Motik, I. Horrocks, and U. Sattler. Bridging thegap between OWL and relational databases.Proceedings of the 16th international conference onWorld Wide Web (WWW’07), pages 807–816, 2007.

[14] B. d. A. Muniz, L. M. Chaves, H. A. Lira, J. R. V.Dantas, and P. P. M. Farias. SERIN - AN APROACHTO SPECIFY SEMANTIC ABSTRACTINTERFACES IN THE CONTEXT OF RESTFULWEB SERVICES. Proceedings of the IADISInternational Conference on WWW/Internet, pages187–194, 2013.

[15] B. D. A. Muniz, L. M. Chaves, J. C. C. Neto, J. R. V.Dantas, and P. P. M. Farias. SERIN - SEMANTICRESTFUL INTERFACES. Proceedings of the IADISInternational Conference on WWW/Internet, pages463–467, 2011.

[16] M. Nally, S. Speicher, J. Arwe, and A. L. Hors. LinkedData Basic Profile 1.0. W3C Member Submission.World Wide Web Consortium, 2012.

[17] A. Silberschatz, H. F. Korth, and S. Sudarshan.Database System Concepts. McGraw-HillScience/Engineering/Math, 5 edition, 2005.

[18] S. Speicher, J. Arwe, and A. Malhotra. Linked DataPlatform 1.0. W3C Recommendation. World WideWeb Consortium, 2014.

1490