Capture basic agent information

[cgendreau]

• displayName
• email

[dshorthouse]

+1 as MVP. Breaking apart displayName now is a slippery slope.

[falkogloeckler]

MVP 1.0 could only focus on natural persons. But I strongly recommend to already include an attribute for type of agent or agent type (see DINA-Web/agent-specs#18).

[cgendreau]

I don't have a strong opinion on type of agent but we could still achieve that even if organization would be it's own entity. Since we will reference by URI, other modules could point to a /agent or /organization. @dshorthouse ?

[dshorthouse]

Tend to agree with @cgendreau but with a caveat. The challenge with modelling an agent as either a human or an organization are the attributes. If we use the more generic entity label agent, then its attributes ought to accommodate human, organization, machine or other entity that executes (or has the potential to execute) an action. I would caution against the use of agent if in practice it only models human attributes even if this were MVP 1.0. So, the Agent module (capital 'A') must have entity human. What we need is the best way to model & store extensible lists of properties such that they are tied to & are specific to a particular entity. Humans have birth dates, death dates, genders, whereas organizations will have entirely different attributes. Columns in a table would be practical & performant for any of these entities but quickly become sparse & unwieldy as more attributes are required. Instead, we should reference and store these more like a running table of triples that could later be sharded by entity type when performance takes a nose-dive: entity_id, property_id, property_value.

And so...

/person is preferable to /agent

[cgendreau]

Do we have an agreement to replace the /agent endpoint by /person for MVP 1.0 ?

[falkogloeckler]

Yes, I think so.