Soft Querying GeoJSON Documents within the J-CO Framework

Giuseppe Psaila

1 a

, Stefania Marrara

2 b

and Paolo Fosci

University of Bergamo, DIGIP, Viale Marconi 5, 24044 Dalmine (BG), Italy

Cefriel, viale Sarca 226, 20126 Milano, Italy

Keywords:

GeoJSON Documents, Soft Querying of GeoJSON Documents, Fuzzy J-CO-QL Queries.

Abstract:

GeoJSON documents have become important sources of information over the Web, because they describe

geographical information layers. Supposing to have such documents stored in some JSON store, the problem

of querying them in a ﬂexible and easy way arises.

In this paper, we propose a soft-querying model to easily express queries on features (i.e., data items) within

GeoJSON documents, based on linguistic predicates. These are fuzzy predicates that evaluate the membership

degree to fuzzy sets; this way, imprecise conditions can be expressed and features can be ranked, accordingly.

The paper presents a rewriting technique that translates soft queries on GeoJSON documents into fuzzy J-

CO-QL queries: this is the query language of the J-CO Framework, an Internet-based framework able to get,

manipulate and save collections of JSON documents in a way totally independent of the source JSON store.

1 INTRODUCTION

GeoJSON

is the standard format to represent geo-

graphical layers; today, it is widely used to share

geographical information. Indeed, GeoJSON relies

on the JSON

(JavaScript Object Notation) syntax,

a simple and widely used standard that can be eas-

ily managed by any object-oriented programming lan-

guage. As a consequence, GeoJSON documents are

often found in open data portals, as well as GIS tools

import and export export GeoJSON documents.

Based on this premise, the reader may think that

managing and querying GeoJSON documents is easy,

especially due to the availability of JSON document

stores, i.e., database systems that are able to store

JSON documents without any limitation. Unfortu-

nately, this assumption is not true for several reasons:

ﬁrst of all, JSON document stores are designed to

manage a multitude of small JSON documents, while

GeoJSON documents may be very large; second, at

the moment a standard query language for JSON doc-

uments does not exist, and each document store im-

plements its own query language, forcing a user in-

terested in several GeoJSON documents stored in dif-

ferent repositories to rewrite her/his queries in every

https://orcid.org/0000-0002-9228-560X

https://orcid.org/0000-0003-2745-3539

https://geojson.org/

https://www.w3schools.com/js/js json intro.asp

speciﬁc query language; third, the query languages

provided by all JSON document stores may be inad-

equate to effectively manage the typical nested struc-

ture of GeoJSON documents; ﬁnally, all the available

languages are based on Boolean conditions that do not

help to rank single features described within GeoJ-

SON documents.

The problem of querying and manipulating JSON

documents stored within different JSON document

stores has been addressed in our previous work: the

J-CO Framework (Bordogna et al., 2017; Bordogna

et al., 2018) is the tentative answer. The framework

is designed to be an internet-based polystore frame-

work, able to connect to a multitude of heterogeneous

JSON stores distributed over the Internet; it provides

a query language, named J-CO-QL, that is indepen-

dent of the speciﬁc JSON store and provides high-

level constructs to manipulate heterogeneous collec-

tions of JSON documents (instructions can deal with

many different document structures contained in the

same collection at the same time).

With this framework, the reader may think that the

problem of querying GeoJSON documents has been

already solved. The truth is that this is “only par-

tially” true: in fact, non-trivial J-CO-QL queries must

be written to query GeoJSON documents. Further-

more, as far as soft querying GeoJSON documents

is concerned, in principle the last extension to J-CO-

QL proposed in (Psaila and Marrara, 2019), which

Psaila, G., Marrara, S. and Fosci, P.

Soft Querying GeoJSON Documents within the J-CO Framework.

DOI: 10.5220/0010155702530265

In Proceedings of the 16th International Conference on Web Information Systems and Technologies (WEBIST 2020), pages 253-265

ISBN: 978-989-758-478-7

253

has introduced constructs to evaluate fuzzy sets over

JSON documents, promises to provide this capability,

but we will see that queries become harder to write.

So, a higher-level approach is necessary, based on a

simpler soft-querying model that is speciﬁc for GeoJ-

SON documents, but indeed based on fuzzy J-CO-QL

queries, which becomes the underlying engine.

In this paper, we present a high-level soft querying

model for selecting features in GeoJSON documents,

in such a way that, given an input GeoJSON docu-

ment, the query generates a new GeoJSON document

containing only the selected features (i.e., data items

contained in the document). The adoption of linguis-

tic predicates in the soft query provides the capability

to rank features, on the basis of the membership de-

gree to fuzzy sets. The paper will show how such

“simple” soft queries can be automatically translated

into complex fuzzy J-CO-QL queries, which actually

disassemble the GeoJSON documents, apply fuzzy

querying to single features and re-assemble them into

a unique GeoJSON document, such that features are

ordered in reverse order of importance with respect to

the linguistic condition expressed in the soft query.

The remainder of the paper is organized as fol-

lows. Section 2 brieﬂy discusses relevant related

work. Section 3 presents the background of our work,

i.e., basic notions on fuzzy sets and the GeoJSON for-

mat. Section 4 introduces the main research idea of

the paper, i.e., applying soft querying to GeoJSON

documents. Section 5 shows how the J-CO-QL lan-

guage can manipulate GeoJSON documents to select

features. Then, Section 6 shows how fuzzy concepts

previously added to J-CO-QL in (Psaila and Marrara,

2019) can perform soft querying on GeoJSON docu-

ments (Sections 6.1 and 6.2), while a rewriting tech-

nique to derive fuzzy J-CO-QL queries on GeoJSON

features is presented in Section 6.3. Finally, Section 7

concludes the paper.

2 RELATED WORK

Most relational database management systems adopt

Boolean logic to formalize queries. This means that a

query condition can be either satisﬁed or not satisﬁed.

By using Boolean logic, it is not possible to have a

ﬂexible semantics of relational operations, to express

preferences and to rank query results. In many real-

world situations, queries are expressed by humans by

means of imprecise words. User’s intention is not

merely to ﬁnd the items that satisfy a given query;

in contrast, the user may wish to estimate how much

each item satisﬁes the conditions in the query (its sat-

isfaction degree), in order to rank items (if possible).

There are several approaches to represent impre-

cise and vague concepts in Information Retrieval (IR).

A ﬁrst approach deﬁnes similarity or proximity rela-

tions between pairs of imprecise and vague items. In

the Vector Space Model, for instance, documents and

queries are represented as points in a space of terms

and the distances between the points representing the

query and the documents are used to quantify their

similarity (Salton et al., 1994). Another category of

