Unused Data Properties

[jziemer2]

Pertains to FIBO Prod (warning not an error and not urgent)
FIBO is a domain ontology and business model - it is mostly class-level.
I understand and support that recent developments don't add data properties, and the few existing ones are grandfathered.

The list below from the PowerDesigner data model check shows unsued Data Items (= object properties). For example, fibo-der-rtd-irswp:hasFloatingRateSpread has no domain and is not used in any class restriction.
I would remove these data properties (or even all data properties).

Checking data item ...

• Data Item name uniqueness
• Data Item code uniqueness
• Data Item not used
  Warning The following Data Items are not attached to any entities:
  -> Data Item 'fibo-be-le-lei:hasOwnershipPercentage' ()
  -> Data Item 'fibo-be-ptr-ptr:dateTradingFrom' ()
  -> Data Item 'fibo-der-rtd-irswp:hasFloatingRateSpread' ()
  -> Data Item 'fibo-der-rtd-irswp:hasRateMultiplier' ()
  -> Data Item 'fibo-fbc-fct-breg:hasAlternativeLanguageLegalName' ()
  -> Data Item 'fibo-fbc-fct-breg:hasAutomaticallyTransliteratedLegalName' ()
  -> Data Item 'fibo-fbc-fct-breg:hasPreferredTransliteratedLegalName' ()
  -> Data Item 'fibo-fbc-fct-breg:hasPriorLegalName' ()
  -> Data Item 'fibo-fbc-fct-breg:hasRenewalDate' ()
  -> Data Item 'fibo-fbc-fct-breg:hasTradingOrOperationalName' ()
  -> Data Item 'fibo-fbc-fct-breg:hasTransliteratedLegalName' ()
  -> Data Item 'fibo-fbc-fct-breg:hasValidationDate' ()
  -> Data Item 'fibo-fbc-fi-ip:hasTradingVolume' ()
  -> Data Item 'fibo-fbc-pas-fpas:hasNominalNumberOfUnits' ()
  -> Data Item 'fibo-fbc-pas-fpas:hasOfferingUnits' ()
  -> Data Item 'fibo-fnd-dt-oc:hasEventDateValue' ()
  -> Data Item 'fibo-fnd-plc-vrt:hasURL' ()
  -> Data Item 'fibo-fnd-plc-vrt:hasWebsite' ()
  -> Data Item 'fibo-fnd-rel-rel:hasAlias' ()
  -> Data Item 'fibo-fnd-rel-rel:hasCommonName' ()
  -> Data Item 'fibo-fnd-rel-rel:hasFormalName' ()
  -> Data Item 'fibo-fnd-rel-rel:wasFormerlyKnownAs' ()
  -> Data Item 'fibo-fnd-utl-alx:hasNumberOfEntries' ()
  -> Data Item 'fibo-ind-ei-ei:hasMinimumLegalWorkingAge' ()
  -> Data Item 'fibo-sec-sec-iss:hasSeries' ()
  -> Data Item 'fibo-sec-sec-iss:hasSubscriptionAmount' ()
  -> Data Item 'fibo-sec-sec-iss:isOverAlloted' ()

(removed lcc and skos from the list)

[ElisaKendall]

Hi Jurgen,

Did you check to see if they are used in individuals? Many of these are needed for GLEIF LEI content, for example. Others will be used in securities examples - and the LCC and SKOS properties should be ignored, as they are in other standards.

[rivettp]

Generally I would comment that:

• data properties are important: if necessary we should add more, not remove them all;
• whether or not something has a domain or a restriction doesn't mean it is not "used" - if it's part of FIBO, our users may have used it;
• as @ElisaKendall says, a good indication is whether our exemplary Individuals have made use of them, though we don't necessarily have complete coverage via those Individuals;
• some generic properties, especially those in the Relations ontology, are specifically designed to apply to lots of classes and hence have no domain. That does not make them any less useful: hasCommonName is a great example;
• many might be addressed by not removing the property but including it in Restrictions;
• AFAIK we don't have any style guideline or hygiene test encompassing this aspect (what should or should not be covered by Restrictions);
• clearly the last few (from lcc-cr and skos) are not even in scope for FIBO so could not be removed even if we wanted to: given that they're not even in FIBO, what made them appear in your report if they're not "used"?

That said, this report may have flagged some problems: but we should raise specific subsets of these as issues in their own right, assigned to the relevant Content Team - for example the two fibo-der-rtd-swp ones could be raised as an issue to be addressed by the DER content team.

As @ElisaKendall said, the ones in fibo-fbc-fct-breg are to represent what's in GLEIF registries, as is the first one. I'm very familiar with the GLEIF data and I know these are needed, assuming we want coverage of that data.

And I know the fibo-fnd-plc-vrt ones were only recently added.

[jziemer2]

Hi Elisa,
Not for all, but for some, I checked for any usage of the property in the Topbraid workspace. For example, fibo-fbc-fct-breg:hasAlternativeLanguageLegalName, fibo-der-rtd-irswp:hasFloatingRateSpread are also not used by individuals.
Furthermore, if an individual uses a data property, then the individual’s class should have a data property restriction defining the use. Not?

Agreed, Pete,
Ignore lcc and skos. The content team can tell whether they need the property and consider defining its use via a class restriction.

Jurgen

[ElisaKendall]

In many cases we have not added domains to make the properties more reusable. The two you've cited are needed for (1) mapping to the LEI data for the alternative language legal name property, which we have not used exhaustively, as Pete mentioned, and (2) floating rate spread we use in example IR swap examples that we have not yet posted to release, but are in work by the DER team.

Of the original list, the one in partnerships, dateTradingFrom is suspect simply due to its name, which doesn't correspond to our conventions (and has been there for as long as I can recall) - that ontology needs further work, although I didn't find an open JIRA issue against it. It includes an exhaustive categorization of kinds of partnerships, at least some of which don't exist as far as we can find in the US or EU. One of my clients has been doing some work in this area, and we may find a subject matter expert through them that can assist in sorting this out if it becomes a priority.

Having said this, that's the only property in your list that isn't needed as far as we are aware. It's possible that we need more restrictions that use these - we haven't had the bandwidth to add them to date, however.

[ElisaKendall]

FYI, to follow up on the partnerships issue, I've worked with my client to revamp that ontology to take a more intensional / pragmatic approach to the model based on kinds of partnerships that exist all over the world rather than based on an exhaustive classification scheme. The revisions, which are linked to pull request #1042 eliminate this one property as well as a number of classes that were either wrong (e.g., partnerships that are incorporated - such an animal, if it exists, would correspond to a US LLC or corporation by definition rather than partnership), or overly constrained such as partnership with general partners, requiring them all to have at least 2 general partners, which is true of a basic general partnership but not of others that have both general and limited partners. We checked UK as well as other country examples, including other European and Japanese examples, and minimized restrictions so that coverage was more flexible for variations world-wide. The update will make much more sense to FIBO users that are bankers and that need these definitions with respect to the kinds of entities they track. I hope you like the results :).

Because we are working towards a new baseline for FIBO on the standards side, we didn't deprecate the original classes fyi, but the partnerships ontology is only used in a handful of examples inside FIBO. It will become more important as we work through funds and the entities that manage them, however.