relaton 3.0.0.pre.alpha.17 → 3.0.0.pre.alpha.19

data/lib/relaton/calconnect/CLAUDE.md

@@ -0,0 +1,177 @@
+# CLAUDE.md
+
+## Development
+
+- `bundle install` — install dependencies
+- `bundle exec rake spec:calconnect` — run this flavor's suite
+- `bundle exec rubocop` — lint
+
+The root `Gemfile` git-pins pubid. Pick it up with **`bundle update pubid`**,
+never `bundle install` — an already-locked git source does not refloat.
+
+## Index
+
+### The gem builds and reads `index-v2`; the data repo owns `index-v1`
+
+`INDEXFILE` is the pubid-backed `index-v2`: rows are
+`Pubid::Calconnect::Identifier` hashes
+(`_type: pubid:calconnect:standard`, with `series`/`number`/`year`, plus
+`month`/`day` for the one fully dated row). The producer
+(`DataFetcher#index`) and the consumer (`HitCollection#index`) pass
+`pubid_class: ::Pubid::Calconnect::Identifier`. Omitting it on the
+**producer** writes v1-shaped rows under a v2 name, silently (`FileIO#save`
+calls `to_hash` only for instances of `pubid_class`); omitting it on the
+**consumer** leaves the rows raw hashes with `FileIO#sorted` false, so every
+lookup scans all 191 rows. `Processor#remove_index_file` passes `url: true` and
+`file:` only: the delete never reads the index (see
+`lib/relaton/index/CLAUDE.md`).
+
+**`index-v1` is not this gem's concern at all.** It exists only for released
+relaton **v2** clients, and `relaton-data-calconnect` owns it end to end:
+`build_index_v1.rb` rebuilds it there from each crawled document's own primary
+`docidentifier` string out of `data/` — unlike relaton-data-{ecma,w3c,iana,bipm},
+it does **not** derive it from the v2 rows. CalConnect can do that and they
+cannot, because a v1 row id is simply the document's printed id, with no edition
+or volume to split back out. The upshot for this side is that their v1 never
+depends on pubid, so nothing here can break it and there is no v1 fixture and no
+v1 assertion in this suite.
+
+### Lookup
+
+`HitCollection#search_index` follows the ETSI/W3C/ECMA idiom:
+
+- **Pass the pubid, not the string.** `Type#search_candidates` narrows only when
+  the argument is not a `String`, and a block alone never narrows — so the plain
+  string this flavor used to pass disabled the binary search however the index
+  was built. `pubid_class:` alone fixes nothing; both had to change together.
+- **Select with the subset match.** `search_index` calls
+  `index.search(pubid)` with no block, so `Index::Type#search` selects with
+  pubid's `pubid === row`. A date that the reference omits matches any value.
+  pubid declares `series` strict for CalConnect (pubid#408): the series keeps
+  `CC/CD 51016` and `CC/WD 51016` apart, and its *absence* is a value too, so
+  `CC 36010` does not match `CC/WD 36010`. Measured over the 191-row fixture:
+  `===` and the old `matches?(…, ignore: %i[year])` agree on all 406 pairs.
+- **An unparseable reference finds nothing**, with a warning, and is a miss
+  rather than an error — it must never surface as a `Relaton::RequestError`.
+
+**This ended a silently ambiguous substring scan.** The old string search
+matched any row *containing* the reference: `CC/DIR 1000` answered with all five
+`CC/DIR 1000x` documents and `CC/A 1` with every `CC/A 1xxx`. A number now
+matches exactly, and a leading zero is significant (`CC/A 0001` is not
+`CC/A 1`).
+
+**Ordering is newest-first, and it has to be explicit.** The index is sorted by
+number, so rows sharing a number arrive in no meaningful order; without
+`#recency_key` a bare `CC/S 0601` would answer with an arbitrary one of the 2005
+and 2006 documents. Date segments are compared as integers and negated for
+descending order, with `row[:file]` breaking ties because the index sort is not
+stable.
+
+`Bibliography.get` no longer regex-splits the reference before searching: pubid
+parses `CC/DIR 10005:2019` whole, so a dated reference narrows in the index
+itself. The `year` **argument** still needs filtering afterwards, because an
+undated reference reaches every year of the document — that is why
+`bib_results_filter` stays, and why it now reads the year off `row[:id].date`
+instead of scraping a rendered string (the old `/:(\d{4})$/` would raise
+`TypeError` against a pubid).
+
+### Why this flavor needs no render flags
+
+CalConnect is the simple end of the pubid migrations, and the reason is worth
+stating so nobody adds machinery it does not need. `Pubid::Calconnect` renders
+the publisher by default and models no edition and no volume, so the index key
+and the document's own printed id are **the same string**: `CC/DIR 10005:2019`
+in the row, `CC/DIR 10005:2019` in the record. There is nothing to opt in to
+(contrast `Relaton::ThreeGpp::Docidentifier`, which must pass
+`with_publisher: true`) and nothing to opt out of (contrast
+`Relaton::Ecma::Docidentifier`, which must suppress the edition and the volume).
+`DataFetcher#index_id` therefore returns the docidentifier's pubid untouched —
+no `dup`, no mutation.
+
+The number is a plain `String`, not a `Components::Code`, and deliberately so:
+it preserves leading zeros (`0001`, `0514`) and keeps a sub-number in one token
+(`0812-1`, `0707.1`). CalConnect models **no part** — those are numbers, not a
+number plus a part — which is why `Docidentifier#remove_part!` and
+`#to_all_parts!` are no-ops. Do not "fix" them by splitting the number.
+
+`Docidentifier` follows the IHO/W3C shape: `content=` calls `super` first, so
+`content` stays the source string verbatim. That is load-bearing beyond
+convention — `ItemData#create_id` derives the record's `id` from
+`content.gsub(/\W+/, "")`, so a re-render would move every published id.
+`#remove_date!` is the one real mutator (`CC/DIR 10005:2019` ->
+`CC/DIR 10005`); it writes back through `store_content`, never `content=`,
+because a re-parse would rebuild `@pubid` and discard the mutation.
+
+### An unparseable docid is recorded, not just warned
+
+`Docidentifier#parse` logs at `Util.error` and leaves `#pubid` nil — it must not
+raise, or an already-published record would stop deserializing.
+`DataFetcher#add_to_index` then records
+`@errors[docid] = "Unparseable primary id … was not indexed (…)"`, which the
+inherited `Core::DataFetcher#report_errors` logs and `Logger::Channels::GhIssue`
+turns into a GitHub issue at the end of the crawl. (`report_errors` treats a
+**String** value as the message; the boolean form the parsers use means "this
+field failed for every record" and is the wrong shape here.)
+
+The row is skipped rather than indexed unparsed, because `Relaton::Index`
+rejects the **whole** index if one row fails to deserialize and its sort calls
+`.root.number` on every id. `#write_doc` writes the file **before** indexing, so
+the document is unindexed, never lost.
+
+### Measured against the live published corpus
+
+All 191 rows of the published index (2026-09-08): every id parses; `to_s`
+reproduces the published string **exactly**; `from_hash(to_hash)` round-trips
+all 191; they render **191 distinct keys**, so nothing collapses under
+`add_or_update`; `root.number` is empty for none. Driving all 191 documents of
+`relaton-data-calconnect`'s `data/` through `write_doc` produces 191 rows with 0
+errors and reads back as 191 identifiers with `FileIO#sorted` true.
+`spec/calconnect/relaton/calconnect/pubid_contract_spec.rb` pins these
+properties offline against the committed `index-v2` fixture.
+
+No pubid change was needed for this migration. `Pubid::Calconnect` was written
+for it.
+
+## Testing
+
+- **Framework:** RSpec with VCR cassettes and WebMock.
+- **Index fixture:** `spec/calconnect/fixtures/index-v2.zip` — the whole
+  published index (191 rows), copied verbatim, so the stored shapes are exactly
+  what the runtime deserializes. Refresh it with
+  `bundle exec rake spec:update_index_calconnect`
+  (`tasks/index_fixture_calconnect.rb`); `#build` refuses a source that is not a
+  pubid index-v2 rather than writing a fixture `Relaton::Index` would reject
+  wholesale.
+- It is seeded into the `Relaton::Index` pool by
+  `spec/calconnect/support/webmock.rb`, built **with `pubid_class:`** — without
+  which the rows stay raw hashes, `FileIO#sorted` stays false, and
+  `Type#search` silently stops narrowing, so the suite would pass while
+  exercising something the runtime never does. It is written to a temp file and
+  read through `FileIO`, not stuffed into `@index` directly, because the
+  deserialize and the sort both happen on that read path.
+- There is **no `index-v1` fixture**, deliberately: `index-v1` is a released
+  relaton v2 artifact that this gem neither produces nor reads (see the index
+  section). Don't reintroduce one.
+- **The `before(:each)` re-seed is not belt-and-braces.** `Index::Pool#type`
+  replaces the pooled entry whenever `actual?` says no, and `DataFetcher#index`
+  asks for the same `:CC` slot with a *different* file (`index-v2.yaml`). With a
+  `before(:suite)` seed alone the fetcher evicts the fixture, and every later
+  example goes to the network for real — which is exactly how six examples used
+  to die with `Errno::EPERM` on `~/.relaton/cc/index-v1.yaml`. The pool key is
+  `type.upcase.to_sym`, so the producer and the consumer share one slot.
+  (The ECMA/OGC pattern.)
+- **VCR cassettes:** `spec/calconnect/vcr_cassettes/` — index downloads are
+  ignored by VCR, matched on the constant so a version bump cannot leave the
+  filter naming the old file and let a real download through.
+- `pubid_contract_spec.rb` checks the whole fixture corpus for the properties
+  the index key depends on: every row deserializes, one distinct rendered key
+  per row, no empty bsearch key, a `to_hash`/`from_hash` round trip, and every
+  rendered key parsing back to the same identifier. Re-run it whenever the
+  fixture is refreshed.
+- `hit_collection_spec.rb` covers the runtime search path — narrowing,
+  ordering, and the misses. It was an empty `describe` block before this
+  migration, so the lookup had no direct coverage at all.
+- The `bibdata`/`bibitem` round-trip examples and two `gets` examples validate
+  XML with Jing, which needs a **JVM on PATH**. Without one they fail with
+  `Jing::ExecutionError`, which is environmental, not a code defect — check
+  `java -version` before chasing it.

data/lib/relaton/calconnect/README.adoc

@@ -0,0 +1,140 @@
+= Relaton::Calconnect
+
+Relaton::Calconnect is a Ruby gem that implements the https://github.com/metanorma/metanorma-model-iso#iso-bibliographic-item[IsoBibliographicItem model].
+
+You can use it to retrieve metadata of Calconnect Standards from https://standards.calconnect.org, and access such metadata through the `CcBibliographicItem` object.
+
+== Usage
+
+=== Search for a standard using keywords
+
+[source,ruby]
+----
+require 'relaton/calconnect'
+=> true
+
+hits = Relaton::Calconnect::Bibliography.search("CC/DIR 10005:2019")
+=> <Relaton::Calconnect::HitCollection:0x00000000002df0 @ref=CC/DIR 10005:2019 @fetched=false>
+
+item = hits[0].item
+=> #<Relaton::Calconnect::ItemData:0x000000011104c998
+...
+----
+
+=== XML serialization
+
+[source,ruby]
+----
+item.to_xml
+=> "<bibitem id="CC-DIR10005-2019" type="standard" schema-version="v1.5.6">
+      <title language="en">Guidelines for the implementation of the CalConnect patent policy</title>
+      <docidentifier type="CalConnect" primary="true">CC/DIR 10005:2019</docidentifier>
+      ...
+    </bibitem>"
+----
+With argument `bibdata: true` it outputs XML wrapped by `bibdata` element and adds flavour `ext` element.
+[source,ruby]
+----
+item.to_xml bibdata: true
+=> "<bibdata type="standard" schema-version="v1.5.6">
+      <title language="en">Guidelines for the implementation of the CalConnect patent policy</title>
+      <docidentifier type="CalConnect" primary="true">CC/DIR 10005:2019</docidentifier>
+      ...
+      <ext schema-version="v1.1.2">
+        <doctype abbreviation="DIR">directive</doctype>
+        <flavor>calconnect</flavor>
+      </ext>
+  </bibdata>
+----
+
+=== Typed links
+
+Each Calconnect document has link types:
+
+* `xml` - XML format
+* `pdf` - PDF format
+* `doc` - Microsoft Word document format
+* `html` - HTML format
+* `rxl` - RelatonXML format
+
+[source,ruby]
+----
+item.source
+=> [#<Relaton::Bib::Uri:0x00007ff2d4b009e0 @content=#<Addressable::URI:0x668 URI:https://standards.calconnect.org/csd/cc-10005.xml>, @type="xml">,
+ #<Relaton::Bib::Uri:0x00007ff2d4b00378 @content=#<Addressable::URI:0x67c URI:https://standards.calconnect.org/csd/cc-10005.pdf>, @type="pdf">,
+ #<Relaton::Bib::Uri:0x00007ff2d4b00058 @content=#<Addressable::URI:0x690 URI:https://standards.calconnect.org/csd/cc-10005.doc>, @type="doc">,
+ #<Relaton::Bib::Uri:0x00007ff2d4b23d28 @content=#<Addressable::URI:0x6a4 URI:https://standards.calconnect.org/csd/cc-10005.html>, @type="html">,
+ #<Relaton::Bib::Uri:0x00007ff2d4b23a08 @content=#<Addressable::URI:0x6b8 URI:https://standards.calconnect.org/csd/cc-10005.rxl>, @type="rxl">]
+----
+
+=== Get document by code and year
+[source,ruby]
+----
+Relaton::Calconnect::Bibliography.get "CC/DIR 10005", "2019"
+[relaton-calconnect] INFO: (CC/DIR 10005) Fetching from Relaton repository ...
+[relaton-calconnect] INFO: (CC/DIR 10005) Found: `CC/DIR 10005:2019`
+ => #<Relaton::Calconnect::ItemData:0x0000000111944b18
+...
+----
+
+=== Create bibliographic item from XML
+[source,ruby]
+----
+Relaton::Calconnect::Item.from_xml File.read('spec/fixtures/cc_dir_10005_2019.xml')
+ => #<Relaton::Calconnect::ItemData:0x000000010ec81040
+...
+----
+
+=== Create bibliographic item from YAML
+[source,ruby]
+----
+Relaton::Calconnect::Item.from_yaml File.read('spec/fixtures/item.yaml')
+=> #<Relaton::Calconnect::ItemData:0x000000010fe5e600
+...
+----
+
+=== Fetch data
+
+This gem uses the https://raw.githubusercontent.com/usnistgov/NIST-Tech-Pubs/nist-pages/xml/allrecords.xml dataset as one of the data sources.
+
+The method `RelatonCalconnect::DataFetcher.fetch(output: "data", format: "yaml")` fetches all the documents from the dataset and saves them to the `./data` folder in YAML format.
+Arguments:
+
+- `output` - folder to save documents (default './data').
+- `format` - the format in which the documents are saved. Possible formats are: `yaml`, `xml`, `bibxml` (default `yaml`).
+
+[source,ruby]
+----
+require "relaton/calconnect/data_fetcher"
+Relaton::Calconnect::DataFetcher.fetch
+Started at: 2021-09-09 16:03:51 +0200
+Stopped at: 2021-09-09 16:04:12 +0200
+Done in: 20 sec.
+=> nil
+----
+
+=== Logging
+
+RelatonCalconnect uses the relaton-logger gem for logging. By default, it logs to STDOUT. To change the log levels and add other loggers, read the https://github.com/relaton/relaton-logger#usage[relaton-logger] documentation.
+
+== Development
+
+After checking out the repo, run `bin/setup` to install dependencies. Then, run `rake spec` to run the tests. You can also run `bin/console` for an interactive prompt that will allow you to experiment.
+
+== Index
+
+Lookups read a pubid-backed `index-v2`, whose rows are `Pubid::Calconnect::Identifier` objects serialized as `_type: pubid:calconnect:standard`. A reference is parsed into an identifier and matched against the index structurally, so a number matches exactly rather than as a substring: `CC/DIR 1000` finds nothing, `CC/DIR 10005` finds the one document, and `CC/A 0001` is not `CC/A 1`. An undated reference reaches every year of a document and the most recent is returned first.
+
+The legacy `index-v1` is no longer produced here; https://github.com/relaton/relaton-data-calconnect[relaton-data-calconnect] rebuilds it from each crawled document's own docidentifier for released relaton v2 clients.
+
+To refresh the index test fixture, run `rake spec:update_index_calconnect`. This downloads the published `index-v2.zip` from the https://github.com/relaton/relaton-data-calconnect[relaton-data-calconnect] repository.
+
+To install this gem onto your local machine, run `bundle exec rake install`. To release a new version, update the version number in `version.rb`, and then run `bundle exec rake release`, which will create a git tag for the version, push git commits and tags, and push the `.gem` file to [rubygems.org](https://rubygems.org).
+
+== Contributing
+
+Bug reports and pull requests are welcome on GitHub at https://github.com/calconnect/relaton_calconnect.
+
+== License
+
+The gem is available as open source under the terms of the [MIT License](https://opensource.org/licenses/MIT).

data/lib/relaton/ccsds/CLAUDE.md

@@ -0,0 +1,74 @@
+# CLAUDE.md
+
+## Architecture
+
+**Pubid-backed docidentifier.** `Relaton::Ccsds::Docidentifier`
+(`model/docidentifier.rb`, `< Bib::Docidentifier`) parses its `content` into a
+`Pubid::Ccsds::Identifier` kept in `@pubid`, while the lutaml `content` attribute
+stays a plain string for serialization. It implements the base class's abstract
+`remove_part!` / `remove_date!` / `to_all_parts!` by mutating the pubid graph
+(walking the `base` chain for supplements/corrigenda) and re-rendering
+via `refresh_content!`. Unparseable content falls back to the raw string. It is
+wired into `model/item.rb` (`attribute :docidentifier, Docidentifier`) so
+`from_xml`/`from_yaml` and `DataParser#parse_docidentifier` yield this class.
+`remove_date!` is effectively a no-op today — CCSDS ids carry no date component —
+but is implemented for parity with ISO/IEC. `to_all_parts!` drops the part
+component (e.g. `CCSDS 121.0-B-3` → `CCSDS 121-B-3`), freezes that rendering
+into `@raw_content` (since `content` is live-derived from `@pubid`), then
+wraps `@pubid` in pubid's `AllParts`. pubid-ccsds has no dedicated `AllParts`
+subclass — unlike pubid-iso — so the wrapper is the generic
+`Pubid::AllPartsIdentifier`: `content` stays the plain part-stripped id, but
+`#pubid` itself, read directly, now answers `all_parts? == true` and renders
+WITH pubid's generic "(all parts)" marker, since it's the wrapper. This
+mirrors `lib/relaton/iec/model/docidentifier.rb`; the shared skeleton is
+intentionally duplicated per flavor for now (to be hoisted into
+`Bib::Docidentifier` once every flavor's id is Pubid-backed).
+
+**Translation relations use pubid's subset match.**
+`Data::Fetcher#search_instance_translation` reads the document's **already
+parsed** id from `bib.docidentifier.first.pubid` (not `content`, which it would
+re-parse), derives the language-less reference with `pubid.exclude(:language)`,
+and picks the branch by `bibid == pubid` — no language means an instance
+(`#search_translations`), a language means a translation (`#search_relations`).
+This is more correct than the old `TRRGX` string test: `content` returns
+`@pubid.to_s`, which reorders components, so a translated corrigendum
+(`CCSDS 320.0-B-1-S - German Translated Cor. 1`) put the language mid-string and
+the `$`-anchored `TRRGX` missed it; `exclude(:language)` strips the language down
+the whole base chain. `TRRGX` still serves `translation_relation_types` and
+`DataParser#relation_type`, which match raw relation-id strings.
+`#search_relations` and `#search_translations` receive that pubid and select
+index rows with `row[:id].exclude(:language) == bibid_pid` — a
+language-agnostic match, so a translated row and the instance both match while
+another edition of the same number does not. This does **not** use `===`:
+pubid declares CCSDS `language` `subset_strict`, so a nil reference language
+means "has none" (a wildcard would be wrong for `HitCollection`, where a
+language-less user reference must not reach a translation). `exclude(:language)`
+drops the language from the row on both sides, mirroring
+`HitCollection#rows` (`r[:id].exclude(:edition) == pubid`).
+
+`HitCollection#rows` keeps `index.search(pubid, exact: true)` for an edition
+reference, although `language` is strict now. CCSDS `suffix` is still a nil
+wildcard in pubid, so the bare `index.search(pubid)` makes `CCSDS 101.0-B-4`
+also return the historical `CCSDS 101.0-B-4-S` (260 such pairs in the index
+fixture). The `hit_collection_spec` "historical and a translated sibling"
+example guards this. Drop `exact: true` only after pubid declares `suffix`
+`subset_strict` too.
+
+`#search_relations` excludes the document's own row with
+`row[:id] == bib.docidentifier.first.pubid` — pubid to pubid. It compared a
+`Pubid::Ccsds::Identifier` with a `String` (`.content`) before and was always
+false, so a re-crawl over an index that already held the document gave it a
+relation to itself. Covered by the `#search_relations` "excludes the document's
+own row" example.
+
+## Development
+
+- `bundle install` — install dependencies
+- `bundle exec rake spec` — run tests
+- `bundle exec rubocop` — lint
+
+## Testing
+
+- **Framework:** RSpec with VCR cassettes and WebMock
+- **Index fixture:** `spec/fixtures/index-v1.zip` is pre-loaded into `Relaton::Index` pool in `before(:suite)` (configured in `spec/support/webmock.rb`). Run `rake spec:update_index` to refresh from relaton-data-ccsds.
+- **VCR cassettes:** `spec/vcr_cassettes/` — index download requests are ignored by VCR (handled by fixture).

data/lib/relaton/ccsds/README.adoc

@@ -0,0 +1,154 @@
+= Relaton::Ccsds
+
+RelatonCcsds is a Ruby gem that implements the https://github.com/relaton/relaton-models#bibliographic-item[BibliographicItem model].
+
+You can use it to retrieve metadata of CCSDS Standards from https://public.ccsds.org/Publications/AllPubs.aspx, and access such metadata through the `RelatonCcsds::BibliographicItem` object.
+
+== Usage
+
+=== Search for a standard using keywords
+
+[source,ruby]
+----
+require 'relaton/ccsds'
+=> true
+
+hits = Relaton::Ccsds::Bibliography.search("CCSDS 230.2-G-1")
+=> <Relaton::Ccsds::HitCollection:0x000000000016b0 @ref=CCSDS 230.2-G-1 @fetched=false>
+
+item = hits[0].item
+=> #<Relaton::Ccsds::ItemData:0x0000000125ae1318
+...
+
+item.docidentifier[0].content
+=> "CCSDS 230.2-G-1"
+
+item = Relaton::Ccsds::Bibliography.get("CCSDS 230.2-G-1")
+[relaton-ccsds] INFO: (CCSDS 230.2-G-1) Fetching from Relaton repository ...
+[relaton-ccsds] INFO: (CCSDS 230.2-G-1) Found: `CCSDS 230.2-G-1`.
+=> #<Relaton::Ccsds::ItemData:0x0000000125deba40
+...
+----
+
+=== XML serialization
+
+[source,ruby]
+----
+item.to_xml
+=> "<bibitem id="CCSDS2302G1" schema-version="v1.5.6">
+      <fetched>2025-12-03</fetched>
+      <title language="en" script="Latn">Next Generation Uplink</title>
+      <uri type="src">https://ccsds.org/publications/ccsdsallpubs/entry/3224/</uri>
+      <uri type="pdf">https://ccsds.org/wp-content/uploads/gravity_forms/5-448e85c647331d9cbaf66c096458bdd5/2025/01//230x2g1.pdf</uri>
+      <docidentifier type="CCSDS" primary="true">CCSDS 230.2-G-1</docidentifier>
+      ...
+    </bibitem>"
+----
+With argument `bibdata: true` it outputs XML wrapped by `bibdata` element and adds flavour `ext` element.
+[source,ruby]
+----
+item.to_xml bibdata: true
+=> "<bibdata schema-version="v1.5.6">
+      <fetched>2025-12-03</fetched>
+      <title language="en" script="Latn">Next Generation Uplink</title>
+      <uri type="src">https://ccsds.org/publications/ccsdsallpubs/entry/3224/</uri>
+      ...
+      <ext>
+        <doctype>report</doctype>
+        <technology-area>Space Link Services Area</technology-area>
+      </ext>
+    </bibdata>"
+----
+
+=== Typed links
+
+All the CCSDS documents have PDF links. Some of them have additional DOC links. The gem provides a way to access these links through the `RelatonBib::TypedUri` object.
+
+[source,ruby]
+----
+item.source
+=> [#<Relaton::Bib::Uri:0x0000000126722b90 @content="https://ccsds.org/publications/ccsdsallpubs/entry/3224/", @language=nil, @locale=nil, @script=nil, @type="src">,
+ #<Relaton::Bib::Uri:0x0000000126722690
+  @content="https://ccsds.org/wp-content/uploads/gravity_forms/5-448e85c647331d9cbaf66c096458bdd5/2025/01//230x2g1.pdf",
+  @language=nil,
+  @locale=nil,
+  @script=nil,
+  @type="pdf">]
+
+Relaton::Ccsds::Bibliography.get("CCSDS 720.6-Y-1").source
+[relaton-ccsds] (CCSDS 720.6-Y-1) Fetching from Relaton repository ...
+[relaton-ccsds] (CCSDS 720.6-Y-1) Found: `CCSDS 720.6-Y-1`.
+=> [#<Relaton::Bib::Uri:0x00000001268cfba0 @content="https://ccsds.org/publications/ccsdsallpubs/entry/3160/", @language=nil, @locale=nil, @script=nil, @type="src">,
+ #<Relaton::Bib::Uri:0x00000001268cf650
+  @content="https://ccsds.org/wp-content/uploads/gravity_forms/5-448e85c647331d9cbaf66c096458bdd5/2025/01//720x6y1.doc",
+  @language=nil,
+  @locale=nil,
+  @script=nil,
+  @type="doc">,
+ #<Relaton::Bib::Uri:0x00000001268cf100
+  @content="https://ccsds.org/wp-content/uploads/gravity_forms/5-448e85c647331d9cbaf66c096458bdd5/2025/01//720x6y1.pdf",
+  @language=nil,
+  @locale=nil,
+  @script=nil,
+  @type="pdf">]
+----
+
+=== Create bibliographic item from XML
+[source,ruby]
+----
+Relaton::Ccsds::Item.from_xml File.read('spec/fixtures/ccsds_230_2-g-1.xml')
+=> #<Relaton::Ccsds::ItemData:0x0000000127b46680
+...
+----
+
+=== Create bibliographic item from YAML
+[source,ruby]
+----
+yaml = File.read 'spec/fixtures/ccsds_230_2-g-1.yaml'
+=> ---\nschema-version: v1.2.9\nid: CCSDS230.2-G-1 ...
+
+Relaton::Ccsds::Item.from_yaml yaml
+=> #<Relaton::Ccsds::ItemData:0x0000000122e4caa0
+...
+----
+
+=== Fetch data
+
+This gem uses the https://ccsds.org/publications/ccsdsallpubs/ page as a data source.
+
+The method `Relaton::Ccsds::DataFetcher.fetch(output: "data", format: "yaml")` fetches all the documents from the data source and saves them to the `./data` folder in YAML format.
+Arguments:
+
+- `output` - folder to save documents (default './data').
+- `format` - the format in which the documents are saved. Possible formats are: `yaml`, `xml`, `bibxml` (default `yaml`).
+
+[source,ruby]
+----
+require 'relaton/ccsds/data/fetcher'
+Relaton::Ccsds::DataFetcher.fetch
+Started at: 2023-08-25 22:02:06 -0400
+(data/CCSDS-720-4-Y-1.yaml) file already exists. Trying to merge links ...
+...
+Done in: 40 sec.
+=> nil
+----
+
+=== Logging
+
+RelatonCcsds uses the relaton-logger gem for logging. By default, it logs to STDOUT. To change the log levels and add other loggers, read the https://github.com/relaton/relaton-logger#usage[relaton-logger] documentation.
+
+== Development
+
+After checking out the repo, run `bin/setup` to install dependencies. Then, run `rake spec` to run the tests. You can also run `bin/console` for an interactive prompt that will allow you to experiment.
+
+To update the index test fixture (used by tests), run `rake spec:update_index`. This downloads the latest `index-v1.zip` from the https://github.com/relaton/relaton-data-ccsds[relaton-data-ccsds] repository.
+
+To install this gem onto your local machine, run `bundle exec rake install`. To release a new version, update the version number in `version.rb`, and then run `bundle exec rake release`, which will create a git tag for the version, push git commits and tags, and push the `.gem` file to [rubygems.org](https://rubygems.org).
+
+== Contributing
+
+Bug reports and pull requests are welcome on GitHub at https://github.com/relaton/relaton-ccsds.
+
+== License
+
+The gem is available as open source under the terms of the [MIT License](https://opensource.org/licenses/MIT).