approaches adopts the notion of Fuzzy Set. Fuzzy Set

Theory is an extension to classical set theory (Zadeh,

1975). The notion of fuzzy set has been used to repre-

sent vague concepts expressed in a ﬂexible query for

specifying soft selection conditions (Blair, 1979). The

objective here is to quantify the closeness of the in-

formation carried by the proposition with the consid-

ered reality. Possibility Theory (Fuhr, 1989; Zadeh,

1965) together with the concept of linguistic variable

deﬁned within fuzzy set theory (Zadeh, 1975), pro-

vides a complete formal framework to manage impre-

cise, vague and uncertain information (Buell, 1985).

There are two alternative ways to model the re-

trieval activity. (i) One possibility is to model the

query evaluation mechanism as an uncertain decision

process. The concept of relevance is deﬁned as a

binary (crisp) condition, since the query evaluation

mechanism computes relevance probability of a doc-

ument d with respect to a query q. Such an approach,

which does model the uncertainty of the retrieval pro-

cess, has been introduced and developed by using

probabilistic IR models (Ramer, 1989; Herrera and

Herrera-Viedma, 1997; Waller and Kraft, 1979). (ii)

Another way is to interpret the query as the speci-

ﬁcation of soft constraints that the representation of

a document can satisfy to a certain degree, and to

consider term relevance as a gradual (vague) concept.

This is the approach adopted in fuzzy IR models (Bor-

dogna and Pasi, 1995). In this latter case, the decision

process performed by the query evaluation mecha-

nism computes the degree with which the query is sat-

isﬁed by the representation of each document. A very

good survey regarding the adoption of Fuzzy Sets in

IR can be found in (Kraft et al., 2015).

A well deﬁned context, in which dealing with un-

certainty and vagueness is quite common, is XML

Retrieval. When deﬁning query languages for XML

documents, the problem of querying data collections

without a well-deﬁned structure, or with a heteroge-

neous structure, was soon evident.

To tackle this problem, Fuzzy Set Theory was

a fairly immediate choice. In (Damiani and Tanca,

2000) the authors presented an approach in which

XML documents are modeled as labeled graphs; their

structure is selectively extended by computing the im-

WEBIST 2020 - 16th International Conference on Web Information Systems and Technologies

254

portance of the information carried by tags as fuzzy

estimates. The results of such an extension are fuzzy

labeled graphs. Query results are sub-graphs of these

fuzzy labeled graphs, presented as a ranked list ac-

cording to their matching degree with respect to the

query.

In a different perspective, the approaches pre-

sented in (Campi et al., 2009; Marrara and Pasi, 2016)

propose ﬂexible XML selection languages, which al-

low for formulating ﬂexible constraints on both struc-

ture and content of XML documents. This way, users

can formulate queries that are able to retrieve XML

documents that provide information close to users’

needs.

According to many research papers (Kacprzyk

and Zadro

zny, 1995; Medina et al., 1994) there are

two main ways to apply Fuzzy Set Theory in the con-

text of database management systems. The ﬁrst way

consists in developing a fuzzy database model to man-

age imprecise relational data (Bosc and Prade, 1997)

The second way develops a fuzzy querying inter-

face on top of a conventional relational database: the

advantage of this approach is evident in the SoftSQL

proposal (Bordogna and Psaila, 2009). Other exten-

sions of SQL have been proposed: FSQL (Galindo

et al., 2006) and SQLf (Bosc and Pivert, 1995).

3 BACKGROUND

This section presents the relevant background on

which the paper relies.

3.1 A Brief Introduction on Fuzzy Sets

Fuzzy Set Theory was introduced by Zadeh (Zadeh,

1975), and soon proved its potentiality, since it was

successfully applied to different areas, such as arti-

ﬁcial intelligence, natural language processing, deci-

sion making, expert systems, neural networks, control

theory, and so on. Let us denote by X a non-empty

universe, either ﬁnite or inﬁnite.

Deﬁnition 1. A fuzzy set (or type-1 fuzzy set) A ⊆ X is

a mapping A : X → [0, 1]. The value A(x) is referred

to as the membership degree of the element x to the

fuzzy set A.

Therefore, a fuzzy set A in X is characterized by

a membership function A(x) that associates each ele-

ment x ∈ X with a real number in the interval [0, 1];

in other words, given x, the value A(x) represents the

degree of membership of x to A.

A fuzzy set is empty if and only if its membership

function is identically zero for each x ∈ X. Two fuzzy

sets A and B are equal, denoted as A = B, if and only

if A(x) = B(x) for all x ∈ X.

The complement of a fuzzy set A is A

and is deﬁned

as A

(x) = 1 − A(x).

As in the case of ordinary sets, the notion of contain-

ment can be deﬁned as well.

Deﬁnition 2. A is contained in B (or, equivalently, A

is a subset of B, or A is smaller than or equal to B) if

and only if A(x) ≤ B(x), for each x ∈ X.

Deﬁnition 3. The union (resp. intersection) of two

fuzzy sets A and B with respective membership func-

tions A(x) and B(x) is a fuzzy set C, written as C = A∪

B (resp., C = A∩B), whose membership function is re-

lated to those of A and B by C(x) = Max(A(x), B(x))

(resp., C(x) = Min(A(x), B(x))), for all x ∈ X.

The union (resp., intersection) is used to express the

logical OR (resp. AND) operators, while the comple-

ment set represents the logical NOT operator.

3.2 The GeoJSON Format

GeoJSON (Butler et al., 2016) is a format for encod-

ing geographic information layers, deﬁned by using

the JSON format. With a GeoJSON document, we

can represent a region of space (i.e., a Geometry), a

spatially bounded entity (i.e., a Feature), or a list of

Features (i.e., a FeatureCollection).

GeoJSON supports several geometry types: Point,

LineString, Polygon, MultiPoint, MultiLineString,

MultiPolygon, and GeometryCollection. Features in

GeoJSON are composed by a geometry ﬁeld plus

additional properties described by the properties

ﬁeld. The overall GeoJSON document is of type

FeatureCollection, and the array ﬁeld named

features contains a list of features.

An example of GeoJSON document is reported in

Listing 1. Features, that are contained in the fea-

tures array ﬁeld, describe weather measures, made

by weather stations located in Regione Lombardia

(Northern Italy). Each feature describes the station

identiﬁer, the date of measure, the temperature (in de-

gree Celsius), the percentage of humidity and the at-

mospheric pressure in millibars.

4 SOFT QUERYING ON GeoJSON

Consider the GeoJSON document reported in List-

ing 1. With soft querying of a GeoJSON document

we mean searching for features that meet a qualitative

condition, in order to get a new GeoJSON document,

Soft Querying GeoJSON Documents within the J-CO Framework

