## 4 Experimental Section: An Ontology of the SEA Procedure of City Masterplans
Slots can be used either to characterize the elements of a class by means of attributes of different types (for instance, string, integer, enumerated), or to describe the relationships between instances, which are defined as the elements belonging to a given class; in other words, features represent the finest level of granularity and form the basis of the hierarchy. Figure 2(a) illustrates, as an example, the slots assigned to the class \"Municipal planning authority\", which is a subclass of the class \"Key Actors\". \"Level\" and \"Name\" are two descriptive attributes, both required and both having single cardinality (meaning that only one value for each attribute is allowed); the type of the first is \"symbol\" (meaning that it can only take predefined values) and that of the second is \"string\" (meaning that any alphanumeric string is allowed). Figure 2: **(a)** An example of descriptive and relational slots assigned to the class “Municipal Planning Authority” in Protege; **(b)** A graphical representation of relations corresponding to these slots. As far as the other three (\"Approves\", \"Prepares\", \"Identifies\") are concerned, they make the relations between the subclass \"Municipal planning authority\" on the one hand and the classes \"Plan\" and \"Consultation authority\" on the other hand explicit, or, more precisely, they make the relations between features belonging to the aforementioned classes explicit. These relations are represented by means of graphs in Figure 2(b). All of the three slots have multiple cardinality (that is, an instance of the class \"Municipal planning authority\" can prepare and/or approve more than one instance of the class \"Plan\" and it can identify, together with the authority that bears responsibility for the SEA, more than one feature belonging to the class \"Consultation authority\"); for two of these instances, inverse relations are defined. Figure 3(a) shows another example, that of the slots assigned to the class \"Scoping report\", which is a subclass of the class \"Document\". Its five slots (\"Has phase\", \"Prepared by\", \"Publicity\", \"Recipient\", \"Refers to\") describe the relationships between the subclass \"Scoping report\" and the classes \"P02_Scoping\" (subclass of the class \"SEA Phase\"), \"Municipality planning authority\", \"Information and Consultation\", \"Key Actors\" and \"Plan\" respectively. These relations are represented by means of graphs in Figure 3(b). The slot \"Has phase\", having single cardinality, is defined as the inverse of \"Has document\", which makes explicit the relation between a phase of the SEA process and its corresponding documents, if any. The slot \"Refers to\" connects a scoping report to the city masterplan it refers to; its cardinality is single because for each plan only one scoping report, a document that aims at establishing both scope and methodology of the SEA process, is prepared and, _vice versa_, each scoping report describes only one plan. The slot \"Prepared by\", having single cardinality, is defined as the inverse of the slot \"Prepares\" mentioned in the previous example; its cardinality is single because, in this given domain (that of the SEA of city masterplans) a plan, and consequently its scoping report, can only be prepared by a municipality; things would have been different if, for instance, the domain had included the SEA of other types of plans, prepared and approved by groups of municipalities. Figure 3: (**a**) An example of descriptive and relational slots assigned to the class “Scoping report” in Protege; (**b**) A graphical representation of relations corresponding to these slots. The slot \"Publicity\" connects the subclass \"Scoping report\" to the class \"Information and Consultation\" so as to show in which ways this document must be made available to the wider public.