Design Decisions

Developing the best practices required to take a huge number of design decisions. There are many aspects that allow more than one solution and we expect that you will question the one or other decision we took. Well, great and we are more than happy to discuss each single one with you.

We started with analyzing the use cases. As a result, the design decision was taken:

(1) Keep everything as simple as possible

Citizen science surveys cannot be compared with professional surveys that require extreme flexibility. In fact, most surveys are rather simple in nature, and you can be happy if the survey participants capture notes such as "water level extremely high due to recent severe rain events" or "most butterflies absent due to cold weather". Design decision (1) was implemented with the following details:

(1.1) Whereever possible, perfer hard-typing over softyping

Data serialization in XML can be performed following two different strategies. Hard-typing means that you define individual elements for all our objects in the schema. In contrary, soft-typing defines a record structure that allows you to define the elements at runtime. The following example illustrates the differences:

Hard-typed

<author>Ingo<author>

Soft-typed

<field name="author">Ingo</field>

The key difference is that in the hard-typed approach, you can see in the schema what elements will be part of an instance document. In the soft-typed approach, you only know that any number of elements are allowed, but you cannot guess the attribute value before you receive the instance document. For sure, you might further constrain the allowed "name"-attributes using code lists, but as code lists are often managed separately, that might not help much neither and your parser may suddenly discover an unknown attribute value. The hard- vs. soft-typing approach is basically a decision between higher level of interoperability and more flexibility. Hard-typing means that your parser knows what to expect, whereas soft-typing means that you can later add new attributes without the need to change the underlying schema. A often used approach is hard-typed plus extension. Here, you hard-type as many elements as you think represent the common denominator and then add a parameter that allows key-value pairs. The next question is simple: Once you have all the elements defined, how do you ensure shared semantics? This leads to the next design decision:

(1.2) Use an SKOS for all terms that can be used in soft-typed structures.

As always with knowledge representation models, you can start from scratch or you can use what is already out there. Some more details on that topic can be found here. For brevity: We used a number of concepts defined in the SSN ontology and defined what was missing ourselves. The SweSkos should serve as a temporary solution - or it could stay permanently and gets extended with further concepts and rdf:types to link to other shared vocabularies.