How to read this document: Each row shows one LHC field and its closest equivalents in Legal Schema.org markup (for search engines) and HSDS 3.0 (for directory interchange). The match column tells you whether it's a direct mapping, a partial fit, an LHC extension with no equivalent, or not applicable for that standard.
DIRECT — maps cleanly to an existing field
PARTIAL — concept exists but structure or values differ
LHC EXT — LHC adds this; no equivalent in the other standard
N/A — not applicable for this standard
Organizations
| LHC Field | Legal Schema.org | HSDS 3.0 | Match / Notes |
|---|---|---|---|
| org_name | schema:name | organization.name | DIRECT — all three align |
| url | schema:url | organization.website | DIRECT |
| org_description | schema:description | organization.description | DIRECT |
| jurisdiction_state_code | schema:areaServed → AdministrativeArea | service_area.extent | PARTIAL — Schema.org uses structured AdminArea objects; HSDS uses a service_area table with geographic descriptions. LHC uses flat state codes. |
| jurisdiction (detail) | schema:areaServed → name array | service_area (linked to service) | PARTIAL — HSDS puts service_area on services, not orgs. Schema.org puts areaServed on both. |
| org_type | No direct equivalent. Closest: schema:@type (always "Organization" or "LegalService") | No direct equivalent. Use attribute with taxonomy | LHC EXT — Neither standard classifies org type. HSDS's attribute table could carry it via a custom taxonomy. |
| audience_served | schema:audience | eligibility_description (free text on service) + attribute (via taxonomy) | PARTIAL — Schema.org has an audience field but with free text. HSDS has only free-text eligibility. LHC adds the controlled vocabulary. |
| offering_type | No direct equivalent | No direct equivalent. Service-level concept. | LHC EXT — Org-level summary of what services they offer. In HSDS, this lives at the service level. |
| list_codes | schema:knowsAbout → taxonomy.legal URLs | service > attributes with LIST taxonomy | DIRECT — Schema.org uses knowsAbout with taxonomy.legal URLs. HSDS uses the attribute/taxonomy_term system to attach any taxonomy including LIST. |
| languages | schema:knowsLanguage | language table (linked to org or service) | DIRECT — All three support languages. LHC uses ISO 639 codes; HSDS uses a language object with name + code; Schema.org uses Language objects. |
| phone | schema:telephone | phone table (linked) | DIRECT |
| schema:email | organization.email | DIRECT | |
| address_* | schema:address → PostalAddress | address table (linked to location) | DIRECT — HSDS puts addresses on locations, not directly on orgs. |
| org_business_model | No equivalent | No equivalent | LHC EXT |
| jurisdiction_level | No equivalent | service_area.extent_type (partially) | LHC EXT — Useful for filtering; no clean equivalent elsewhere. |
Services
| LHC Field | Legal Schema.org | HSDS 3.0 | Match / Notes |
|---|---|---|---|
| service_name | schema:name (on Service) | service.name | DIRECT |
| org_id | schema:provider → @id ref | service.organization_id | DIRECT |
| service_url | schema:serviceUrl (in ServiceChannel) | service.url | DIRECT |
| service_description | schema:description | service.description | DIRECT |
| service_type self-help, brief-help, some-help, full-help, etc. |
No equivalent. Schema.org doesn't classify depth of legal service. | No equivalent. Could use attribute with custom taxonomy. | LHC EXT — This is the core innovation. Neither standard distinguishes "how much help you get." LHC's service_type is a legal-domain-specific classification that fills a major gap. |
| audience_served | schema:audience | service.eligibility_description (free text) + attribute with taxonomy | PARTIAL — Same as org-level mapping. LHC provides the controlled vocabulary. |
| list_codes | schema:knowsAbout | service > attributes with LIST taxonomy | DIRECT |
| jurisdiction | schema:areaServed | service_area | DIRECT |
| delivery_mode in-person, phone, video, etc. |
Partially in ServiceChannel (serviceUrl, servicePhone, serviceLocation) | No direct field. HSDS uses service_at_location for physical, and phone table for phone access. | PARTIAL — Both standards model delivery implicitly through contact channels and locations. LHC makes it an explicit, taggable field. |
| languages | schema:availableLanguage | language table | DIRECT |
| phases_served understanding-rights, application-filing, responding-to-action, etc. |
No equivalent | No equivalent | LHC EXT — Legal-domain-specific. No general-purpose directory standard models case phase. Critical for legal service matching. |
| capacity | No equivalent | service.status (active/inactive/defunct/temporarily_closed) + capacity object (v3.0) | PARTIAL — HSDS 3.0 added a capacity object with available/maximum counts. LHC's capacity field is simpler (accepting/waitlist/limited) — appropriate for legal aid where exact counts don't apply. |
| cost | No equivalent | service.fees_description (free text) + cost_option table | PARTIAL — HSDS has a structured cost_option object. LHC uses a simple single-select (free/sliding-scale/etc.) which is more practical for legal aid. |
| eligibility_notes | No equivalent | service.eligibility_description | DIRECT — This maps exactly to HSDS's eligibility_description free-text field. |
| opening_hours | schema:hoursAvailable (in ContactPoint) | schedule table (RFC 5545 RRULES) | PARTIAL — HSDS uses formal RRULE syntax. LHC uses free text. Schema.org uses structured OpeningHoursSpecification. |
Content Index (Knowledge Base)
Neither HSDS nor core Schema.org was designed for indexing legal content. The Legal Schema.org markup project added an "Articles, FAQs, and Guides" section that partially covers this. HSDS has no content/knowledge-base equivalent at all.
| LHC Field | Legal Schema.org | HSDS 3.0 | Match / Notes |
|---|---|---|---|
| title | schema:name / schema:headline | N/A | DIRECT to Schema.org. HSDS doesn't model content. |
| url | schema:url | N/A | DIRECT |
| description | schema:description | N/A | DIRECT |
| jurisdiction | schema:spatialCoverage | N/A | DIRECT — Legal Schema.org uses spatialCoverage for article jurisdiction. |
| list_codes | schema:about → taxonomy.legal URLs | N/A | DIRECT — Legal Schema.org uses "about" linking to LIST taxonomy URLs. |
| languages | schema:inLanguage | N/A | DIRECT |
| publisher | schema:publisher → @id ref | N/A | DIRECT |
| last_reviewed_date | schema:dateModified | N/A | DIRECT |
| content_format written-guide, faq, document-assembly, etc. |
schema:@type = Article / FAQPage. Partial via schema:encodingFormat | N/A | PARTIAL — Schema.org distinguishes Article from FAQPage at the type level. LHC's content_format is more granular, covering document-assembly, decision-tree, calculator, etc. which have no Schema.org types. |
| content_level public, professional |
schema:audience (on Article) | N/A | PARTIAL — Schema.org audience can indicate intended reader but isn't structured as public/professional. |
| legal_position neutral, plaintiff, defendant |
No equivalent | N/A | LHC EXT — Legal-domain-specific innovation. No general standard models plaintiff/defendant orientation of content. |
| legal_content_type rights-explainer, process-guide, form-instructions, etc. |
No equivalent | N/A | LHC EXT — Legal-domain-specific. Classifies what kind of legal help the content provides. |
| jurisdiction_depth federal, state-specific, court-specific, etc. |
No equivalent | N/A | LHC EXT — How location-specific is this content? Critical for knowing if a guide from another state is still useful. |
| phases_served | No equivalent | N/A | LHC EXT |
| currency_status | No equivalent (dateModified exists but not a staleness flag) | N/A | LHC EXT |
| audience_served | schema:audience | N/A | PARTIAL — Same as org/service level. |
Summary: where LHC extends beyond existing standards
The fields that are direct mappings to both Schema.org and HSDS cover the basics: names, URLs, descriptions, contact info, addresses, languages, jurisdiction, legal issue codes. This is the foundation — if your data has these, it's already interoperable.
The fields where LHC adds controlled vocabularies to what existing standards leave as free text:
| LHC Field | What it adds |
|---|---|
| audience_served | Standard slugs for Schema.org's audience and HSDS's eligibility_description |
| delivery_mode | Explicit tagging of what Schema.org models implicitly via ServiceChannel |
| capacity | Simplified version of HSDS 3.0's capacity object, suited to legal aid |
| cost | Simplified version of HSDS's cost_option, suited to legal aid |
The fields that are entirely new — legal-domain-specific innovations with no equivalent in either standard:
| LHC Field | Why it matters |
|---|---|
| service_type | "How much help will I get?" — the core referral expectation-setting field |
| phases_served | "Where am I in my legal journey?" — matches services and content to case stage |
| legal_position | "Am I the plaintiff or defendant?" — matches content to the person's role |
| legal_content_type | "What kind of legal help is this content?" — rights explainer vs. form instructions vs. process guide |
| content_format | "What kind of artifact is this?" — more granular than Schema.org's Article/FAQPage |
| jurisdiction_depth | "How location-specific is this?" — is a guide from another state still useful? |
| currency_status | "Is this content still reliable?" — flags stale legal info |
| org_type | "What kind of organization is this?" — legal aid vs court vs law library |
The positioning story: LHC Standards are a legal-domain profile that sits on top of Schema.org and HSDS. For the basics (names, contacts, locations, languages), we map directly to both. For eligibility and delivery, we add the controlled vocabularies those standards left open. For legal-specific matching (service depth, case phase, legal position, content type), we add fields that general-purpose standards never needed. This isn't competing — it's completing.
Implementation note: If you're already publishing HSDS data, adding LHC fields means adding custom
attribute entries with LHC taxonomy terms. If you're already doing Schema.org markup, adding LHC means using the standard slugs as values in your existing audience, availableLanguage, and knowsAbout fields, and adding additionalProperty entries for the legal-domain-specific fields that Schema.org doesn't cover.