Topic on User talk:Olea

I think legalFoundationDate in CDDA data rather shouldn't be interpreated as incpetion year. At least in case of Estonian protected objects this appears to be the year when last version of protection rules came into effect. E.g. for Karula Pikkjärv Nature Park (Q12366532) current protection rules came into effect in 2015, but per first entry for this protected area is as of 1959, and per it exist in the same boundary since 2006.

I also happen to notice for some reason you set that Estonian-language offical names are in Danish, e.g. for Vargstein (Q108068920). The latter type of protected object also is an individual physical object and hence shouldn't be treated as a protected area, i.e. it should be instance of what it actually is (a boulder, or glacial erratic) and "area: 0 ha" better be omitted.

What do you suggests for legalFoundationDate? Better not to use it? :-m

About the Danish labeling... I'm really sorry 0_o. I'm fixed the typo and I could update the correct labels in next uploads.

Thanks for the feedback :)

I've changed legalFoundationDate in the OpenRefine schema to use start time (P580). This way everything could be update. The drawback is this conflicts with inception (P571) these should be removed at some point (probably with QS).

start time (P580) and inception (P571) seem equivalent to me. Start time of a protected area would be the inception time, wouldn't it? At least in case of Estonian protected objects, yes, I'd ignore legalFoundationDate in CDDA dataset. Unless there is a statement about the latest version of protection rules in particular. As for other countries, I don't know, maybe there is more reason to interpret is as an incpetion year.

A couple of more remarks. Firstly, items for types (designations) of protected objects in Estonia already existed for the most part. E.g. Q108059560 is {Q1|2364029}}. Also these designations being set as instances of CDDA designation type (Q108028209) seems odd, as these designations after all are specific to individual countries, not to given dataset, i.e. they are not "developed by the CDDA" as item description currently says. Also these designations, at least in case of Estonia, are not legal forms, as currently stated, i.e. procted areas aren't individual legal entities with legal form, but instead are managed by a legal entity (ministry, agency or alike) that has legal form.

Secondly, protected object name in CDDA being interpreated as official name is dubious, too. E.g. in case of Uuesoo rändrahn; (Uuesoo e. Rebase kivi ja teised rahnud; Rebasekivi) (Q108068925) its a mix aliases and a description, and in case of Lahemaa RP, Palganeeme skv. (Q108068922) it's just a combination of abbreviated protected area name and protected area section name. Per the first one has only an unofficial name ("Rebasekivi"), and if the second one has official name then rather it would be "Palganeeme sihtkaitsevöönd" from protection rules. I'd use these CDDA "names" only as labels (that often still need to be corrected to an actual name).

Protected names are chosen by national autorities and used as is. The CDDA designations codes are a CDDA/EIONET system, hence the instances. Also, this is the system I'm using in WD for all the CDDA id elements. About duplicates: yes, probably. I've compared against WDPA codes when available. When in doubt I prefer to left a potential duplicate element suitable to be merged to the correct one than mix in a wrong one messing concepts and details.

Well, as shown above these protected names are kind of ad hoc, also aren't necessarily proper names, and aren't the only name variants found in official usage. I'm fine with thse names being used as (preliminary) labels, but there doesn't seem to be much reason to think that these names are official and neither does CDDA explicitly say so despite reference to CDDA.

Yes, CDDA/EUNIS has assigned its own codes to national designations, but these designations per se are defined and assigned by individual countries, not by CDDA/EUNIS. Similary, EUNIS has assigned unique ids to species, but we probably wouldn't say that, say, Salix alba (Q156918) is an instance of "EUNIS species" despite having EUNIS id.

These designation codes are currently set as official names which they aren't really, and there doesn't seem to be other fitting property either. Possibly new property for EUNIS designation code should be created, similar to EUNIS ID for species (P6177)?

I now noticed that you created 15 items about Nature Conservation Act (Q16413376), each new item for an arbitary selection of paragraphs. Could you please use the previously existing item with section, verse, paragraph, or clause (P958) qualifer instead?

As explained in the other answer I can't fine tune things like that. Just please merge (as you does) or clean any not needed data. And is not arbitrary text but the exact one in the CDDA database.Feel free to adapt to your preferred decomposed qualifiers convention.

