You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jul 17, 2018. It is now read-only.
Based on my current discussion in #1 with @jpmckinney, I'm leaning toward making this a hypermedia style relationship so it is infinitely expandable based on the provided rel.
There's nothing saying you couldn't, but it probably wouldn't be needed. Instead, the rel property would define the type of relationship which is only going to be in a given direction. Here's a few fictious examples, drawing on real data that we have here @texastribune:
Person who is a contributor to a Person who happens to be a Politician: rel: 'http://example.org/rels/contributor/', href: 'http://example.org/politician/123'
Person who is an employee to an Organization that happens to be an Employer: rel: 'http://example.org/rels/employee/', href: 'http://example.org/employeers/123'
Person who is an inmate at an Organization that happens to be a Prison: rel: 'http://example.org/rels/inmate/', href: 'http://example.org/prison/123'
Organization who has hired an Organization that happens to be a LobbyingFirm: rel: 'http://example.org/rels/lobbyist/', href: 'http://example.org/lobbyists/123/'
One thing of note, the rel field does not have to be a full URL, just a unique URI. That means you can use full URLs and if that URL is under your control, it gives you the ability to ensure that nobody uses it to define something. My plan is to eventually create a @texas/rels repository that defines all of our schemas.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
No description provided.
The text was updated successfully, but these errors were encountered: