As part of Semantic BSDD, we made a Semantic Objects (SOML) schema for bSDD.
- I have now added an open source tool soml2puml, and two PlantUML diagrams:
Overview:
Full:
Feedback about the diagrams is most welcome!
Nice representation of the data structure!
I’m missing the links between:
- Property and Domain,
- PropertyRelation and Classification
- Property and Classification.
and also missing many of the attributes that are described in the documentation. For example, 6 attributes of a domain such as “QualityAssuranceProcedure”.
Remember that bSDD is a service, not a fixed standard, so the data structure might change, so always refer to latest documentation on github bSDD/bSDD JSON import model.md at master · buildingSMART/bSDD · GitHub
the data structure might change, so always refer to latest documentation
These are not illustrative diagrams:
As to the specific questions on links between:
Property and Domain
: there indeed isn’t any
PropertyRelation and Classification
: there isn’t such. There are links between:
PropertyRelation and Property
ClassificationRelation and Classification
Property and Classification
: There isn’t a direct link: ClassificationProperty
sits in the middle
@artur_tomczak I noticed something: why are Property.units
and ClassificationProperty.units
plural (string arrays: [String]
)?
Since the property value is a bare number (eg ClassificationProperty.predefinedValue
), shouldn’t there be just 1 unit?
In reality, there is the connection that I mentioned, so this is the limitation of GraphQL API.
why are Property.units
and ClassificationProperty.units
plural (string arrays: [String]
)?
Please refer to the docs: https://github.com/buildingSMART/bSDD/blob/master/Documentation/bSDD%20JSON%20import%20model.md. A property definition can have multiple possible units, and when it is applied to a particular Classification, it can only have one unit. That was the decision made when defining the data structure based on ISO standards. If GraphQL returns ClassProp units as plural as well, that is a bug.
In light of your findings, the best would be to say that bSDD’s GraphQL API is not complete and should be used with caution. The main source of truth should be REST JSON API until this is resolved. Thank you @VladimirAlexiev for thorough testing so that we can improve bSDD!
cc: @Erik.bSDD @berlotti
The latest diagrams are here (added id
and name
, which are “standard” fields):
the best would be to say that bSDD’s GraphQL API is not complete and should be used with caution
No! the best would be to fix the GraphQL API:
- to be able to return all data, and
- to have full-fledged where
(searching by various fields) and
limit/offset` (pagination).
GraphQL is a more developer-friendly approach than a fixed REST API, and IMHO should become the main BSDD API. @artur_tomczak @Erik.bSDD @jbrouwer @frederic.grand @berlotti @Evandro @jakob.beetz @mtryfona @michelangelo @MichelBohms what do you think?
Of course, the best is to improve the GraphQL, at some point. Currently, we are focusing on a few other priority improvements, like IFC integration, so unless you would like to contribute to the development, GraphQL has to wait for a couple of months.
The Ontotext Platform builds a systematic and feature-full GraphQL endpoint over RDF data, as shown by the “Semantic BSDD” development so far.
So if we can take full relational or JSON data, and harmonize JSON and RDF representation, then we can do that part of the equation.
1 Like