ISO19115 compliant metadata

[balazsdukai]

I've been browsing the ISO19115:2014 a bit (yeah, makes a nice bedtime reading....), looking for some new metadata members, and I realized that some of the current cityjson metadata members that are supposedly ISO19115 compliant, might not be so. I don't fully understand how this compliance works, so any help is welcome. I've skimmed the paper too, but maybe I just didn't spot the info in there.

The cityjson metadata members that I spotted, and their equivalent in ISO19115:2014 (in my opinion):

• datasetPointOfContact --> "pointOfContact" (in ISO19115:2014)
• datasetTitle --> I think its "title"
• datasetReferenceDate --> I think its "date"
• geographicalExtent --> I think its probably "geographicExtent" or sth

The question is basically, whether this renaming breaks the compliance or not?

[liberostelios]

I am not an expert, so take everything I say with a grain of salt.

As far as I am concerned and after skimming the standard, the pointOfContact can be assigned to any kind of resource. In theory, a simple pointOfContact under metadata could just mean that this is the point of contact for the metadata. Defining that this is the point of contact for the whole dataset makes it explicit that this applies to the data itself and that it’s for the whole dataset. In some formats (e.g. geopackage) you can assign metadata to subparts of the dataset (e.g. a simple feature or a table - called data source, afair -). Therefore you could have datasetPointOfContact for the whole dataset and datasourcePointOfContact for each individual table. Remember, this is an ISO and as such it’s very messy and arbitrary therefore this can be perceived in many different ways.

I personally like plain pointOfContact more, but it might be that based on the ISO this is too vague because it doesn’t specify if this is for the whole dataset, the metadata itself, a data source, a feature or something. Therefore datasetPointOfContact, as awkward as it might sound, might be more accurate.

[balazsdukai]

My reasoining is from a technical pov

So, i have some parser that expects iso metadata, thus i code my parser to look for the exact matches of the metadata attributes. And i have the trust to code exact matching (ok, probably not case sensitive), because its a standard after all. So i assume that THE correct approach is exact matching.

Thus, if cityjson says that it has iso metadata, but then uses different names for the same attributes, then my parser won't work anymore. Thus, iso compliance means nothing. I need to code a cityjson specific metadata parser.

Going one step further. If it is allowed to deviate from the names as prescribed by iso, eg. use datasetPointOfContact instead of pointOfContact, then what keeps us from naming the point of contact ressource hairyPigs for instance? 😃 Or any other arbitrary name?

[liberostelios]

I think you overestimate the applicability of ISO standards 😅

I am not aware of any standard that can be directly translated to code. If what you say was true, (City)GML would work like a charm. In practice, we came up with CityJSON which basically deviates a bit from the standard to solve its vagueness.

My experience from coding metadata in geopackage also justifies that. Every format eventually comes with its own quirks which would either compliment or alter the ISO metadata. Eventually, I think ISO is just a generic framework to work with, but noone can write ISO-ready code that works for all formats. The way I see it, the ISO just defines the entities and vocabulary and the individual implementations (e.g. here CityJSON) translates it in specific ways.

[balazsdukai]

That's a good point. What I have trouble with is that in my opinion these are all equivalent:

datasetPointOfContact --> "pointOfContact" geographicalExtent --> "geographicExtent" < any misspelling > --> ISO name

So how much "misspelling" can we allow? Because misspelling or change in the name are the same in my opinion.