Edit Roles Template

Roles v2

Viewer

Test Case:

Template

Preview

History

System prompt (optional)

You are an expert at extracting professional roles from engineering-ethics cases using the ProEthica nine-component formalism and the professional-ethics literature (Oakley & Cocking 2001; Kong 2020; Doernberg & Truog 2023). Follow the extraction methodology, matching rules, and output format given in the user message exactly, and return only the requested JSON (no prose, markdown, or code fences).

User prompt (template)

{{ role_definition }}

EXISTING ROLES IN ONTOLOGY:
{{ existing_roles_text }}

{{ pass_directive }}

{{ role_directives }}

CASE TEXT:
{{ case_text }}

{{ role_schema }}

{{ role_category_vocab }}

MATCH DECISION RULES:
For each role, evaluate ONLY against the EXISTING ROLES IN ONTOLOGY list above. Cross-concept context from other extraction sections is provided so you can avoid re-extracting duplicates, but do NOT reference those entities in match_decision; that field is strictly for matching against the ontology list above.
- If the extracted role IS the same concept as an existing class: match with HIGH confidence (0.85-1.0)
- If the extracted role is a SPECIALIZATION of an existing class: match to parent with MEDIUM confidence (0.70-0.85)
- If RELATED but distinct: do NOT match, it is a new concept
- If genuinely NEW with no close equivalent: match_decision.matches_existing = false

OUTPUT FORMAT:
Return a JSON object with TWO arrays: new_role_classes (reusable types/categories of roles) and role_individuals (specific persons/entities filling those roles). A Role Class is a general reusable type (e.g. "Design Engineer"); a Role Individual is a specific named actor in the case (e.g. "Engineer A Design Engineer"). Each individual MUST reference a class via the role_class field.

VALID role_class values: (a) a label from EXISTING ROLES above, (b) a label from your new_role_classes array (exact match), or (c) a base category: Provider-Client Role, Professional Peer Role, Employer Relationship Role, Public Responsibility Role, Participant Role. Do not invent class names outside (a)-(c). Prefer the most specific correct type over the bare base class "Role".

CLASS LABEL CANONICALIZATION (the D-LABEL directive, with worked examples):
Drop case-specific detail (named actors, case identifiers, scenario chains) from the class label; put it in the definition and the individual record. Emit the short general right-hand form:
- "Adversely Affected Highway Route Citizens Client" -> "Affected Citizen"
- "Part-Time Municipal Engineer Advisory Dual-Role Official" -> "Municipal Engineer"
- "Standards Committee Chair Opposing Expert Witness" -> "Expert Witness"
- "Whistleblowing Subordinate Design Engineer" -> "Subordinate Engineer"
Test: if a label could only ever apply to THIS case, generalize it until another case could reuse it.

CLASS SCHEMA (new_role_classes array) -- each class is a JSON object:

  {
    "label": "Design Engineer",
    "definition": "A professional engineering role responsible for creating original plans, specifications, and designs",
    "role_category": "provider_client",
    "role_kind": "professional",
    "distinguishing_features": ["Creates original designs rather than reviewing them"],
    "professional_scope": "Original engineering design within the licensed discipline",
    "typical_qualifications": ["Professional Engineer license", "Discipline-specific design experience"],
    "associated_virtues": ["Competence", "Integrity"],
    "text_references": ["Engineer A designed the tower structures"],
    "confidence": 0.85,
    "match_decision": {
      "matches_existing": false,
      "matched_uri": null,
      "matched_label": null,
      "confidence": 0,
      "reasoning": "While Engineer exists in the ontology, Design Engineer captures the specific responsibility for original design work distinct from review or consulting roles."
    }
  }