BTW, a couple other things: I removed many of the CDDA Estonian type codes bc that wrong dk labels but for some reason Wikidata don't let me create again bc is using the same labels, so there are a few codes I can't upload yet. Also, in the current task of uploading I'm finding 395 WD elements with CDDA id I can relate with the database, 19789 without CDDA in WD and 23 of these seeming to exist in WD but without id codes. Here there is a question: do you want me to at least create those 19789 elements in WD? If you choose not to do I'll left all the Estonian items and I'll finish the other countries.

Hm, no offence, but such level of duplication sounds kind of careless. Certain kind of data in CDDA is probably better not to be automatically matched and imported. I see that these exact law references are given in CDDA, but these references nonetheless are arbitrary text, most legalReferenceName values being a reference to unieque paragaph in some legislative act. Some sort of data'd probably give much better results if handled in smaller patches, e.g. you can treat sites of one designation in one way and sites of another designation in another way.

I'm not sure which 19789 sites exactly you have in mind. I do notice that CDDA includes 12703 sites of designation type EE23, none of which even have a name, i.e. siteName values are numbered like "VEP nr.102011", "VEP nr.130107" etc. Such sites, compareable to cadastral parcels and alike, might not even meet WD:N. I also checked that WD currently has 1305 protected natural objects with Environmental Register code (Estonia) (P4689), of which 177 are without WDPA id. Some of these may be former protected objects that are no longer available in WDPA/CDDA, but others should be matched. I don't know if there is some external dataset that matches P4689 values directly to P809 values. If not, then you can use CDDA's "nationalId" column and match it to properties > id value in queries like this to get P4689 value.

If you plan to import more data about Estonian protected objests then the following would be appreciated. Otherwise I feel that the manual cleanup work you leave to others, including myself, is tremendous. In summary:

1. drop misleading/dubious inception/start time and offical name statements
2. use P31=protected area (Q473972) statement only for sites of certain designations like nature reserve and nature park (protected landscape), and not for other designations that are *not* for protected areas like individual protected natural object (protected nature monument)
3. drop area statement for nature monuments (trees, boulders) and other sites with meaningless "0 ha" value
4. if preliminary Estonian-language description for individiual protected objects is its designation, then it should be in lower case, e.g. "kaitstav looduse üksikobjekt"
5. if data is matched to existing item, then don't import duplicating values to statements that already have value that is expected to be valid, and don't overwrite existing descriptions that are expected to be more accurate
6. avoid some weird stuff such as setting designation code as alias for individual protected object, like here lately

Also it would be appreciated if CDDA sites in Estonia are matched to designations that are currently used consistently for protected natural objects in Estonia as heritage designation (P1435) values (see query) and these designation be used for new items as well.

Seems your requirements are higher than I could deliver. So I left the task open for other person. Sorry.

Yesterday I started to clean up these designation items. For instance, in case of nature park (Q45754653) I already merged everything that isn't dubious and otherwise makes sense (Special:Diff/1482853691). Now you readded this: Special:Diff/1483257387. I'd appreciate if you didn't undo my work without addressing concerns that I had. Some of it I already covered above. As for the rest:

1. Code is is just a code, not a name, and hence I don't see why it should be given as label/alias nor official name. Now we also have separate property for designation code anyway.
2. "Maastikukaitseala (looduspark)" is a cominbation of two name variants, one of which should be formatted as an alias on Wikidata. I see even less reason to think that such arbitary text is an offical name.
3. You relinked one of these duplicate items for a legistlative act that was already properly linked using a qualifier.
4. What does it mean that ministry "operates" a designation? It'd make make more sense to say that ministry or other authority operates/manages, or more precisely in context of protected areas, governs particular sites of some designation.

In case of P31=CDDA designation type (Q108028209) statement in particular I already described above and here why this is rather misleading. Designation nature park (Q45754653) is the very same national designation designation that is referred in CDDA, but it was developed and adopted entirely independent of CDDA, as defined in Nature Conservation Act of Estonia. As such description "developed by the CDDA" for Q108028209 or other similar association to CDDA is simply wrong.

I see you now changed CDDA designationTypeCode (P9800)'s type constraint to use this poorly defined CDDA designation type (Q108028209) item. If P31=Q108028209 statement is equivalent to any item with P9800 statement, then what's the point of such circular constraint anyway? Earlier I left a suggestion about this constraint here: Property talk:P9800#Type constraint.