allow inline location string data

[aspiers]

Summary by CodeRabbit

Release Notes

• New Features

  • Location records now support string-based location data (e.g., coordinates or compact GeoJSON) alongside existing URI and blob formats.

• Documentation

  • Added comprehensive guide on creating location records with field specifications and usage examples.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[changeset-bot]

🦋 Changeset detected

Latest commit: 3d45228

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@hypercerts-org/lexicon	Minor

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[coderabbitai]

Warning

Rate limit exceeded

@aspiers has exceeded the limit for the number of commits that can be reviewed per hour. Please wait 3 minutes and 0 seconds before requesting another review.

⌛ How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout.

Please see our FAQ for further information.

Note

Other AI code review bot(s) detected

CodeRabbit has detected other AI code review bot(s) in this pull request and will avoid duplicating their findings in the review comments. This may lead to a less comprehensive review.

📝 Walkthrough

Walkthrough

This PR extends the app.certified.location lexicon schema to support string-based location representations alongside existing URI and blob formats. It includes schema updates, comprehensive documentation, and a changeset entry documenting the minor release.

Changes

Cohort / File(s)	Summary
Lexicon Schema Update lexicons/app/certified/location.json	Added new string definition for location values (e.g., coordinates or GeoJSON strings). Extended the location field's union refs to accept #string in addition to existing URI and blob references.
Documentation README.md	Added comprehensive "Creating Location Records" section detailing the app.certified.location schema structure, including required/optional fields and three location data format examples (blob, coordinate-decimal, geojson-point).
Release Documentation .changeset/extend-location-schema.md	New changeset entry documenting the minor release adding inline string format support to location schema.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~12 minutes

Possibly related PRs

• update measurement schema #120 — Updates measurement records to reference the app.certified.location schema with a locations array, directly affected by schema extensions.
• feat: add location property to collections #123 — Introduces a collection.location strongRef pointing to app.certified.location, dependent on the location schema being modified.

Suggested reviewers

• s-adamantine

Poem

🐰 A string of locations hops into view,
No more just blobs—coordinates shine through,
The schema now stretches, flexible and free,
From URI to text, it's the way it should be! ✨

---

Important

Pre-merge checks failed

Please resolve all errors before merging. Addressing warnings is optional.

❌ Failed checks (1 error, 1 warning)

Check name	Status	Explanation	Resolution
Lexicon Documentation Sync	❌ Error	SCHEMAS.md was not updated to document the new string union member added to the location field, creating inconsistency with README.md documentation.	Update SCHEMAS.md to include the string format in the location field description and fix the createdAt field placement in README.md.
Lexicons Styleguide Compliance	⚠️ Warning	The lexicon file violates ATProto style guide by including a scalar string type as a union member instead of objects with discriminators.	Remove #string reference or wrap it in an object structure with proper type discriminator field as per ATProto specifications.

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title 'allow inline location string data' accurately describes the main change: extending the location schema to accept string representations alongside existing formats.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[Copilot]

Pull request overview

This pull request adds support for inline location string data to the app.certified.location lexicon, allowing location data to be specified as a direct string value (coordinates or GeoJSON) in addition to the existing URI and blob formats.

Changes:

• Extended location schema to support three data formats: URI references, embedded blobs, and inline strings
• Added comprehensive documentation with examples demonstrating all three location data formats
• Updated changeset to reflect the minor version bump
• Regenerated ERD diagrams to reflect the schema changes

Reviewed changes

Copilot reviewed 3 out of 7 changed files in this pull request and generated 6 comments.

Show a summary per file

File	Description
lexicons/app/certified/location.json	Added #string ref to location union and defined new string type for inline location data
README.md	Added "Creating Location Records" section with examples for all three location data formats (URI, blob, string)
ERD.svg	Regenerated entity relationship diagram to reflect schema changes
ERD-with-fields.svg	Regenerated detailed ERD with field information
.changeset/extend-location-schema.md	Added changeset documenting the minor version change

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[coderabbitai]

Actionable comments posted: 3

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

lexicons/app/certified/location.json (1)

36-43: Update the location description to include the string format.

The union now supports strings, but the description still says “URI or blob.”

✅ Suggested fix

-            "description": "The location of where the work was performed as a URI or blob."
+            "description": "The location of where the work was performed as a URI, blob, or inline string."

🤖 Fix all issues with AI agents

In `@lexicons/app/certified/location.json`:
- Around line 65-68: Update the SCHEMAS.md entry for app.certified.location to
list all three union members (URI, blob, and string) for the location field:
find the documentation block that currently says "URI or blob" for
app.certified.location and expand it to include the "string" variant (describe
that it can be a coordinate string or small GeoJSON), ensuring the union types
match the lexicon definition (app.certified.location -> location field) and
update examples if present to show all three options.

In `@README.md`:
- Around line 109-113: The example object wrongly places the required field
createdAt under the "Optional fields" section; update the README example so that
createdAt is shown as a required field (move it out of the optional block or
adjust the comment) and ensure the example still contains name, description, and
createdAt so integrators see createdAt is mandatory (refer to the createdAt
property in the example, and the surrounding "Optional fields" label).
- Around line 149-171: The location union in
lexicons/app/certified/location.json currently references the scalar ref
"#string", which violates ATProto Lexicon (union members must be object
variants); fix the schema by either removing the "#string" member from the union
(leaving only the existing object variants like uri and smallBlob) or replace
the "#string" ref with a proper object wrapper definition (e.g., a new record
type such as "string-wrapper" that contains a single "string" field) and update
the union to reference that object; ensure the union variant names and $type
discriminator usage in the "location" union remain consistent with other defs
(compare org.hypercerts.defs uri/smallBlob patterns) and adjust README examples
only if the schema change alters the expected payload shape.