Hi everyone!
We just had a paper accepted to LDAC 2023: Semantic bSDD: Improving the GraphQL, JSON and RDF Representations of buildingSmart Data Dictionary. Caution: we’ve focused on these 3 data representations rather than the traditional REST API, and our analysis is based on the test bSDD instance (but we think similar problems will be found in the production instance).
More important than the paper:
- we described our work in detail: Semantic bSDD
- we made a demo site https://bsdd.ontotext.com. It includes links to a variety of services: GraphQL schema visualizations, GraphiQL querying (of original and refactored service), SPARQL querying, etc.
This Friday 24 Mar 2023 at 3pm CET (4pm BG time) we’ll present the work at https://meet.google.com/cjc-mbcy-nke. I’ll take a recording.
Our company Ontotext is a semantic technology expert but not (yet) an AECO expert. So we are very eager to get feedback from all of you (in particular @artur_tomczak @berlotti @jakob.beetz @jakob-beetz @pipauwel @Erik.bSDD) on whether the identified needs for improvement make sense.
- I’ll now post some specific data observations.
- Since we sponsor the LDAC 2023 Summer School, we might define a hackathon case to elaborate “Semantic bSDD”, i.e. make more improvements to the bSDD structure.
2 Likes
Hi Vladimir!
That is an impressive overview; I’m looking forward to the meeting tomorrow to hear more. I need a bit more time to read through the report and give feedback on the proposed ideas.
I played a bit with the visuals; they are great! Below is my attempt to demonstrate the “sustainability assessing” location in Uniclass. I hope it is fine if I use it in my presentation in Rome next week.
As you probably know, the bSDD is also a sponsor of the LDAC event and we have prepared one bSDD-related hackathon challenge. See you in Matera in June!
2 Likes
Sure, use the vizgraph!
Looking forward to meet you tomorrow, and in Matera!
What are you doing in Rome?
Which do you like for a logo for “Semantic BSDD”? I like the last one.
Note: a recording of the Feb 24 webinar is available, it’s liked at https://bsdd.ontotext.com/.
Hi Vladimir, I like the icon but would prefer you not to use the name bSDD and colours as it might lead to confusion with the actual bSDD service from buildingSMART. Please at least add the “semantic” to it and not use the official colours.
The official bSDD logo is this one:
I was afraid bSI will complain about the logo, that’s why we made our own 
We also have our own favicon: 
Please note we haven’t used your font.
So the colors and the word are the only thing that relates our logo to the BSDD logo. Do you really want us to change the colors? I think our logo is totally different from yours, so there’s no chance of confusion between them.
I also doubt very much that bSI can protect a choice of colors: unlike a logo, colors are for anyone to use, no? Eg previously we used the Google colors in a logo, can they ask someone not to?
I like your suggestion: we’ll add in smaller font
“Semantic bSDD by Ontotext”
Do you agree?
My intention is to avoid confusion with the actual bSDD from buildingSMART. The version you shared before is misleading. As long as it is not confusing I’m fine with it. But let’s ask @aidan.mercer as he is our expert on this.
I really like the work you done and it is an inspiration for the bSDD.
Creating a new system however is not helping and will only confuse users.
Let’s properly discuss in-person how we can make the bSDD better and benefit from the work you did, instead of starting something new again. There is a nice opportunity at LDAC and also many in the ACCORD project.
We will process your other input as well in the meantime to improve the core of bSDD.
Hi @berlotti ! Of course we don’t want to create a new bSDD, we’d like to help bSI make a better bSDD. Ready to discuss this in ACCORD or at LDAC. Cheers!
cc @artur_tomczak
1 Like
We had a discussion with bSI. You can see a recording (and imprecise transcript) at 2023-04-to-bSI - Google Drive.
The next discussion is 22 May 2023 at LBD.
And I hope we can have a wider community discussion at LDAC!
1 Like
For easier tracking, here is a live spreadsheet with status/solution to each of Ontotext’s proposals: 
bSDD issues from Ontotext.xlsx
And the summary of the progress so far:
| Status |
Count of Status |
| DISMISSED |
6 |
| NEED MORE INFO |
5 |
| SOLUTION IN PROGRESS |
12 |
| SOLVED |
4 |
| TO BE ANALYSED |
21 |
| TO DO |
13 |
| Grand Total |
61 |
We will be discussing some open topics at LDAC this June.
Thank you once again for helping to improve the bSDD service!
@VladimirAlexiev @Nata_Ke @MichelBohms
After today’s LBD meeting, I noted to check if bSDD relations (between classes and properties) are reflexive, symmetric, and transitive. In my understanding, none of this is true for bSDD. We can have one-directional relations, and they don’t point to themselves. In some cases, the relations can be symmetric if both publishers declare there is a relation between their content. Would it help to be “more linked” if we show the opposite relations? Then it should be like on the right hand-side, with up to 4 relations between two classes:
That is doable, I think. It’s only a matter of displaying the content like that in GraphQL and RDF since the current SQL data already allows for finding such relations. Can you provide some example of what value this would bring if we implement it?
Whether relations have these characteristics depends on the use case. Eg in SKOS:
- broaderMatch is asymmetric (and narrowerMatch is its inverse)
- closeMatch is symmetric
- exactMatch is symmetric and transitive, thus also reflexive, thus forms classes of equivalence
I don’t think the nature of relations should depend on which data provider states them, because BSDD is a single database. If a relationType is meant to be symmetric, then it doesn’t matter whether it’s stated as C1-R-C2 or C2-R-C1.
The original representation is Classification.relations -> ClassificationRelation.relatedClassificationUri, which we can symbolize as C1->R->"C2" (the last link is string not thing).
The fact that relations are reified (represented as a separate node) means that a symmetric relation should be expanded to 2 nodes.
The refactored representation is Classification.relation -> ClassificationRelation.related -> Classification, but there’s also the opposite direction. We can symbolize it as C1-R-C2 and you can navigate it in any direction, eg C2-relation-R-related-C1 or even R-related{2}-{C1,C2}.
So in fact the refactored representation has changed the meaning of relations a bit: both ends of the relation are named the same. This caters better to symmetric relations (only one Relation node is needed), but cannot capture asymmetric relations: this needs to be fixed.
