Building functional systems with this vocab
migrating a discussion from https://github.com/valueflows/agent/pull/37, so we have a dedicated issue to share learnings and discuss best practices for how we build functional systems with this vocab.
@fosterlynn: I don't think that all of this has to affect how we think of our building our functional systems. I certainly don't intend to make any changes to AgentType or AgentAssociationType in NRP! I am finding that this is like when I had to make the transition from relational to OO modeling structures. And that impedance mismatch never went away, we just manage it in the interface between the OO structures in the code and the relational database. This will be similar, we just manage it when we translate OO (or relational) data to rdf and back.
@ahdinosaur: that's really good to hear. i think we'll do the same for Holodex, since these RDF changes are adding complexity that i'd rather keep out of our app codebase and defer to an external translation module, which also means we won't feel tied to The JSON-LD / RDF Way if a better way of doing linked open data arises (e.g. ssb).
@elf-pavlik: @ahdinosaur I would find it very helpful if you could document somewhere in what exact way you see approach here adds complexity? To my understanding holodex as of now doesn't work with data distributed across different dataspaces (domains) on the web, I would expect certain increase in complexity while adding support for that.
@ahdinosaur: an
id
is a URL, so that's enough to handle data distributed across domains, assuming each domain provides the data in the proper format. anything more than a single state object exactly as the Holodex user interface code expects is additional complexity. my current thinking for how to handle this without adding large dependencies (e.g. jsonld) to the page load is to do the translation in the API so the UI can receive exactly what it expects without any special parsers. that isn't to say we won't support JSON-LD / RDF, we'll just have an API service layer that handles parsing, translation, caching, etc so the UI code doesn't have to. i'm still letting this simmer though.