glam/frontend/public/schemas/20251121/linkml/modules/classes/AddressComponent.yaml
kempersc 2d09776856 Refactor StorageCondition schema: Migrate compliance_status to has_or_had_status with ComplianceStatus class
- Removed compliance_status slot and replaced it with has_or_had_status.
- Updated has_or_had_status to use ComplianceStatus for structured representation.
- Adjusted examples to reflect new structure for compliance status.
- Updated documentation to indicate migration and provide details on the ComplianceStatus class.
2026-01-22 16:22:16 +01:00

227 lines
7.7 KiB
YAML

# AddressComponent - Generic address component class
# Source-agnostic representation of individual address parts
# Refactored: 2026-01-12 - Removed Google Maps-specific references per user guidance
# Rule 38 compliant: All slots imported from modules/slots/
id: https://nde.nl/ontology/hc/classes/AddressComponent
name: AddressComponent
title: AddressComponent
prefixes:
linkml: https://w3id.org/linkml/
hc: https://nde.nl/ontology/hc/
schema: http://schema.org/
vcard: http://www.w3.org/2006/vcard/ns#
locn: http://www.w3.org/ns/locn#
imports:
- linkml:types
# Centralized slots (Rule 38 compliant)
- ../slots/long_name
- ../slots/short_name
# REMOVED 2026-01-22: ../slots/component_type - migrated to has_or_had_type + ComponentType (Rule 53)
- ../slots/has_or_had_type
- ./ComponentType
- ./ComponentTypes
default_range: string
classes:
AddressComponent:
class_uri: hc:AddressComponent
description: |
A single component of a structured address.
**PURPOSE**:
AddressComponent represents one discrete element of an address, such as
the street number, street name, city, region, or country. This enables:
- Parsing addresses from various sources into standardized components
- Normalizing address data from different formats/APIs
- Supporting multilingual address representations (long_name vs short_name)
**COMPONENT STRUCTURE**:
Each AddressComponent has:
- `long_name`: Full form of the value (e.g., "Netherlands", "Noord-Holland")
- `short_name`: Abbreviated form (e.g., "NL", "NH") - may equal long_name
- `has_or_had_type`: Semantic type(s) via ComponentType (e.g., Country, Locality)
**STANDARD COMPONENT TYPES**:
| Type | Description | Example long_name | Example short_name |
|------|-------------|-------------------|-------------------|
| `street_number` | House/building number | "1", "221B" | same |
| `route` | Street/road name | "Museumstraat" | same |
| `locality` | City/town/village | "Amsterdam" | same |
| `postal_code` | ZIP/postal code | "1071 XX" | same |
| `subregion` | County/district | "Amsterdam" | same |
| `region` | State/province | "Noord-Holland" | "NH" |
| `country` | Country | "Netherlands" | "NL" |
| `premise` | Building/complex name | "Rijksmuseum" | same |
| `subpremise` | Unit/floor/suite | "Floor 3" | "3" |
**RELATIONSHIP TO Address CLASS**:
AddressComponent is used for:
1. **Parsing workflows**: Breaking down raw address strings into components
2. **Normalization**: Standardizing addresses from different sources
3. **Intermediate representation**: Before constructing a full Address object
The Address class provides the final, ontology-aligned representation with
dedicated slots (street_name, locality, region, country_name, etc.).
```
Raw Address Data (any source)
└── parse → AddressComponent[] # Intermediate representation
└── normalize → Address # vCard/LOCN aligned
```
**USAGE EXAMPLES**:
```yaml
# Street number component (MIGRATED 2026-01-22: Rule 53)
- long_name: "1"
short_name: "1"
has_or_had_type: [StreetNumber]
# Province with abbreviation
- long_name: "Noord-Holland"
short_name: "NH"
has_or_had_type: [Region]
# Country with ISO code
- long_name: "Netherlands"
short_name: "NL"
has_or_had_type: [Country]
```
**SOURCE-AGNOSTIC DESIGN**:
This class is designed to work with addresses from ANY source:
- Website scraping
- Registry data (ISIL, KvK, etc.)
- API responses (when normalized)
- Manual data entry
- OCR/document extraction
API-specific raw data formats are handled by Endpoint classes.
close_mappings:
- locn:AddressRepresentation
related_mappings:
- schema:PostalAddress
- vcard:Address
slots:
- long_name
- short_name
# REMOVED 2026-01-22: component_type - migrated to has_or_had_type + ComponentType (Rule 53)
- has_or_had_type
attributes:
types:
range: string
multivalued: true
inlined_as_list: true
description: Address component types (alias for component_type for backward compatibility with Google Maps API format)
slot_usage:
long_name:
range: string
required: false
description: Full form of the address component value
examples:
- value: "Netherlands"
description: Country full name
- value: "Noord-Holland"
description: Province full name
- value: "Museumstraat"
description: Street name
short_name:
range: string
required: false
description: Abbreviated or short form of the component value (may equal long_name)
examples:
- value: "NL"
description: ISO 3166-1 alpha-2 country code
- value: "NH"
description: Province abbreviation
- value: "Museumstraat"
description: Same as long_name when no abbreviation exists
# MIGRATED 2026-01-22: component_type → has_or_had_type + ComponentType (Rule 53)
has_or_had_type:
description: |
Semantic type(s) of this address component.
MIGRATED from component_type per slot_fixes.yaml (Rule 53, 2026-01-22).
Uses ComponentType class hierarchy for structured classification.
range: ComponentType
multivalued: true
inlined_as_list: true
required: false
examples:
- value: StreetNumber
description: House/building number
- value: Locality
description: City or town
- value: Region
description: State or province
- value: Country
description: Country
comments:
- Source-agnostic representation of address components
- Use for parsing/normalization workflows before constructing Address objects
- Component types follow common geographic hierarchy conventions
- Multiple types allowed for components that serve multiple roles
see_also:
- https://nde.nl/ontology/hc/classes/Address
- https://www.w3.org/ns/locn#Address
examples:
# MIGRATED 2026-01-22: component_type → has_or_had_type + ComponentType (Rule 53)
- value:
long_name: "1"
short_name: "1"
has_or_had_type: [StreetNumber]
description: Street number component
- value:
long_name: "Museumstraat"
short_name: "Museumstraat"
has_or_had_type: [Route]
description: Street name component
- value:
long_name: "Amsterdam"
short_name: "Amsterdam"
has_or_had_type: [Locality]
description: City component
- value:
long_name: "Noord-Holland"
short_name: "NH"
has_or_had_type: [Region]
description: Province component with abbreviation
- value:
long_name: "Netherlands"
short_name: "NL"
has_or_had_type: [Country]
description: Country component with ISO code
- value:
long_name: "1071 XX"
short_name: "1071 XX"
has_or_had_type: [PostalCode]
description: Dutch postal code component
annotations:
specificity_score: 0.35
specificity_rationale: "Generic address parsing component. Broadly applicable across all address sources and custodian types."
custodian_types: '["*"]'
custodian_types_rationale: "Any custodian with address data may use address components during parsing/normalization."