why use dbp props? - Githubissues

ga-group / iso10383

RDF dataset of ISO10383's MICs (similar to fibo-fbc-fct-mkti) with business centres from ISDA/FpML and historical identifiers.

http://data.ga-group.nl/iso10383/

1 stars 1 forks source link

why use dbp props? #3

Open VladimirAlexiev opened 2 years ago

VladimirAlexiev commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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