why use dbp props?

[VladimirAlexiev]

In ISO10383.tarql you have this:

<MIC exchange/market>
		dbp:formerLabel	?NAME_INSTITUTION_DESCRIPTION ;
		dbp:formerName	?NAME_INSTITUTION_DESCRIPTION ;
		fibo-fbc-fct-mkt:hasExchangeName	?NAME_INSTITUTION_DESCRIPTION ;
		rdfs:label	?NAME_INSTITUTION_DESCRIPTION ;

<MIC code>
		rdfs:label	?_miclbl ;
		dbp:formerLabel	?_miclbl ;

• Why emit the same label as both current and "former"? Or is the idea that at some point "DELETED" entries will be left only with "former"?
• @ElisaKendall doesn't FIBO or LEI have a term for "former name"?
• dbp is not a very good namespace because it applies only to English dbpedia and signified a "raw" (unmapped) prop.
  • If you need to, use dbo:formerName (see http://mappings.dbpedia.org/index.php/OntologyProperty:FormerName)

[hroptatyr]

Hi Vladimir,
the idea is to collect all former names/labels (as long as LEI doesn't change) while the current one is visible as per foaf:name/rdfs:label. Similar to how Bloomberg does it (e.g. bbdp:priorMnemonics).

GLEIF does have a previousLegalName or something, but specifically for labels I couldn't find anything other than dbp:.

[VladimirAlexiev]

• So the idea is to keep loading MarketsIndividuals.ttl without replacing the old content?
  But if some bigger changes happen in MIC, won't this "accumulation" approach lead to disaster?
  Eg an exchange having status both "ACTIVE" and "DELETED"?
• there is dbo:formerName; and you don't need both formerName and formerLabel

[hroptatyr]

Yes, all entries are kept and historical entries are already replayed. Whenever something becomes repurposed or reused, as opposed to a simple rename, the (prior) resource is suffixed. So you have a chance to refer to both the old and the new exchange or MIC.

You're right about dbp:formerName/Label.

[hroptatyr]

oh, I was going to mention MarketIndividuals-hist.ttl where "historic" records are collected.