by Al Baker, 22 March 2017 · 4 minute read
Stardog is part of NASA’s mission to Mars and we couldn’t be prouder of that. In this post I’ll explain some of the how and the why.
Hi Al,
I’ve worked with ISO 15926 before to handle lifecycle data in RDF. Do you know how it compares to OSLC?
Also, I presume you ran into having a need for some sort of reification. ISO 15926 does this by introduction objects for relationships and objects for literals. With RDF I know of three other ways of doing it.
How did you solve this with NASA? And what is the recommended approach with Stardog wrt. performance?
Cheers,
Håvard
They added “virtual quints” to support property graphs so there’s that as an option as well.
Hi Håvard,
OSLC is a linked data spec, focusing on top level transactions and identifiers used in those transactions. For example, the OSLC Asset Management spec stops at just model, manufacturer and serial number. You would expect to be able to make a request and get back the resource for those objects with additional data supported by that product, e.g. a representation of ISO 15926. We’ve found that as the tools standardize on the data, there’s a lot of system-to-system integrations and data sets out there. So we have a healthy mix of pulling in data from different products, sometimes directly, sometimes via some middleware that others have already made available. We’re not here to replace any tool integration, just collect up the data into a single knowledge graph to inform the engineering community on the larger impact of their data across the graph.
Our current approach for modeling these data sets is similar to ISO 15926, in that we create intermediate resources for the relationships. For example, rather than have a “controlledBy” predicate between an object and a hazard record, we’ll create a resource for the control relationship and assign it a class within the ontology. This makes a trade that the graph is a bit larger, as previous predicate usage turns into an extra resource in the mix. However, you get the benefit of being able to make other relationships off of that resources. This helps for lifecycle reviews, approval records, and other things that you would typically want to make against that individual property. I’ve also found this makes it easier for our team, and our NASA counter parts to write the audit reports, ICV constraints, etc.
Performance of this larger graph is great in Stardog, all of our visualizations and reports are generated quickly in real time in the browser. In the next blog in this series, I’ll discuss how using this style of modeling lets you represent different trees in this data area – architecture trees of controlled items, function trees of a space vehicle, and all of the organization specific overlays (like safety).
Cheers,
Al
Do you do any cost estimation in there as well? The engineering interplay across the graph also has a large impact on those projections. (I ask because I know someone who does NASA mission cost estimation who would be interested.).
Cost is handled in a different organization, so we don't have that in scope. I'm certainly interested in hearing more though - if you can contact me at albaker at stardog.com, we can discuss.
Thanks!
Al
Congratulations.
Planetdog. Marsdog.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.