Should the simplification rules include extensions?

INSPIRE-MIF / 2017.2

Repository for action 2017.2 on alternative encodings

6 stars 11 forks source link

Should the simplification rules include extensions? #24

Closed michellutz closed 5 years ago

michellutz commented 6 years ago

Some of the examples proposed (e.g. #4, #5, #6, #7) are extensions to the INSPIRE data models that include additional ("simple") properties with the aim to make data easier to use.

Should such extensions be considered in the simplification rules, and under what conditions?

heidivanparys commented 6 years ago

That's a hard one. I'm not sure we should do that... I can see why it could be useful, but it has already be proven that INSPIRE can be extended, so I'm not sure we should include it here.

tevbrasch commented 6 years ago

I would maybe say that, unless simplification through extension is explicitly needed to handle an attribute for a specific format (how would geojson handle the complex dataype au.administartiveunit.name for example), we should probably avoid it.

cportele commented 6 years ago

In my view the simplification rules should allow extensions, but in order for an encoding to be a candidate for a general INSPIRE Good Practice, extensions should be optional. That is, it should be able to use the encoding to represent data that is restricted to the scope of the IR.

michellutz commented 6 years ago

[2017.2 meeting 2018-09-28]

In the listed examples, additional properties were used to simplify use of the provided data, e.g. by adding a simple "name" property in addition to the complext geographical name property already present in the schema. This was mainly done, in order to stay compliant with the existing schemas.
Since this action's remit is to define additional encodings, the focus should be on simplifying structures that are deemed difficult to use, rather than duplicating information (in a complex and a simple structure) in the same data set. There may be different encodings with different levels of complexity depending on the supported use case.
A chapter on "extensions" should be added in the GP document on simplification rules that explains this aspect. It will also be important to define the terms "extension", "profiling", "flattening"

PeterParslow commented 6 years ago

Take the two "names simplifications" used by OS in the examples we have submitted, the group could define:

one additional encoding, which could be common across a number of themes, and which would be useful in many use cases: to use GML3.3's LocalisedCharacterString. This would be an alternative simplified Geographic Names model, with some kind of hint that themes adopt it? Or an alternative encoding across all those themes that use names, and for which the simple use case is valid.
a second simplification technique, only applicable to network models, which 'moves' the name to the links. Again, useful in some use cases but not others (makes clear visualisation harder). This could be an alternative simplified Generic Network Model?