255

Listing 1: Sample GeoJSON Document.

{ "type": "FeatureCollection",

"features": [

{ "type": "Feature",

"properties": {

"Station_Id": 109,

"Date": "2020-05-01",

"temperature": 26,

"humidity": 83,

"pressure": 1000

"geometry": {

"type": "Point",

"coordinates":

[9.379659683,45.26066732]

}

{ "type": "Feature",

"properties": {

"Station_Id": 114,

"Date": "2020-05-01",

"temperature": 24,

"humidity": 99,

"pressure": 980

"geometry": {

"type": "Point",

"coordinates":

[9.267153115,45.32059361]

}

{ "type": "Feature",

"properties": {

"Station_Id": 117,

"Date": "2020-05-01",

"temperature": 17,

"humidity": 81,

"pressure": 874

"geometry": {

"type": "Point",

"coordinates":

[10.33339294, 46.17572375]

}

]

}

in which features are sorted in reverse order of impor-

tance (as far as the qualitative selection condition is

concerned).

A sample qualitative query may be: extract those

meteorological measures (features) that registered a

high value of humidity with either a low value of tem-

perature or a medium value of pressure or both.

To explain the idea, suppose we can express

three linguistic predicates, i.e., High Humidity,

Low Temperature and Medium Pressure.

By using a SQL-like syntax, the soft query may be

expressed as reported in Listing 2.

Listing 2: Soft query in SQL-like syntax.

SELECT *

FROM Meteo_Measures

WHERE High_Humidity AND

(Low_Temperature OR Medium_Pressure)

FOR FUZZY SET Wanted

ALPHA-CUT Wanted: 0.5

ADD MEMBERSHIP OF Wanted AS rank

The idea is the following: if we are able to evalu-

ate the three linguistic predicates on each feature, we

can evaluate a compound Wanted linguistic predi-

cate; the membership value associated to this linguis-

tic predicate denotes the degree with which the sin-

gle feature matches the compound linguistic condi-

tion. Let us describe our idea in details.

• The FROM clause speciﬁes the source GeoJSON

document.

• The WHERE clause speciﬁes the compound lin-

guistic condition, by evaluating the membership

degree for each single feature.

The last part of the clause, i.e., FOR FUZZY

SET Wanted, gives a name to the fuzzy set ob-

tained by evaluating the compound linguistic con-

dition.

• The SELECT clause speciﬁes the properties of the

feature to project on.

• The ALPHA-CUT clause selects only those fea-

tures that belong to the Wanted fuzzy set with

membership degree greater than or equal to 0.5.

• ADD MEMBERSHIP OF Wanted AS rank

speciﬁes that the membership value of the

Wanted fuzzy set becomes a new property in

features, whose name is rank; implicitly, we

assume that the features are sorted by the rank

properties in descending order.

We now present our semantic model.

• Each feature can have a pool of associated fuzzy

sets; the memberships degree for each fuzzy set

denotes the degree with which the feature belongs

to the fuzzy set. Formally, the data model for a

feature is:

f = hproperties, geometry, fuzzysetsi

where properties and geometry are de-

ﬁned exactly as in the GeoJSON standard; The

fuzzysets ﬁeld is a key/value map, that asso-

ciates a fuzzy set name f sn to the membership de-

gree of f to the fuzzy set f sn.

• The WHERE clause evaluates a soft condition,

computes the membership degree and adds the

new fuzzy set name and the computed member-

ship degree to the map f .fuzzysets.

WEBIST 2020 - 16th International Conference on Web Information Systems and Technologies

256

Clearly, linguistic predicates can be interpreted in

terms of fuzzy sets, i.e., the satisfaction degree of a

linguistic predicate corresponds to the membership

degree to a fuzzy set. So, the previous soft query is

correct only if we guess that the features in the source

GeoJSON document have membership degrees to the

fuzzy sets High Humidity, LowTemperature

and Medium Pressure already computed. How-

ever, this is not true in GeoJSON documents: so, we

can assume that their membership degree is 0 (as a

standard behavior, we can assume that when a fuzzy

set name f sn 6∈ f .fuzzysets, its membership de-

gree is 0). Thus, the previous soft query is correct,

but would not select any feature.

Consequently, we have to extend our proposal and

consider that:

1. fuzzy operators for evaluating membership de-

grees are available;

2. the FROM clause must accept nested soft queries.

Based on the above-mentioned consid-

erations, and supposing that three fuzzy

operators named Has High Humidity,

Has Low Temperature and

Has Medium Pressure are deﬁned, the soft

query can be written as reported in Listing 3.

Listing 3: Nested soft query in SQL-like syntax.

SELECT *

FROM (SELECT *

FROM Meteo_Measures

WHERE Has_High_Humidity(humidity)

FOR FUZZY SET High_Humidity

)

WHERE Has_Low_Temperature(temperature)

FOR FUZZY SET Low_Temperature

)

WHERE Has_Medium_Pressure(pressure)

FOR FUZZY SET Medium_Pressure

)

WHERE High_Humidity AND

(Low_Temperature OR Medium_Pressure)

FOR FUZZY SET Wanted

ALPHA-CUT Wanted: 0.5

ADD MEMBERSHIP OF Wanted AS rank

Consequently, the problem we address in this pa-

per can be formulated as follows

Problem 1. Given a soft query sq on a GeoJSON

document, rewrite the query into a lower-level fuzzy

query language for JSON data sets, that generates a

new GeoJSON document containing only the features

that satisfy the soft condition, sorted by the member-

ship degree in reverse order.

5 QUERYING GeoJSON

FEATURES WITH J-CO-QL

The J-CO-QL language is a rich language to query

and transform collections of complex JSON docu-

ments. Here, we show how it can be used to select

features in GeoJSON documents. This way, we will

brieﬂy introduce the language (the reader can refer to

(Bordogna et al., 2017; Bordogna et al., 2018; Psaila

and Fosci, 2018)) and what it is possible to do with-

out using fuzzy constructs, that will be presented in

Section 6.2.

Suppose we have a GeoJSON document that de-

scribes measures performed by weather stations (see

Listing 1), stored within a database named MyDB as

the lonely document of a collection (container of doc-

uments) named Meteo Measures. In this paper,

we do not consider how to connect the J-CO frame-

work to JSON stores (such as MongoDB); the inter-

ested reader can refer to (Psaila and Fosci, 2018).

Listing 4: J-CO-QL query that selects features from a Geo-

JSON document.

GET COLLECTION Meteo_Measures@MyDB;

EXPAND

UNPACK WITH ARRAY .features

ARRAY .features TO feature

DROP OTHERS;

FILTER

CASE WHERE WITH

.feature.item.properties.temperature

AND

.feature.item.properties.temperature

> 30

GENERATE { .type: .feature.item.type,

.properties:

.feature.item.properties,

.geometry: .feature.item.geometry,

.key: "K" }

DROP OTHERS;

GROUP

PARTITION WITH .key

BY .key INTO .features

DROP GROUPING FIELDS

GENERATE { .features: .features,

.type: "FeatureCollection" }

DROP OTHERS;

SAVE AS Filtered@MyDB;

The query in Listing 4 generates a new GeoJ-

SON document, and stores it into a database collec-

tion named Filtered. Let us discuss it.

The query contains ﬁve instructions, performing

either simple tasks or complex tasks. The underlying

Soft Querying GeoJSON Documents within the J-CO Framework

257

Listing 5: Temporary collection after the GROUP instruction

in Listing 4.

{"type" : "FeatureCollection",

"features" : [

{ "type" : "Feature",

"geometry" : {

"coordinates" :

[9.379659683, 45.26066732],

"type" : "Point"

"properties" : {

"Date" : "2020-08-01",

"Station_Id" : 109,

"humidity" : 97,

"pressure" : 750,

"temperature" : 36.7 } },

{ "type" : "Feature",

"geometry" : {

"coordinates" :

[9.267153115, 45.32059361],

"type" : "Point"

"properties" : {

"Date" : "2020-08-01",

"Station_Id" : 114,

"humidity" : 99,

"pressure" : 745,

"temperature" : 38.2 } }

]

}

semantics is the following: each instruction starts

from an Execution State s

, and produces a new execu-

tion state s

(i+1)

. Each execution state contains several

information, including also the Temporary Collection,

i.e., a collection of JSON documents that constitutes

the input of the instruction. Thus, each instruction

may use this collection and may generate a new tem-

porary collection.

We can now describe the query in Listing 4.

• The GET COLLECTION instruction retrieves the

collection named Meteo Measures from the

database named MyDB. This collection becomes

the starting temporary collection of the process.

Notice that in this case the collection is composed

by just one document.

• The EXPAND instruction selects and transforms

documents in the temporary collection generating

a new temporary collection. In this case, the UN-

PACK clause selects those documents containing

an array structure in a ﬁeld named features

and then generates new documents, each one re-

lated to each element in the features array.

Each new document has a feature ﬁeld con-

taining one of the value in the source features

array, while the other ﬁelds in the source docu-

ment remain unchanged. The ﬁnal DROP OTH-

Listing 6: Temporary collection after the EXPAND instruc-

tion in Listing 4.

{ "type" : "FeatureCollection",

"feature" : {

"item" : {

"geometry" : {

"coordinates" :

[9.379659683, 45.26066732],

"type" : "Point"},

"properties" : {

"Date" : "2020-08-01",

"Station_Id" : 109,

"humidity" : 97,

"pressure" : 750,

"temperature" : 36.7 },

"type" : "Feature" },

"position" : 0 } }

{ "type" : "FeatureCollection",

"feature" : {

"item" : {

"geometry" : {

"coordinates" :

[9.267153115, 45.32059361],

"type" : "Point" },

"properties" : {

"Date" : "2020-08-01",

"Station_Id" : 114,

"humidity" : 99,

"pressure" : 745,

"temperature" : 38.2 },

"type" : "Feature" },

"position" : 1 } }

{ "type" : "FeatureCollection",

"feature" : {

"item" : {

"geometry" : {

"coordinates" :

[10.33339294, 46.17572375],

"type" : "Point" },

"properties" : {

"Date" : "2020-08-01",

"Station_Id" : 117,

"humidity" : 81,

"pressure" : 751,

"temperature" : 17.3 },

"type" : "Feature" },

"position" : 2 } }

ERS clause, which in this case is ineffective, dis-

cards all those documents in the temporary collec-

tion that do not match the selecting condition.

Listing 6 reports the temporary collection ob-

tained by expanding the GeoJSON document re-

ported in Listing 1. Notice that each document

contains the feature ﬁeld, as speciﬁed; this

ﬁeld, in turns, contains the item ﬁeld, that ac-

tually is the previously nested document, and the

WEBIST 2020 - 16th International Conference on Web Information Systems and Technologies

258

Listing 7: Temporary collection after the FILTER instruc-

tion in Listing 4.

{ "type" : "Feature"

"key" : "K",

"geometry" : {

"coordinates" :

[9.379659683, 45.26066732],

"type" : "Point"

"properties" : {

"Date" : "2020-08-01",

"Station_Id" : 109,

"humidity" : 97,

"pressure" : 750,

"temperature" : 36.7

} }

{ "type" : "Feature"

"key" : "K",

"geometry" : {

"coordinates" :

[9.267153115, 45.32059361],

"type" : "Point"

"properties" : {

"Date" : "2020-08-01",

"Station_Id" : 114,

"humidity" : 99,

"pressure" : 745,

"temperature" : 38.2

} }

position ﬁeld, that denotes the position for-

merly occupied by the document in the array.

• The FILTER instruction selects and transforms

the documents in the temporary collection, gen-

erating a new temporary collection. In this case,

since documents describe weather measures, the

CASE WHERE clause selects documents having

the temperature ﬁeld (by means of the WITH

predicate) whose value is above 30 degrees.

The selected documents are restructured by the

GENERATE action, in order to simplify them.

Speciﬁcally, we keep out all ﬁelds inside the

.feature.item structure, generating ﬁelds at

root level as type, property and geome-

try. Moreover, an extra key ﬁeld with a con-

stant value is added. The ﬁnal DROP OTHERS

clause discards documents that are not selected by

the CASE WHERE clause.

Notice that the new temporary collection contains

two documents, as reported in Listing 7.

• The GROUP instruction creates a partition in the

temporary collection and groups the documents in

the partition into a new single document.

In this case, by means of the WITH predicate, all

documents that hold a key ﬁeld are selected to

be partitioned. By means of the BY clause, doc-

uments in the partition are grouped based on the

value of the key ﬁeld: since we have only one

constant value, all documents in the partition are

grouped into one single document.

The INTO clause speciﬁes the name of the new

array ﬁeld that has to contain grouped docu-

ments: in this case, the name is features. The

DROP GROUPING FIELDS option discards the

key ﬁeld. The GENERATE action maintains un-

changed the features ﬁeld and adds a new

type ﬁeld with "FeatureCollection" as

value.

Notice that the new temporary collection contains

one GeoJSON document, as reported in Listing 5.

• Finally, the temporary collection produced by

the GROUP instruction is saved into the MyDB

database with name Filtered.

The dot notation .features to refer to ﬁelds

is motivated by the fact that documents can contain

nested documents and ﬁelds; the dot notation allows

for referring to nested ﬁelds, for example .A.B (the

initial dots means that the A ﬁeld is in the root level).

6 SOFT QUERYING IN J-CO-QL

We can now present fuzzy J-CO-QL queries (pro-

posed in (Psaila and Marrara, 2019)), which provide

the tools to solve Problem 1.

6.1 Creating Fuzzy Operators

In order to evaluate if a document belongs to a fuzzy

set, it is necessary to deﬁne some operators able to

compute the membership degree of a document with

respect to a fuzzy set.

The fuzzy extension of the J-CO-QL language of-

fers a speciﬁc construct to create fuzzy operators. We

exploit it (see Listing 8) to deﬁne the fuzzy operators

used in the soft query presented in Listing 3.

Let us consider the deﬁnition of the

Has Medium Pressure operator. First of all, the

PARAMETERS clause speciﬁes the formal parameters

received by the operator Has Medium Pressure.

Speciﬁcally, the Has Medium Pressure operator

receives one single parameter, named pressure,

deﬁned as an integer value. When the operator is

invoked, all parameters are assembled into one JSON

document, having the formal parameters as ﬁelds

and the actual parameters as values. In our case, this

JSON document will have only the pressure ﬁeld.

In order to obtain the membership degree, we have to

evaluate an expression based on this parameter. The

Soft Querying GeoJSON Documents within the J-CO Framework

259

(a) Has Medium Pressure. (b) Has High Humidity. (c) Has Low Temperature.

Figure 1: Membership Functions of Fuzzy Operators in Listing 8.

EVALUATE clause speciﬁes this expression. In our

case, the value of the pressure parameter is kept

untouched.

However, not all values of the input parameters

are valid: the PRECONDITION clause speciﬁes

a condition to be veriﬁed before performing the

evaluation. If the condition is false, no membership

value is generated and the operator generates an

evaluation error. In our case, an atmospheric pressure

below zero has no physical meaning.

The RANGE clause speciﬁes the range within which

the result of the EVALUATE expression is mapped

to the corresponding membership degree, by means

of the polyline function deﬁned in the subsequent

POLYLINE clause. In this case, we consider a range

between 700 and 1100 millibar.

Finally, the POLYLINE clause deﬁnes the polyline

used as membership function. It is deﬁned as a

sequence of pairs (x, y), where x is a coordinate in

the range speciﬁed by the RANGE clause, while y is

a value speciﬁed in the range [0, 1]. The ﬁrst pair

has the value of the x coordinate that coincides with

the left bound of the range, while the last pair has a

value for the x coordinate that is equal to the right

bound of the range. This way, it is possible to deﬁne

the membership function as a polyline, where the y

coordinate denotes the ﬁnal membership value.

For example, the membership function for the

Has Medium Pressure operator is depicted

in Figure1a: notice the points of the polyline that

correspond to the sequence of pairs. If we suppose

that the actual value of the pressure parameter

is 1003, the corresponding y coordinate is 1 (the

membership degree), i.e., the pressure belongs to

the set of medium pressure; if the value for the

pressure parameter is 1045, the corresponding

membership degree is 0, meaning that the pressure

does not belong at all to the set of medium pressure.

And so on. We assume that in case of values of

the expression speciﬁed in the EVALUATE clause

that are lower than the left bound (greater than the

right bound, resp.), the y value of the left bound

(right bound, resp.) is the membership value. For

example, if the pressure parameter is 1140 mb,

the membership value is 0.

Similarly, Listing 8 deﬁnes the

Has High Humidity operator, which consid-

ers values over 0% as valid humidity and whose

membership function is in the [0%, 100%] range

as depicted in Figure 1b. It also deﬁnes the

Has Low Temperature operator, which consid-

ers values over the absolute zero (−273

◦

) as valid

temperature and whose membership function is in the

[−30

◦

, 50

◦

] range, as depicted in Figure 1c.

Listing 8: Deﬁnition of the Fuzzy Operators.

CREATE FUZZY OPERATOR

Has_Medium_Pressure

PARAMETERS pressure TYPE Integer

PRECONDITION .pressure >=0

EVALUATE .pressure

RANGE (700, 1100)

POLYLINE (700,0), (900,0),

(950,0.3), (980,1),

(1010,1), (1025, 0.9),

(1040,0), (1100,0);

CREATE FUZZY OPERATOR

Has_High_Humidity

PARAMETERS humidity TYPE Integer

PRECONDITION .humidity >=0

EVALUATE .humidity

RANGE (0, 100)

POLYLINE (0,0), (70,0),

(90,1), (100,1);

CREATE FUZZY OPERATOR

Has_Low_Temperature

PARAMETERS temperature TYPE Integer

PRECONDITION .temperature >=-273

EVALUATE .temperature

RANGE (-30, 50)

POLYLINE (-30,1), (0,1),(10,0.2),

(20,0), (50,0);

WEBIST 2020 - 16th International Conference on Web Information Systems and Technologies

260

6.2 Fuzzy Sets in J-CO-QL Queries

The fuzzy extension to J-CO-QL can be actually used

to perform the soft query presented in Listing 3. The

fuzzy J-CO-QL query is reported in Listings 9, 10 and

11. The ﬁrst thing to do is to introduce how the data

model has been extended, in order to deal with mem-

bership to fuzzy sets.

A JSON document d can belong to one or more

fuzzy sets A

, A

, . . . , A

. For each fuzzy set A

, d be-

longs to A

with a membership degree A

(d) ∈ [0, 1].

To represent the multiple membership degrees of d,

a special root-level ﬁeld named ˜fuzzysets is in-

troduced: it is a nested structure, containing only nu-

merical ﬁelds; each ﬁeld denotes the membership de-

gree of the JSON document to the fuzzy set named as

the ﬁeld. Notice that the name ˜fuzzysets is fully

compliant with JSON naming rules. Furthermore, no-

tice that it represents the map introduced in Section 4

that associates fuzzy sets to membership degrees.

As an example, consider the two JSON documents

reported in Listing 12. For each document, the mem-

bership to four fuzzy sets has been evaluated: in fact,

notice the presence of the ˜fuzzysets ﬁeld. The

reader can notice that the names of the fuzzy sets are

the same introduced in the soft query in Listing 3:

hereafter, we will see how to compute them.

However, we want to point out that the documents

do not say how the membership degrees to fuzzy sets

were evaluated, they only say the degree with which

they belong to some fuzzy sets. The advantage of this

solution is that the documents are still standard JSON

documents: they can be stored into database collec-

tions and retrieved from them.

In Section 5, we presented the FILTER instruc-

tion without fuzzy sets. From now on, we will make

use of the extended version of the FILTER instruc-

tion, that provides speciﬁc clauses to deal with fuzzy

sets. Remember that the general goal is to perform

the soft query in Listing 3: starting from the Me-

teo Measures GeoJSON document (reported in

Listing 1), we want to generate a new GeoJSON doc-

ument, containing only those features that have high

humidity and either low temperature or medium pres-

sure or both, sorted in reverse order of relevance.

Let us start with the preamble of the J-CO-QL

query, reported in Listing 9. This part of the query

coincides with the ﬁrst three instructions in the clas-

sical J-CO-QL query reported in Listing 4: this is not

surprising, because these three instructions retrieve

the collection containing the desired GeoJSON layer

from the database, expand the features into one single

document for each feature and remove nested struc-

tures that are not necessary.

Listing 10 reports the core part of the query. In

this part, it is necessary to actually evaluate fuzzy sets,

both those that express basic linguistic predicates,

such as Medium Pressure, High Humidity

and Low Temperature, and the one (Wanted )

derived by combining the former ones.

The ﬁrst FILTER instruction evaluates the mem-

bership degree of documents in the temporary collec-

tion (generated by the last instruction in Listing 9) to

the High Humidity fuzzy set.

Speciﬁcally, after the WHERE condition, the CHECK

FOR FUZZY SET sub-clause denotes that the mem-

bership degree to this fuzzy set is evaluated.

In particular, the subsequent USING sub-clause re-

ports the fuzzy condition to be used in order to eval-

uate the membership degree. In this case, the fuzzy

condition evaluates the Has High Humidity op-

erator on each single document; the membership de-

gree returned by the fuzzy operator becomes the de-

gree with which each single document belongs to the

High Humidity fuzzy set.

Notice that the GENERATE action is absent: the struc-

ture of documents that are put into the output tempo-

rary collection does not change, apart from the novel

˜fuzzysets ﬁeld that is automatically added.

The second and the third FILTER instructions

perform the same activity, i.e., they evaluate the

degree of membership to the Medium Pressure

fuzzy set and to the Low Temperature fuzzy

set. After the third FILTER instruction, the

˜fuzzysets ﬁeld contains three ﬁelds, one for each

of the three evaluated fuzzy sets.

The last FILTER instruction in the core part of

the query (Listing 10) evaluates the membership to

the Wanted fuzzy set. The fuzzy condition (USING)

uses the previously computed membership degrees to

fuzzy sets High Humidity, Medium Pressure

and Low Temperature as linguistic predicates, in

Listing 9: Fuzzy J-CO-QL Query (preamble).

GET COLLECTION Meteo_Measures@MyDB;

EXPAND

UNPACK WITH ARRAY .features

ARRAY .features TO feature

DROP OTHERS;

FILTER

CASE WHERE WITH .feature.item

GENERATE

{ .type: .feature.item.type,

.properties:

.feature.item.properties,

.geometry:

.feature.item.geometry }

DROP OTHERS;

Soft Querying GeoJSON Documents within the J-CO Framework

261

Listing 10: Fuzzy J-CO-QL Query (core).

FILTER

CASE WHERE

WITH .properties.humidity

CHECK FOR FUZZY SET High_Humidity

USING Has_High_Humidity(

.properties.humidity )

DROP OTHERS;

FILTER

CASE WHERE

WITH .properties.pressure

CHECK FOR FUZZY SET Medium_Pressure

USING Has_Medium_Pressure(

.properties.pressure )

DROP OTHERS;

FILTER

CASE WHERE

WITH .properties.temperature

CHECK FOR FUZZY SET Low_Temperature

USING Has_Low_Temperature(

.properties.temperature )

DROP OTHERS;

FILTER

CASE WHERE KNOWN FUZZY SETS

High_Humidity,

Low_Temperature,

Medium_Pressure

CHECK FOR FUZZY SET Wanted

USING High_Humidity AND

(Low_Temperature OR Medium_Pressure)

ALPHA-CUT 0.5 ON Wanted

DROP OTHERS;

order to evaluate the degree with which documents

belong to the wished Wanted fuzzy set.

The structure of the instruction is the same, but with

some small differences. First of all, in the WHERE

clause, we use the KNOWN FUZZY SETS predicate,

that is evaluated as true if the membership to all the

listed fuzzy sets has been evaluated in a document.

Second of all, notice that the fuzzy condition in the

USING sub-clause now simply relies on fuzzy sets

that are used as linguistic predicates.

Finally, the ALPHA-CUT clause speciﬁes that only

documents having a membership degree greater than

or equal to 0.5 to the Wanted fuzzy set are kept in

the output temporary collection.

In Listing 12, we report the documents that are

present in the temporary collection at the end of the

core part of the query (Listing 10). The reader can no-

tice that, of the three features formerly present in the

source GeoJSON document (reported in Listing 1),

only two of them have been selected by the ALPHA-

CUT clause. Notice, in each document, the presence

of the special ˜fuzzysets ﬁeld, with the four ﬁelds

corresponding to the four fuzzy sets and the corre-

Listing 11: Fuzzy J-CO-QL Query (tail).

FILTER

CASE WHERE

WITH ."˜fuzzysets".Wanted

GENERATE { .type: .type,

.properties: .properties,

.geometry: geometry, .key: 1,

.properties.rank:

."˜fuzzysets".Wanted }

DROPPING ALL FUZZY SETS

DROP OTHERS;

GROUP

PARTITION WITH .key

BY .key INTO .features

DROP GROUPING FIELDS

ORDER BY .properties.rank DESC

GENERATE

{ .type: "FeatureCollection",

.features: .features }

DROP OTHERS;

SAVE AS Filtered@MyDB;

sponding membership degrees.

Finally, the tail of the query, reported in List-

ing 11, can be executed, to rebuild a GeoJSON docu-

ment containing the wished features.

The ﬁrst FILTER instruction in Listing 11 pre-

pares documents to be grouped into the output GeoJ-

SON document. In particular, the GENERATE action

inserts a rank ﬁeld into the properties ﬁeld of

each document, whose value is the membership de-

gree to the Wanted fuzzy set: this value denotes how

much the document satisﬁes the linguistic selection

condition. Notice that, apart from the need to refer

to the ˜fuzzysets ﬁeld as "˜fuzzysets", it is

a standard JSON ﬁeld and can be referred to accord-

ingly. As in Listing 6, a ﬁeld named key with a con-

stant value is added, that will play the role of grouping

ﬁeld in the next GROUP instruction.

The DROPPING ALL FUZZY SETS option asks

for removing the ˜fuzzysets special ﬁeld from the

output documents.

The GROUP instruction rebuilds a unique GeoJ-

SON document. With respect to the GROUP instruc-

tion in Listing 6, now we have the ORDER BY clause

that sorts documents that have been grouped into the

new features array in descending order (DESC op-

tion) of rank.

Finally, the temporary collection, that contains

only the wished GeoJSON document (reported in

Listing 13), is saved into the database.

The fuzzy J-CO-QL query presented in this sec-

tion, demonstrates that J-CO-QL is effective in per-

forming the soft query reported in Listing 3. How-

ever, although J-CO-QL is effective, it is a rich and

complex language, that asks for the development of

WEBIST 2020 - 16th International Conference on Web Information Systems and Technologies

262

Listing 12 Document belonging to some fuzzy sets.

{ "geometry" : {

"coordinates" :

[ 9.379659683, 45.26066732 ],

"type" : "Point" },

"properties" : {

"Date" : "2020-05-01",

"Station_Id" : 109,

"humidity" : 83,

"pressure" : 1000,

"temperature" : 26 },

"type" : "Feature",

"˜fuzzysets" : {

"High_Humidity" : 0.65,

"Low_Temperature" : 0.0,

"Medium_Pressure" : 1.0,

"Wanted" : 0.65 }

}

{ "geometry" : {

"coordinates" :

[ 9.267153115, 45.32059361 ],

"type" : "Point" },

"properties" : {

"Date" : "2020-05-01",

"Station_Id" : 114,

"humidity" : 99,

"pressure" : 980,

"temperature" : 24 },

"type" : "Feature",

"˜fuzzysets" : {

"High_Humidity" : 1.0,

"Low_Temperature" : 0.0,

"Medium_Pressure" : 1.0,

"Wanted" : 1.0 }

}

higher-level tools, such as the soft query language

sketched in Section 4. In Section 6.3 we show that

it is possible to devise a query-rewriting technique,

that generates the fuzzy J-CO-QL query reported in

Listings 9, 10 and 11. Consequently, based on this

consciousness, Problem 1 can be reﬁned as follows.

Problem 2. Given a soft query sq on a GeoJSON doc-

ument, rewrite the query into a J-CO-QL query that

generates a new GeoJSON document containing only

the features that satisfy the soft condition, sorted vs

the membership degree in reverse order.

6.3 Rewriting Soft Queries

We can ﬁnally provide the ﬁnal contribution of the

paper, i.e., addressing Problem 2: we present an algo-

rithm for rewriting soft queries into fuzzy J-CO-QL

queries, that proceeds as follows.

1. The concept of temporary collection will be ex-

ploited to save intermediate collections generated

by nested soft queries.

Listing 13: GeoJSON document saved to database.

{ "type" : "FeatureCollection",

"features" : [

{ "type" : "Feature",

"geometry" : {

"coordinates" :

[ 9.267153115, 45.32059361 ],

"type" : "Point" },

"properties" : {

"Date" : "2020-05-01",

"Station_Id" : 114,

"humidity" : 99,

"pressure" : 980,

"temperature" : 24,

"rank" : 1.0 } },

{ "type" : "Feature",

"geometry" : {

"coordinates" :

[ 9.379659683, 45.26066732 ],

"type" : "Point" },

"properties" : {

"Date" : "2020-05-01",

"Station_Id" : 109,

"humidity" : 83,

"pressure" : 1000,

"temperature" : 26,

"rank" : 0.65 } }

]

}

2. The data model of J-CO-QL naturally deals with

fuzzy sets. So, given a feature f , the map

f .fuzzysets corresponds to the special ﬁeld

˜fuzzysets.

3. Given a nested soft query sq

in the FROM clause

of another soft query sq

(i−1)

, the translation of sq

generates the temporary collection that will be the

input to the translation of sq

(i−1)

4. The preamble of the J-CO-QL query is the code

that gets the collection from the database and ex-

tracts features from within the GeoJSON docu-

ment; the last part of the J-CO-QL query is the

code that groups features to generate one single

GeoJSON document.

Algorithm 1 reports the pseudo-code of the rewrit-

ing process. Hereafter, we present it.

• The rewriting process is managed by the Rewrite-

SoftQuery function, that receives a query sq as

input parameter; it returns a string with the corre-

sponding J-CO-QL query.

• The RewriteSoftQuery function takes the string

generated by the recursive RewriteSingleQuery

function and appends the tail of the query, gener-

ated by the GenTail function.

• The RewriteSingleQuery function recursively

deals with nesting of soft queries. If the FROM

clause of the current query is a nested query, it

Soft Querying GeoJSON Documents within the J-CO Framework

263

Algorithm 1 : Rewrites Soft Queries on GeoJSON docu-

ments to fuzzy J-CO-QL queries.

1.Function RewriteSingleQuery(sq: SoftQuery)

: String

Begin

T := "";

If sq.FROM Is a Soft Query Then

T := RewriteSingleQuery(sq.FROM);

Else

T := GenPreamble(sq.FROM)

End If

R := T •GenFilter(sq.FROM);

Return R;

End Function

Function RewriteSoftQuery(sq: SoftQuery)

: String

Begin

T := RewriteSingleQuery(sq);

R := T • GenTail(sq);

Return R;

End

recursively recalls itself; otherwise, it is a layer

name and it calls the GenPreamble function.

The GenPreamble function prepares the pream-

ble of the J-CO-QL query, that gets the collec-

tion containing the GeoJSON document from the

database and expands it, to obtain as many JSON

documents describing features as the features that

are grouped within the features array at the

root level of the GeoJSON document.

• Finally, the RewriteSingleQuery function ap-

pends the output of the GenFilter function, that

actually generates a J-CO-QL FILTER instruc-

tion that corresponds to the current soft query.

For the sake of space, we do not report the pseudo

code for the GenFilter and the GenTail functions.

However, having in mind Listing 10, the GenFil-

ter function generates the FILTER instruction cor-

responding to each single soft query. Having in mind

Listing 11, the GenTail function generates the whole

tail of the query; speciﬁcally, it uses the outer soft

query to generate the ﬁrst FILTER instruction in List-

ing 11, that generates the rank ﬁeld by taking the

membership value to the Wanted fuzzy set, as well

as the ORDER BY clause in the GROUP instruction.

The presented algorithm is thus able to rewrite a

high-level and generic soft query on GeoJSON doc-

uments, as formulated in Section 4, into a fuzzy J-

CO-QL query. Thus, we solve Problems 1 and 2, as

well as we have shown that it is possible to effectively

use the J-CO-QL language and, more in general, the

J-CO framework, as the underlying engine to develop

high-level soft query languages on speciﬁc classes of

JSON documents, such as GeoJSON documents.

7 CONCLUSIONS

In this paper, we introduced the idea of writing soft

queries, i.e., queries that rely on linguistic predicates,

on a speciﬁc class of JSON documents, i.e., GeoJSON

documents. The usefulness of this approach is moti-

vated by the fact that GeoJSON has become a widely

used format for disseminating geographical informa-

tion over the Web, but a standard query language able

to natively query GeoJSON documents is not avail-

able yet.

We explored the adoption of the fuzzy constructs

introduced in the J-CO-QL language, that is part of

the J-CO framework, speciﬁcally designed to provide

a powerful tool to manipulate and query collections

of JSON documents in a seamless way with respect

to the speciﬁc JSON storage system. The query-

rewriting technique presented in Section 6.3 shows

that it is possible to generate a complex fuzzy J-CO-

QL query from a simple and high-level soft query. We

showed that the high-level soft query language can

be actually translated into a concrete query language

(such as J-CO-QL). The effectiveness of the idea will

be evaluated in future validation campaigns.

As a future work, we plan to further investigate

the deﬁnition of high-level and soft query languages

for JSON documents, by considering various JSON

standards. In fact, we think that the development of

effective query languages for JSON data sets is an

important research line; and it is a concrete and use-

ful application of the J-CO framework as underlying

execution engine. Geo-tagging within JSOn (as Geo-

JSON) documents will be consider, to perform uncer-

tain location-based queries (Bordogna et al., 2008).

REFERENCES

Blair, D. C. (1979). Information retrieval, 2nd ed. c.j. van

rijsbergen. london: Butterworths; 1979: 208 pp. price:

$32.50. Journal of the American Society for Informa-

tion Science, 30(6):374–375.

Bordogna, G., Capelli, S., Ciriello, D. E., and Psaila, G.

(2018). A cross-analysis framework for multi-source

volunteered, crowdsourced, and authoritative geo-

graphic information: The case study of volunteered

personal traces analysis against transport network

data. Geo-spatial Information Science, 21(3):257–

271.

WEBIST 2020 - 16th International Conference on Web Information Systems and Technologies

264

Bordogna, G., Capelli, S., and Psaila, G. (2017). A big

geo data query framework to correlate open data with

social network geotagged posts. In The Annual Inter-

national Conference on Geographic Information Sci-

ence, pages 185–203. Springer.

Bordogna, G., Pagani, M., Pasi, G., and Psaila, G. (2008).

Evaluating uncertain location-based spatial queries. In

Proceedings of the 2008 ACM symposium on Applied

computing, pages 1095–1100.

Bordogna, G. and Pasi, G. (1995). Linguistic aggregation

operators of selection criteria in fuzzy information re-

trieval. International journal of intelligent systems,

10(2):233–248.

Bordogna, G. and Psaila, G. (2009). Soft aggregation in

ﬂexible databases querying based on the vector p-

norm. International Journal of Uncertainty, Fuzziness

and Knowledge-Based Systems, 17(supp01):25–40.

Bosc, P. and Pivert, O. (1995). Sqlf: a relational database

language for fuzzy querying. IEEE transactions on

Fuzzy Systems, 3(1):1–17.

Bosc, P. and Prade, H. (1997). An introduction to the fuzzy

set and possibility theory-based treatment of ﬂexible

queries and uncertain or imprecise databases. In Un-

certainty management in information systems, pages

285–324. Springer.

Buell, D. A. (1985). A problem in information retrieval

with fuzzy sets. Journal of the American Society for

Information Science (pre-1986), 36(6):398.

Butler, H., Daly, M., Doyle, A., Gillies, S., Hagen, S.,

Schaub, T., et al. (2016). The geojson format. Internet

Engineering Task Force (IETF).

Campi, A., Damiani, E., Guinea, S., Marrara, S., Pasi, G.,

and Spoletini, P. (2009). A fuzzy extension of the

xpath query language. Journal of Intelligent Informa-

tion Systems, 33(3):285.

Damiani, E. and Tanca, L. (2000). Blind queries to

xml data. In International Conference on Database

and Expert Systems Applications, pages 345–356.

Springer.

Fuhr, N. (1989). Models for retrieval with probabilistic

indexing. Information Processing & Management,

25(1):55–72.

Galindo, J., Urrutia, A., and Piattini, M. (2006). Fuzzy

databases: Modeling, design, and implementation.

IGI Global.

Herrera, F. and Herrera-Viedma, E. (1997). Aggregation

operators for linguistic weighted information. IEEE

Transactions on Systems, Man, and Cybernetics-Part

A: Systems and Humans, 27(5):646–656.

Kacprzyk, J. and Zadro

zny, S. (1995). Fquery for access:

Fuzzy querying for a windows-based dbms. Bosc P.,

Kacprzyk J. (eds), Fuzziness in Database Manage-

ment Systems. Studies in Fuzziness, 5.

Kraft, D. H., Colvin, E., Bordogna, G., and Pasi, G. (2015).

Fuzzy information retrieval systems: A historical per-

spective. In Fifty Years of Fuzzy Logic and its Appli-

cations, pages 267–296. Springer.

Marrara, S. and Pasi, G. (2016). Fuzzy approaches to ﬂexi-

ble querying in xml retrieval. International Journal of

Computational Intelligence Systems, 9(sup1):95–103.

Medina, J. M., Pons, O., and Vila, M. A. (1994). Gefred: A

generalized model of fuzzy relational databases. In-

formation Sciences, 76(1):87 – 109.

Psaila, G. and Fosci, P. (2018). Toward an anayist-oriented

polystore framework for processing json geo-data.

In International Conferences on Applied Computing

2018, Budapest; Hungary, 21-23 October 2018, pages

213–222. IADIS.

Psaila, G. and Marrara, S. (2019). A ﬁrst step towards

a fuzzy framework for analyzing collections of json

documents. In IADIS AC 2019, pages 19–28.

Ramer, A. (1989). Possibility theory: An approach to com-

puterized processing of uncertainty, by didier dubois

and henri prade, plenum press, new york 1988. xvi+

263 pages. International Journal of General Systems,

15(2):168–170.

Salton, G., Allan, J., Buckley, C., and Singhal, A.

(1994). Automatic analysis, theme generation, and

summarization of machine-readable texts. Science,

264(5164):1421–1426.

Waller, W. and Kraft, D. H. (1979). A mathematical model

of a weighted boolean retrieval system. Information

Processing & Management, 15(5):235–245.

Zadeh, L. A. (1965). Fuzzy sets. Information and control,

8(3):338–353.

Zadeh, L. A. (1975). The concept of a linguistic variable

and its application to approximate reasoning—i. In-

formation sciences, 8(3):199–249.

Soft Querying GeoJSON Documents within the J-CO Framework

265