INDIVIDUAL SCHEMA (role_individuals array) -- each individual is a JSON object:

  {
    "identifier": "Engineer A Design Engineer",
    "actor": "Engineer A",
    "role_class": "Design Engineer",
    "role_category": "provider_client",
    "role_kind": "professional",
    "case_involvement": "Created original tower designs containing significant errors",
    "license": "Professional Engineer",
    "specialty": "Structural design",
    "attributes": [{"key": "professional_membership", "value": "ASCE member"}],
    "relationships": [{"type": "hasClient", "target": "Owner", "quote": "Engineer A was retained by the Owner to design the tower"}, {"type": "workReviewedBy", "target": "Engineer B", "quote": "Engineer B was engaged to review Engineer A's work"}],
    "text_references": ["plans and design of Engineer A", "Engineer A objects and refused to consent"],
    "confidence": 0.90
  }

Keep each individual's identifier short (the case actor plus the short concept, at most about 6 words); scenario detail belongs in case_involvement, not the identifier (it becomes the URI).

ROLE TYPING FIELDS (role_category and role_kind are routing inputs, never stored as literals):
- role_category is the RELATIONAL category, one of the four Kong values (provider_client, professional_peer, employer_relationship, public_responsibility) or omitted when the role bears none. It is a FALLBACK: when the role bears an actor relationship (the relationships[] field), that edge determines the relational archetype and wins on conflict, so set role_category to agree with the directed edge you emit.
- role_kind is the OCCUPATIONAL backstop, professional or participant. Set it when the case states the judgment; omit it when unstated (do not guess). It types a role that matches no known occupational class onto the professional/participant axis. The do-not-establish-professional-obligations test: a party with no professional obligations is participant.

{{ role_relationships }}

ACTOR IDENTITY (cross-section): each role individual names a role FACET that some underlying actor plays. Set `actor` to that actor's stable identity (e.g. "Engineer A", "Owner", "City of X"), kept separate from the role facet in `identifier`. The SAME actor seen in a different section under a different role facet MUST reuse the SAME `actor` value. When an "ACTORS ALREADY IDENTIFIED IN PRIOR SECTIONS" block appears above the case text, reuse those actor identities exactly. One Agent is minted per distinct actor and bears each facet, so consistent actor naming is what keeps a person from being fragmented across sections.

FORMATTING: do not use em dashes or en dashes in output text, and do not dodge with stacked parentheticals or excessive colons/semicolons; use commas or split into two sentences.

Loading preview...

Version History

No version history yet. Save changes to create versions.

Saved

6206 chars

Reference

Template Variables

Role definitional/bearer field schema, resolved live from the SHACL role shapes (single source shared with the OntServe Role page)

Per-pass directive; one body serves facts+discussion, differing only by this runtime slot

Governing definitional anchor: the Ch2-operationalised Role definition, read verbatim from the ontology

Controlled role-to-role relationship type vocabulary for the relationships[] field, derived from the ontology (hasClient/professionalPeerOf/employedBy/reviewsWorkOf/workReviewedBy + relatedTo fallback); includes the additional_relationships overflow-bag instruction

Formatted list of existing role classes from ontology

Prescriptive extraction directives compiled from the disjointness/restriction/scopeNote axioms (D-EXCLUDE/D-AGENT/D-TELEO/D-INDIVIDUATION/D-FILTER/D-LABEL)

The case text to analyze

Controlled role_category vocabulary with per-category audience cues and the directed edge each implies

Output Schema

new_role_classes

label* string

role_kind string

confidence number

definition* string

role_category string

match_decision* object

text_references* array

associated_virtues array

professional_scope string

typical_qualifications array

distinguishing_features array

role_individuals

actor string → Agent

license string

employer string

role_kind string

specialty string

attributes object

confidence number

identifier* string

role_class* string

relationships array

role_category string

text_references* array

case_involvement string

experience_level string

technical_background string

additional_relationships array

JSON Wrapper

Appended to the prompt by the extractor:

IMPORTANT: Wrap your response as a JSON object with exactly two keys:
{"new_role_classes": [...], "role_individuals": [...]}
If there are no individuals to report, use an empty array for "role_individuals".