Add "description" field to type and property classes

[wetneb]

In the "Core Concepts" section we describe the fields of entities, properties and types. While we mention that entities can have descriptions, we do not have descriptions for properties and types. But this is not consistent with the schemas for the suggest responses, which let services return descriptions for such elements.

[wetneb]

It would also be good to expose those fields in all JSON schemas where those classes are serialized: for instances, types can be represented in the manifest, in reconciliation candidates and in type suggest responses: it would be useful to have a uniform serialization of types in all those places. This could probably be achieved by defining the JSON schema for types only once, and referring to it in those places (just like we refer to the JSON schema for authentication in the manifest).

[thadguidry]

That uniform serialization for types you mention reminds me of CBOR standard and how it's used in CBOR-LD to reduce binary size for compression and representation in QR encoding for instance. They use key mapping replacement essentially. "person":1 "organization":2 etc.

[thadguidry]

One UI representation of schema (properties that are query-able) I noticed from https://malloydata.dev in the post https://x.com/lloydtabb/status/1698717988491571495?s=46&t=CHG6wKavtxaRwUBGiCJ8wA

I find it an interesting way to present schema: types, hierarchy, query-able domains.

This is the kind of representation views that make suggest services easier for users. We should ensure that we have specs that allow services to richly expose schema mechanisms in a consistent and standardized way for all clients to absorb and display as they wish.