I. Use Case Description | |
Use Case Name | Using GLEIF data with FIBO |
Use Case Identifier | BE-01 |
Source | BE Content Team |
Point of Contact | |
SEC-Creation / Revision Date | 6/11/2019 / 6/25/2019 |
Associated Documents | |
II. Use Case Summary | |
Goal | LEI is a standard for identifying banks and companies actively involved in the financial industry. Regulators across the globe increasingly require financial market participants to use LEI. G20 and Financial Stability Board and many regulators require businesses to acquire LEI as soon as possible. LEI adoption among firms continues to increase on a daily basis. The GLEIF (Global Legal Entity Identifier Foundation) supports this increased adoption by continuing to focus on further optimizing the quality, reliability, and usability of LEI data. There are two goal of this use case:
|
Requirements | State any requirement(s)specific to this use case, including any capabilities from a business architecture or process model that the use case supports, any metrics or other reporting requirements, etc., including any reference identifier for the requirement(s), as applicable |
Scope |
|
Priority | Identify the priority of the use case (with respect to other use cases for the project) |
Stakeholders |
|
Description | Summarize the use case, capturing the essential objectives (no longer than a page), including a quick overview, restated goals, and principal actor(s).
User stories, if applicable, and any narrative mapped from those user stories to usage scenarios should be included in the Usage Scenarios section, below. |
Actors / Interfaces | List actors: people, systems, knowledge bases, repositories, and other data resources, services, sensors, or other “things” outside the system that either act on the system (primary actors) or are acted on by the system (secondary actors). Primary actors are those that invoke the use case and benefit from the result. Identify the primary actor and briefly describe role.
Any actor that is external to or outside the control of the use case owner should be further described under Resources, below. |
Pre-conditions | Identify any assumptions about the state of the system that must be met for the trigger (below) to initiate the use case. Any assumptions about the state of other related systems can also be stated here. List all preconditions. |
Post-conditions | Provide any conditions that will be true of the state of the system after the use case has been completed. |
Triggers | Describe in detail the event or events that initiate the execution of this use case. Triggers can be external, temporal, or internal. They can be single events or a complex event that indicates that some set of conditions has been met. |
Performance Requirements | List any known performance-specific requirements – timing and sizing (volume, frequency, etc.), maintainability, reusability, other “-ilities”, etc. |
Assumptions |
|
Open Issues |
|
III. Usage Scenarios
Provide at least two usage scenarios that flesh out the requirements outlined in the summary, including identification of requirements specific to any envisioned ontology or semantically-driven service or application. Scenarios should be described as narrative, with supporting diagrams as appropriate. In an Agile process, every user story relevant to the use case should be included and elaborated/rolled up into one or more usage scenarios, with a clear mapping from the user story to the scenario it is integrated in or mapped to.
IV. Basic Flow of Events
Narrative: Often referred to as the primary scenario or course of events, the basic flow defines the process/data/work flow that would be followed if the use case were to follow its main plot from start to end. Error states or alternate states that might occur as a matter of course in fulfilling the use case should be included under Alternate Flow of Events, below. The basic flow should provide any reviewer a quick overview of how an implementation is intended to work. A summary paragraph should be included that provides such an overview (which can include lists, conversational analysis that captures stakeholder interview information, etc.), followed by more detail expressed via the table structure.
In cases where the user scenarios are sufficiently different from one another, it may be helpful to describe the flow for each scenario independently, and then merge them together in a composite flow.
Basic / Normal Flow of Events | |||
Step | Actor (Person) | Actor (System) | Description |
|
|
| |
|
|
| |
|
|
| |
V. Alternate Flow of Events
Narrative: The alternate flow defines the process/data/work flow that would be followed if the use case enters an error or alternate state from the basic flow defined, above. A summary paragraph should be included that provides an overview of each alternate flow, followed by more detail expressed via the table structure.
Alternate Flow of Events | |||
Step | Actor (Person) | Actor (System) | Description |
|
|
| |
|
|
| |
|
|
| |
VI. Use Case and Activity Diagram(s)
Provide the primary use case diagram, including actors, and a high-level activity diagram to show the flow of primary events that include/surround the use case. Subordinate diagrams that map the flow for each usage scenario should be included as appropriate
VII. Competency Questions
Provide at least 2 competency questions that you will ask of the vocabulary/ontology/knowledge base to implement this use case, including example answers to the questions.
Describe at least one way you expect to use the semantics and/or provenance to propose an answer to the questions. Include an initial description of why the semantics and/or provenance representation and reasoning provides an advantage over other obvious approaches to the problem. (optional – depending on the use case and need for supporting business case).
VIII. Resources
In order to support the capabilities described in this Use Case, a set of resources must be available and/or configured. These resources include the set of actors listed above, with additional detail, and any other ancillary systems, sensors, or services that are relevant to the problem/use case.
Knowledge Bases, Repositories, or other Data Sources
Data | Type | Characteristics | Description | Owner | Source | Access Policies & Usage |
apple-lei.xml | (remote, local/in situ, etc.) | e.g. – no cloud cover | Short description of the dataset, possibly including rationale of the usage characteristics | GLEIF |
| |
| Apple-GLEIF.rdf | GLEIF | |||||
Python "mapping" code |
|
|
| Makolab S.A. |
| |
| apple-lei-fibo.ttl | ||||||
| A part of FIBO BE used to model LEI |
External Ontologies, Vocabularies, or other Model Services
Resource | Language | Description | Owner | Source | Describes/Uses | Access Policies & Usage |
(ontology, vocabulary, or model name) | (ontology language and syntactic form, e.g., RDFS - N3) | If the service is one that runs a given ontology or model-based application at a given frequency, state that in addition to the basic description |
| Source (link to the registry or directly to the ontology, vocabulary, or model where that model is maintained, if available) | List of one or more data sources described by and/or used by the model |
|
|
Other Resources, Service, or Triggers (e.g., event notification services, application services, etc.)
Resource | Type | Description | Owner | Source | Access Policies & Usage |
(sensor or external service name) |
| Include a description of the resource as well as availability, if applicable | Primary owner of the service | Application or service URL; if subscription based, include subscription and any subscription owner |
|
|
|
|
|
|
|
Classes
fibo-fnd-aap-agt:AutonomousAgent
----fibo-be-le-lp:LegalPerson
--------fibo-be-le-lp:LegalEntity
--------fibo-be-le-lp:LegallyCompetentNaturalPerson
----fibo-fnd-aap-ppl:Person
--------fibo-be-le-lp:LegallyCompetentNaturalPerson
--------fibo-fnd-aap-ppl:Adult
------------fibo-fnd-aap-ppl:IncapacitatedAdult
------------fibo-fnd-aap-ppl:LegallyCapableAdult
----fibo-fnd-org-org:Organization
--------fibo-fnd-org-fm:FormalOrganization
------------fibo-be-le-lp:LegalEntity
--------fibo-fnd-org-fm:InformalOrganization
----fibo-fnd-pty-pty:IndependentParty
fibo-fnd-agr-agr:Agreement
----fibo-fnd-agr-ctr:Contract
fibo-fnd-agr-agr:Commitment
fibo-fnd-agr-ctr:ContractualElement
fibo-fnd-arr-arr:Arrangement
----fibo-fnd-arr-arr:Collection
--------fibo-fbc-fct-ra:Registry
------------fibo-fbc-fct-breg:BusinessRegistry
----fibo-fnd-arr-arr:Scheme
--------fibo-fnd-arr-cls:ClassificationScheme
------------fibo-be-le-lei:EntityLegalFormScheme
--------fibo-fnd-arr-id:IdentificationScheme
------------fibo-be-le-fbo:OrganizationIdentificationScheme
----------------fibo-be-corp-corp:RegistrationIdentifierScheme
----------------fibo-be-le-lei:LegalEntityIdentifierScheme
--------fibo-fnd-arr-id:IndexingScheme
------------fibo-fnd-plc-adr:AddressingScheme
----fibo-fnd-arr-cd:CodeSet
--------fibo-be-le-lei:EntityLegalFormScheme
----fibo-fnd-arr-lif:Lifecycle
fibo-fnd-dt-fd:CombinedDateTime
fibo-fnd-dt-fd:TimeInstant
----fibo-fnd-dt-fd:Date
fibo-fnd-dt-fd:TimeInterval
----fibo-fnd-dt-fd:DatePeriod
----fibo-fnd-dt-fd:Duration
fibo-fnd-dt-oc:Occurrence
----fibo-fnd-arr-lif:LifecycleEventOccurrence
----fibo-fnd-arr-lif:LifecycleOccurrence
----fibo-fnd-arr-lif:LifecycleStageOccurrence
fibo-fnd-dt-oc:OccurrenceKind
----fibo-fnd-arr-lif:LifecycleEvent
fibo-fnd-gao-gl:Goal
fibo-fnd-law-cor:Constitution
----fibo-fnd-law-cor:GovernmentalConstitution
fibo-fnd-law-cor:Law
fibo-fnd-law-jur:Jurisdiction
fibo-fnd-law-jur:LegalSystem
fibo-fnd-law-lcap:LegalConstruct
----fibo-fnd-law-lcap:LegalCapacity
--------fibo-fbc-fct-ra:RegistrationCapacity
--------fibo-fnd-law-lcap:LiabilityCapacity
fibo-fnd-pas-pas:Service
----fibo-fbc-fct-ra:RegistrationService
fibo-fnd-plc-fac:Capability
fibo-fnd-pty-rl:Role
fibo-fnd-pty-rl:ThingInRole
----fibo-fnd-pty-rl:AgentInRole
--------fibo-fnd-pty-pty:PartyInRole
------------fibo-fbc-fct-ra:Registrar
------------fibo-fnd-agr-ctr:ContractParty
----fibo-fnd-plc-fac:Facility
----fibo-fnd-plc-fac:Site
----fibo-fnd-pas-pas:ServiceProvider
--------fibo-fbc-fct-ra:RegistrationAuthority
------------fibo-fbc-fct-breg:BusinessRegistrationAuthority
fibo-fnd-rel-rel:Reference
----fibo-fbc-fct-ra:RegistryEntry
--------fibo-fbc-fct-breg:BusinessRegistryEntry
----fibo-fnd-arr-cls:Classifier
--------fibo-be-le-lei:EntityLegalForm
--------fibo-fnd-arr-lif:LifecycleStage
------------fibo-fbc-fct-breg:EntityStatus
------------fibo-fbc-fct-breg:RegistrationStatus
----fibo-fnd-arr-cd:CodeElement
--------fibo-be-le-lei:EntityLegalFormIdentifier
--------fibo-fbc-fct-breg:EntityValidationLevel
--------fibo-fbc-fct-breg:RegistrationAuthorityCode
----fibo-fnd-arr-id:Identifier
--------fibo-be-le-fbo:OrganizationIdentifier
------------fibo-be-corp-corp:RegistrationIdentifier
------------fibo-be-le-lei:LegalEntityIdentifier
--------fibo-fbc-fct-breg:RegistrationAuthorityCode
--------fibo-fbc-fct-ra:RegistryIdentifier
----fibo-fnd-arr-id:Index
--------fibo-fnd-plc-adr:Address
------------fibo-fnd-plc-adr:PhysicalAddress
----------------fibo-be-le-fbo:RegisteredAddress
lcc-cr:Country
lcc-cr:CountrySubdivision
lcc-cr:GeographicRegion
lcc-cr:Location
----fibo-fnd-plc-loc:PhysicalLocation
Properties
fibo-be-le-lei:hasLegalFormAbbreviation
fibo-be-le-lei:hasTransliteratedLegalFormAbbreviation
fibo-be-le-lp:isRecognizedIn
----fibo-be-le-lp:isOrganizedIn
fibo-fbc-fct-breg:hasAddressLine1
fibo-fbc-fct-breg:hasAddressLine2
fibo-fbc-fct-breg:hasAddressLine3
fibo-fbc-fct-breg:hasAddressLine4
fibo-fbc-fct-breg:hasCity
fibo-fbc-fct-breg:hasPostalCode
fibo-fbc-fct-breg:hasValidationLevel
fibo-fbc-fct-ra:hasRegistrationDate
----fibo-fbc-fct-breg:hasInitialRegistrationDate
----fibo-fbc-fct-breg:hasRegistrationStatusRevisionDate
----fibo-fbc-fct-breg:hasRenewalDate
----fibo-fbc-fct-breg:hasValidationDate
fibo-fbc-fct-ra:isRegisteredBy
fibo-fbc-fct-ra:isRegisteredIn
fibo-fbc-fct-ra:isRegistrationAuthorityFor
fibo-fbc-fct-ra:registers
fibo-fnd-aap-agt:hasName
----fibo-be-le-lei:hasTransliteratedName
----fibo-fbc-fct-breg:hasRegistryName
----fibo-fnd-rel-rel:hasFormalName
--------fibo-fnd-rel-rel:hasLegalName
------------fibo-fbc-fct-breg:hasPriorLegalName
----fibo-fnd-rel-rel:wasFormerlyKnownAs
--------fibo-fbc-fct-breg:hasPriorLegalName
fibo-fnd-aap-agt:identifies
fibo-fnd-aap-agt:isIdentifiedBy
fibo-fnd-aap-ppl:hasGender
fibo-fnd-agr-ctr:isAssignable
fibo-fnd-dt-fd:hasDateValue
fibo-fnd-dt-fd:hasDurationValue
fibo-fnd-dt-oc:exemplifies
fibo-fnd-dt-oc:hasDescription
fibo-fnd-dt-oc:hasEventDateValue
fibo-fnd-law-jur:appliesIn
fibo-fnd-law-jur:hasReach
fibo-fnd-org-fm:isDomiciledIn
fibo-fnd-plc-fac:isSituatedAt
fibo-fnd-plc-fac:situates
fibo-fnd-plc-loc:isLocatedAt
fibo-fnd-pty-rl:playsRole
fibo-fnd-rel-rel:comprises
----fibo-fbc-fct-ra:hasRegistryEntry
----fibo-fnd-agr-ctr:hasContractualElement
fibo-fnd-rel-rel:confers
fibo-fnd-rel-rel:designates
----fibo-fnd-rel-rel:appoints
fibo-fnd-rel-rel:governs
fibo-fnd-rel-rel:has
----fibo-fnd-dt-fd:hasDuration
----fibo-be-le-lei:hasLegalForm
----fibo-fbc-fct-breg:hasCountry
----fibo-fbc-fct-breg:hasEntityStatus
----fibo-fbc-fct-breg:hasSubdivision
----fibo-fnd-aap-ppl:hasCitizenship
----fibo-fnd-aap-ppl:hasPlaceOfBirth
----fibo-fnd-dt-fd:hasDate
--------fibo-fnd-aap-ppl:hasDateOfBirth
--------fibo-fnd-dt-fd:hasEndDate
--------fibo-fnd-dt-fd:hasStartDate
------------fibo-fnd-pty-pty:hasCommencementDate
--------fibo-fnd-agr-ctr:hasEffectiveDate
--------fibo-fnd-agr-ctr:hasExecutionDate
--------fibo-fnd-dt-oc:hasEventDate
----fibo-fnd-dt-fd:hasDatePeriod
--------fibo-fnd-dt-bd:holdsDuring
----fibo-fnd-law-lcap:hasCapacity
----fibo-fnd-pty-pty:hasPartyInRole
--------fibo-fnd-agr-ctr:hasContractParty
----fibo-fnd-pty-rl:hasRole
----fibo-fnd-plc-adr:hasAddress
--------fibo-be-le-fbo:hasPrimaryAddress
--------fibo-be-le-fbo:hasRegisteredAddress
------------fibo-be-le-lei:hasAddressOfLegalFormation
----fibo-fnd-rel-rel:hasIdentity
--------fibo-fnd-pty-rl:isPlayedBy
----fibo-fnd-rel-rel:hasRepresentation
--------fibo-fnd-rel-rel:hasDefinition
fibo-fnd-rel-rel:hasMember
fibo-fnd-rel-rel:hasPart
----fibo-fnd-arr-lif:hasStage
--------fibo-fbc-fct-breg:hasRegistrationStatus
fibo-fnd-rel-rel:hasTag
fibo-fnd-rel-rel:involves
fibo-fnd-rel-rel:isAppointedBy
fibo-fnd-rel-rel:isCharacterizedBy
----fibo-fnd-arr-lif:hasLifecycle
fibo-fnd-rel-rel:isConferredBy
fibo-fnd-rel-rel:isConferredOn
----fibo-fnd-law-lcap:isCapacityOf
fibo-fnd-rel-rel:isGovernedBy
fibo-fnd-rel-rel:isIncludedIn
fibo-fnd-rel-rel:isManagedBy
fibo-fnd-rel-rel:isMemberOf
fibo-fnd-rel-rel:isPartOf
----fibo-fnd-arr-lif:isStageOf
fibo-fnd-rel-rel:isProvidedBy
----fibo-fnd-pas-pas:isProvisionedBy
fibo-fnd-rel-rel:manages
fibo-fnd-rel-rel:provides
----fibo-fnd-pas-pas:provisions
fibo-fnd-rel-rel:refersTo
----fibo-fnd-arr-id:isIndexTo
----fibo-fnd-rel-rel:appliesTo
----fibo-fnd-rel-rel:characterizes
--------fibo-fnd-arr-lif:isLifecycleOf
----fibo-fnd-rel-rel:classifies
----fibo-fnd-rel-rel:represents
--------fibo-fnd-rel-rel:defines
--------fibo-fnd-rel-rel:denotes
fibo-fnd-utl-av:abbreviation
fibo-fnd-utl-av:adaptedFrom
fibo-fnd-utl-av:definitionOrigin
fibo-fnd-utl-av:explanatoryNote
fibo-fnd-utl-av:synonym
fibo-fnd-utl-av:usageNote
IX. References and Bibliography
List all reference documents – policy documents, regulations, standards, de-facto standards, glossaries, dictionaries and thesauri, taxonomies, and any other reference materials considered relevant to the use case
X. Notes
There is always some piece of information that is required that has no other place to go. This is the place for that information.