glossarist 0.4.33 → 0.4.34

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "glossarist",
-  "version": "0.4.33",
+  "version": "0.4.34",
   "description": "JavaScript SDK for Glossarist GCR packages — read, write, validate, and manage terminology concepts",
   "type": "module",
   "main": "src/index.js",

package/src/concept-parser.js

@@ -2,7 +2,7 @@ import * as yaml from 'js-yaml';
 import { Concept } from './models/concept.js';
 import { RelatedConcept } from './models/related-concept.js';
 import { HyperedgeRegistry } from './models/hyperedge-registry.js';
-import { migrateHyperedgeToRelation } from './migration/partitive-relation-migrator.js';
+import { migrateHyperedgeToRelation } from './migration/hyperedge-migrator.js';
 import { InvalidInputError, YamlParseError } from './errors.js';
 
 // Structural keys are reserved at the concept level and excluded

package/src/diff/concept-diff.js

@@ -101,7 +101,7 @@ export class ConceptLevelDiff extends GlossaristModel {
     this._sources = wrapListDiff(data.sources);
     this._dates = wrapListDiff(data.dates);
     this._relatedConcepts = wrapListDiff(data.relatedConcepts ?? data.related_concepts);
-    // Unified n-ary relations diff. Accepts:
+    // Unified hyperedge diff. Accepts:
     //   - data.relations                   (new unified shape)
     //   - data.partitiveRelations /
     //     data.partitive_relations /
@@ -127,7 +127,7 @@ export class ConceptLevelDiff extends GlossaristModel {
   get sources() { return this._sources; }
   get dates() { return this._dates; }
   get relatedConcepts() { return this._relatedConcepts; }
-  /** Unified n-ary relations diff (PartitiveHyperedge + GenericHyperedge). */
+  /** Unified hyperedge diff (PartitiveHyperedge + GenericHyperedge). */
   get relations() { return this._relations; }
   /**
    * Filtered view of `relations` containing only PartitiveHyperedge
@@ -465,7 +465,7 @@ function diffConceptLevel(oldConcept, newConcept) {
     sources: diffSources(oldConcept.sources ?? [], newConcept.sources ?? []),
     dates: diffDates(oldConcept.dates ?? [], newConcept.dates ?? []),
     relatedConcepts: diffRelatedConcepts(oldConcept.relatedConcepts ?? [], newConcept.relatedConcepts ?? []),
-    relations: diffNaryRelations(
+    relations: diffHyperedges(
       oldConcept.relations ?? [],
       newConcept.relations ?? [],
     ),
@@ -565,13 +565,13 @@ function diffRelatedConcepts(oldRC, newRC) {
   });
 }
 
-// Diff two unified n-ary relations arrays. Identity is polymorphic —
+// Diff two unified hyperedge arrays. Identity is polymorphic —
 // dispatches via value.constructor.identityOf so PartitiveHyperedge
-// and GenericHyperedge (and any future n-ary subclass) coexist in
+// and GenericHyperedge (and any future hyperedge subclass) coexist in
 // the same list. Cross-type entries with matching identity are still
 // treated as different (because their constructor differs and they
 // live under different wire keys).
-function diffNaryRelations(oldR, newR) {
+function diffHyperedges(oldR, newR) {
   return diffSet(oldR, newR, {
     identityKey: relationIdentityOf,
     textKey: relationText,

package/src/diff/diff-renderer.js

@@ -125,10 +125,10 @@ function renderConceptLevel(diff, colors) {
   lines.push(...renderListDiff('Sources', diff.sources, colors, itemLabel));
   lines.push(...renderListDiff('Dates', diff.dates, colors, itemLabel));
   lines.push(...renderListDiff('Related', diff.relatedConcepts, colors, itemLabel));
-  // Unified n-ary relations section. Replaces the per-type sections
+  // Unified hyperedge section. Replaces the per-type sections
   // (Partitive relations, Generic relations) — the underlying diff
   // is a single ListDiff over the unified .relations array.
-  lines.push(...renderListDiff('N-ary relations', diff.relations, colors, relationLabel));
+  lines.push(...renderListDiff('Hyperedges', diff.relations, colors, relationLabel));
   lines.push(...renderListDiff('Groups', diff.groups, colors, itemLabel));
   lines.push(...renderListDiff('Sections', diff.sections, colors, itemLabel));
   lines.push(...renderListDiff('Tags', diff.tags, colors, itemLabel));
@@ -214,8 +214,16 @@ function relationLabel(r) {
         const ref = m?.ref ?? m ?? {};
         let tail = '';
         const mult = resolveMultiplicity(m);
-        if (mult && mult !== 'compulsory') tail = ` (${mult})`;
+        if (mult && mult !== 'compulsory') tail += ` (${mult})`;
+        // PartitiveMember uses is_delimiting (boolean flag).
         if (m?.is_delimiting === true) tail += ' ⊘';
+        // GenericMember uses delimitingCharacteristic (string value per
+        // ISO 704:2022 §5.5.4.2.1) — show the delimiting characteristic
+        // text so reviewers can see the intension difference.
+        if (m?.delimitingCharacteristic) {
+          const c = Object.values(m.delimitingCharacteristic)[0];
+          if (typeof c === 'string' && c.length > 0) tail += ` ⟨${c}⟩`;
+        }
         return `${ref.id ?? ref.source ?? ref.text ?? '?'}${tail}`;
       }).join(', ')
     : '';

package/src/models/abstract-hyperedge.js

@@ -1,4 +1,4 @@
-// AbstractHyperedge — shared base for n-ary concept-system
+// AbstractHyperedge — shared base for directed 1→N hyperedges
 // relations (PartitiveHyperedge, GenericHyperedge, future
 // SequentialRelation, AssociativeRelation).
 //
@@ -10,7 +10,7 @@
 //   - sources / notes / status: administrative metadata
 //
 // Concrete leaves add type-specific fields if needed (currently none).
-// See docs/design/abstract-nary-relation.md (concept-model repo).
+// See docs/design/abstract-hyperedge.md (concept-model repo).
 
 import { GlossaristModel } from './base.js';
 import { ConceptRef } from './concept-ref.js';

package/src/models/concept.js

@@ -4,7 +4,7 @@ import { RelatedConcept } from './related-concept.js';
 import { PartitiveHyperedge } from './partitive-hyperedge.js';
 import { AbstractHyperedge } from './abstract-hyperedge.js';
 import { HyperedgeRegistry, groupHyperedgesByWireKey } from './hyperedge-registry.js';
-import { migrateHyperedgeToRelation } from '../migration/partitive-relation-migrator.js';
+import { migrateHyperedgeToRelation } from '../migration/hyperedge-migrator.js';
 import { ConceptReference } from './concept-reference.js';
 import { ConceptDate } from './concept-date.js';
 import { ConceptSource } from './concept-source.js';
@@ -36,7 +36,7 @@ export class Concept extends GlossaristModel {
 
     this.relatedConcepts = _mapInstances(data.relatedConcepts ?? data.related ?? data.related_concepts ?? [], RelatedConcept);
 
-    // Unified hyperedge array. Every n-ary relation (PartitiveHyperedge,
+    // Unified hyperedge array. Every hyperedge (PartitiveHyperedge,
     // GenericHyperedge, future TemporalHyperedge / AssociativeHyperedge /
     // SequentialHyperedge) lives here. The single public API is
     // `.relations`; external systems that need to filter by type use

package/src/models/generic-member.js

@@ -1,15 +1,82 @@
-// GenericMember — one member of a GenericHyperedge. Inherits the
-// ISO 704:2022 MECE shape from HyperedgeMember. Declared as a
-// distinct leaf class for type safety and to leave room for
-// generic-specific extensions.
+// GenericMember — one member of a GenericHyperedge.
 //
-// See docs/design/abstract-nary-relation.md and
-// docs/design/generic-relation.md (concept-model repo).
+// Per ISO 704:2022 §5.5.4.2.1 (Generic relations and general concepts):
+//
+//   "In a generic relation, the intension of the subordinate concept
+//    includes the intension of the superordinate concept plus at least
+//    one additional delimiting characteristic."
+//
+// In hyperedge terms: when a GenericHyperedge has comprehensive=computer mouse
+// and criterion=means of movement detection, each member (mechanical mouse,
+// optomechanical mouse, optical mouse) carries a delimitingCharacteristic —
+// the value of the criterion for that specific concept:
+//
+//   mechanical mouse     → 'detecting movement by means of rollers'
+//   optomechanical mouse → 'detecting movement by means of rollers and light sensors'
+//   optical mouse        → 'detecting movement by means of light sensors'
+//
+// Multidimensionality (§5.6.3): the same comprehensive can be the
+// '1' side of multiple generic hyperedges simultaneously, each by a
+// different criterion. computer mouse is also comprehensive of
+// {wired mouse, wireless mouse} under criterion=computer connection.
+// That second hyperedge's members carry their own delimitingCharacteristic
+// values ('using a corded electrical connection', 'using a cordless
+// light or sound connection').
+//
+// delimitingCharacteristic is REQUIRED on GenericMember. Without it,
+// the member is just a coordinate concept with no semantic content
+// tying it to the criterion — ISO 704 says the relation is meaningless
+// without the delimiting characteristic.
+//
+// LocalizedString shape (mirrors criterion on the parent hyperedge):
+//   { eng: 'detecting movement by means of light sensors' }
+//   { eng: '...', fra: '...' }   — multiple languages supported
 
 import { HyperedgeMember } from './hyperedge-member.js';
 
 export class GenericMember extends HyperedgeMember {
-  // Inherits all attributes and validations from HyperedgeMember.
+  constructor(data = {}) {
+    super(data);
+    this.delimitingCharacteristic = _resolveDelimitingCharacteristic(data.delimitingCharacteristic);
+  }
+
+  toJSON() {
+    const base = super.toJSON();
+    base.delimitingCharacteristic = { ...this.delimitingCharacteristic };
+    return base;
+  }
+}
+
+function _resolveDelimitingCharacteristic(value) {
+  if (value == null) {
+    throw new Error(
+      'GenericMember.delimitingCharacteristic is required per ISO 704:2022 §5.5.4.2.1 ' +
+      '(the intension of a subordinate concept must include at least one additional ' +
+      'delimiting characteristic beyond the superordinate).',
+    );
+  }
+  if (typeof value === 'string') {
+    if (value.length === 0) {
+      throw new Error(
+        'GenericMember.delimitingCharacteristic cannot be empty (ISO 704:2022 §5.5.4.2.1)',
+      );
+    }
+    return { default: value };
+  }
+  if (typeof value === 'object') {
+    const entries = Object.entries(value).filter(([, v]) => typeof v === 'string' && v.length > 0);
+    if (entries.length === 0) {
+      throw new Error(
+        'GenericMember.delimitingCharacteristic must have at least one non-empty string ' +
+        'value (ISO 704:2022 §5.5.4.2.1)',
+      );
+    }
+    return Object.fromEntries(entries);
+  }
+  throw new Error(
+    `GenericMember.delimitingCharacteristic must be a string or a language-keyed object; ` +
+    `got ${typeof value}`,
+  );
 }
 
 export default GenericMember;

package/src/models/hyperedge-member.js

@@ -1,13 +1,21 @@
-// HyperedgeMember — abstract base shape for members of any
-// n-ary concept-system relation (PartitiveMember, GenericMember,
-// future AssociativeMember, SequentialMember).
+// HyperedgeMember — abstract base shape for the members of any directed
+// 1→N hyperedge (PartitiveMember, GenericMember, future AssociativeMember,
+// SequentialMember).
 //
-// Carries the shared ISO 704:2022 MECE dimensions: presence × count,
-// plus the orthogonal is_delimiting flag.
+// Carries ONLY the dimensions shared by every hyperedge member type:
+//   ref       — ConceptRef [1] (the member concept)
+//   presence  — 'required' | 'optional' (default: required)
+//   count     — 'exactly_one' | 'at_least_one' | 'multiple' (default: exactly_one)
 //
-// Concrete leaf classes extend this with type-specific fields if
-// needed (currently none). See docs/design/abstract-nary-relation.md
-// (concept-model repo).
+// These three form the ISO 704:2022 MECE pair (presence × count). The
+// pair is the shared invariant across all hyperedge types — that's
+// why it lives on the base.
+//
+// Type-specific extensions live on the leaves:
+//   PartitiveMember  — is_delimiting (rake-diagram semantics, ISO 704 §5.5.4.2.2)
+//   GenericMember    — delimitingCharacteristic (intension difference, ISO 704 §5.5.4.2.1)
+//
+// See docs/design/abstract-hyperedge.md (concept-model repo).
 
 import { GlossaristModel } from './base.js';
 import { ConceptRef } from './concept-ref.js';
@@ -30,14 +38,12 @@ export class HyperedgeMember extends GlossaristModel {
     this.ref = _ensureRef(data.ref);
     this.presence = _resolvePresence(data.presence);
     this.count = _resolveCount(data.count);
-    this.is_delimiting = _resolveDelimiting(data.is_delimiting);
 
     _assertValidPair(this.presence, this.count);
   }
 
   get isRequired() { return this.presence === PARTITIVE_PRESENCE.REQUIRED; }
   get isOptional() { return this.presence === PARTITIVE_PRESENCE.OPTIONAL; }
-  get isDelimiting() { return this.is_delimiting === true; }
 
   identity() {
     return HyperedgeMember.identityOf(this);
@@ -47,7 +53,6 @@ export class HyperedgeMember extends GlossaristModel {
     const obj = { ref: this.ref.toJSON() };
     if (this.presence !== DEFAULT_PRESENCE) obj.presence = this.presence;
     if (this.count !== DEFAULT_COUNT) obj.count = this.count;
-    if (this.is_delimiting) obj.is_delimiting = true;
     return obj;
   }
 
@@ -95,20 +100,10 @@ function _resolveCount(value) {
   return c;
 }
 
-function _resolveDelimiting(value) {
-  if (value == null) return false;
-  if (typeof value !== 'boolean') {
-    throw new Error(
-      `HyperedgeMember.is_delimiting must be boolean; got ${typeof value}`,
-    );
-  }
-  return value;
-}
-
 function _assertValidPair(presence, count) {
-  // Delegate to the multiplicity SSOT (Phase 8 of TODO.abstract-hyperedge).
-  // The canonical error string lives in one place: multiplicity.js.
-  // Calling multiplicityFromPair throws on the invalid combination;
-  // we don't need to duplicate the error message here.
+  // Delegate to the multiplicity SSOT. The canonical error string
+  // lives in one place: multiplicity.js. Calling multiplicityFromPair
+  // throws on the invalid combination; we don't need to duplicate the
+  // error message here.
   multiplicityFromPair(presence, count);
 }

package/src/models/index.js

@@ -32,9 +32,9 @@ export {
   isValidPluralityMarker,
 } from './plurality-marker.js';
 
-// v2 PartitiveHyperedge models (TODO.partitive-relation-v2). These
-// supersede the v1 hyperedge models above; the v1 models are kept for
-// backward-compat input. New code should use v2 exclusively.
+// PartitiveHyperedge models. The wire format (partitive_relations)
+// is unchanged from earlier versions; the v1 wire key (partitive_hyperedges)
+// is parsed on input and migrated to v2 shape via hyperedge-migrator.js.
 export { PartitiveHyperedge } from './partitive-hyperedge.js';
 export { PartitiveMember } from './partitive-member.js';
 
@@ -89,7 +89,7 @@ export {
 export {
   migrateHyperedgeToRelation,
   downgradeRelationToHyperedge,
-} from '../migration/partitive-relation-migrator.js';
+} from '../migration/hyperedge-migrator.js';
 
 export { makeEnum } from './enum.js';
 export { resolveHyperedgeColor } from './hyperedge-colors.js';

package/src/models/partitive-member.js

@@ -1,9 +1,18 @@
-// PartitiveMember — one member of a PartitiveHyperedge. Inherits the
-// ISO 704:2022 MECE shape from HyperedgeMember; the `comprehensive`
-// of its parent PartitiveHyperedge denotes the whole concept.
+// PartitiveMember — one member of a PartitiveHyperedge.
 //
-// Distinct leaf class for type safety and to leave room for
-// Partitive-specific extensions.
+// Adds to HyperedgeMember the partitive-specific `is_delimiting` flag
+// from ISO 704:2022 §5.5.4.2.2 (rake diagram semantics):
+//
+//   "Delimiting" parts (bold/3x-width line in source diagrams) behave
+//   like delimiting characteristics — they distinguish the comprehensive
+//   from coordinate concepts. Whether a part is delimiting depends on
+//   the concept system, the coordinate concepts, the inheritance
+//   principle, and the criterion of subdivision used.
+//
+// `is_delimiting` lives here on PartitiveMember, not on the base
+// HyperedgeMember, because it is partitive-specific. GenericMember
+// carries `delimitingCharacteristic` instead (the intension-difference
+// value per §5.5.4.2.1, which always applies to every generic member).
 //
 // Matches concept-model/models/concepts/PartitiveMember.lutaml exactly:
 //   +ref            — ConceptRef [1]
@@ -13,14 +22,34 @@
 //
 // The combination (optional, at_least_one) is invalid: if a part is
 // optional, the at-least-one constraint is vacuous and collapses to
-// (optional, multiple). Rejected at construction.
+// (optional, multiple). Rejected at construction by HyperedgeMember's
+// delegate to multiplicityFromPair.
 
 import { HyperedgeMember } from './hyperedge-member.js';
 
 export class PartitiveMember extends HyperedgeMember {
-  // Inherits all attributes and validations from HyperedgeMember.
-  // Declared as a distinct class for type safety and to leave room
-  // for future partitive-specific extensions.
+  constructor(data = {}) {
+    super(data);
+    this.is_delimiting = _resolveDelimiting(data.is_delimiting);
+  }
+
+  get isDelimiting() { return this.is_delimiting === true; }
+
+  toJSON() {
+    const base = super.toJSON();
+    if (this.is_delimiting) base.is_delimiting = true;
+    return base;
+  }
+}
+
+function _resolveDelimiting(value) {
+  if (value == null) return false;
+  if (typeof value !== 'boolean') {
+    throw new Error(
+      `PartitiveMember.is_delimiting must be boolean; got ${typeof value}`,
+    );
+  }
+  return value;
 }
 
 export default PartitiveMember;

package/src/rdf/gloss-partitive-relation.js

@@ -14,7 +14,7 @@
 //
 // The carrying concept links via `gloss:hasPartitiveRelation`.
 //
-// Replaces gloss-hyperedge.js (the v1 emitter) per
+// Per
 // TODO.partitive-relation-v2 item 01.
 // Cross-repo alignment with glossarist-ruby's Rdf::GlossPartitiveRelation.
 //

package/src/validators/ref-keys.js

@@ -1,7 +1,7 @@
 // Shared identity-key helpers for cross-relation validators.
 //
-// Extracted from PartitiveRelationCoherenceRule and
-// BinaryHasPartRedundancyRule per TODO.partitive-relation-v3/06.
+// Extracted from HyperedgeCoherenceRule and
+// BinaryHasPartRedundancyRule.
 // Eliminates drift: both rules now use the same notion of "same ref"
 // and "same criterion" instead of each defining its own _refKey and
 // _criterionKey with subtly different behaviors.