net.neodb.review

A long-form review of a catalog work, authored on a NeoDB instance.

Repository @neodb.net did:plc:ui2d3qu2ltydsyskmnuvi4ay namespace authority
Details · record, key any
Kindrecord
Record keyany
Authorityneodb.net
Indexed

Record

record · key any

Properties

body

requiredstring

Review body in Markdown.

createdAt

requiredstring · datetime

fediverseUri

string · uri

Fediverse (ActivityPub) object URI of the corresponding post on the originating NeoDB instance.

Optional rating accompanying the review.

subject

requiredref

title

requiredstring
  • maxLength: 2000
  • maxGraphemes: 500

updatedAt

string · datetime

Similar lexicons

semantic match

Lexicons whose schemas describe something close to this one. Check them before publishing a new one that overlaps.

  • A portable user-owned review of an Atmosphere project profile. The reviewer writes this record to their own PDS; AppViews may index and moderate their own display of it.

  • A shelf entry recording a user's status toward a catalog work, with optional rating, comment and tags.

  • A review of a work — whether the reviewer recommends it, and the words that explain why. It is a review rather than a rating because a verdict without reasons tells another user nothing about whether to trust it. A review attaches to a work and to nothing else: a post is an announcement, and recommending one means nothing. It lives in the reviewer's own repository. Editing a review rewrites this record in place rather than writing a new one, so a link to it keeps working — which also means a ref

  • how.bun.reviews.review

    record not from the namespace authority

    Record containing a review of something.

  • social.dracome.library.review

    record not from the namespace authority

    A review of one edition by an actor. Duplicate convention: the rkey is a TID minted once at first create and never changes. Several records may exist for one actor and edition (for example from out-of-band writers); consumers SHOULD treat the record with the greatest `updatedAt` (falling back to `createdAt`) as the winner and break ties by the lowest TID, ignoring the others. This is a convention, not an enforced contract: AppViews MUST tolerate a differing winner, and may see a record's catalog