Changes to bSDD data model names

Users bSDD
1

There were a few requests to change the names of some of the bSDD concepts. I agree that the current naming is confusing, and we often need to explain it. In its defence, I will just say that some of the names are taken from the previous version of ISO12006-3. It’s a considerable change, so before taking action, let’s discuss it here on the forum. Easier to change it now and in one go, than when bSDD becomes even more popular.

We’re considering renaming:
“Classification” → “Class” (alternative: “Concept”)*
“Domain” → “Dictionary” (alternative: “Ontology”)
and changing:
“Material” into “Class”(ification) of type “Material” (right now “Material” is a separate entity)

*consequence of that will be a change to all fields such as “ClassificationRelations” or “ClassificationProperties”. We would also need to rethink current ClassificationTypes, as having a Class of type “Domain” and “ReferenceDocument” doesn’t make much sense, but type “GroupOfProperties” does. Maybe we keep only two types: “Concept” (default) and “GroupOfProperites”?

There was also a suggestion from @VladimirAlexiev and Ontotext team, to change all attributes to singular and written in lowerCamelCase. For example: “CountriesOfUse” → “countryOfUse”. I don’t think this change is necessary and might even lead to more confusion, but would like to hear more opinions on this.

Another proposal from Ontotext was to drop the “namespace” from “namespaceUri”.

Let me know if you are against or in favour of the proposed changes. Do you have any other suggestions?

As usual, such a change would require that we create a new version of the API, and maintain the old one for a period of at least 6 months. It wouldn’t affect the existing content, as we would rename the fields in the database. For those who want to upload new content, that would require them to update their input data files or use the updated template.

CC: @Erik.bSDD @jbrouwer @frederic.grand @berlotti @Evandro @VladimirAlexiev @jakob.beetz @mtryfona @michelangelo @MichelBohms

3 Likes
2

Great action Artur!

I 100% support singular names, we also say that in sml btw.

I will have to study the uri issue tbc.

All others i clesrly support.

Pref is concept iso of class

Material would not become class but actually an instance of Class.
So actually it would disappear on this metalevel…

Tbc michel

This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.

1 Like
3

I find the bSDD analysis by Ontotext very good and thorough, and now is the time to implement most of these points to have a good foundation for version 1.0.

I do think we have to be careful in stating bSDD === Linked data with the risk of eventually ending up with all the complex relationships that are possible within the Linked data world.
But bSDD should be a good Linked data citizen that perfectly represents the subset of Linked data relationships possible in IFC.
Because of this I prefer to use “Classification” or “Class” over “Concept”, and “Dictionary” over “Ontology”.

The material concept in bSDD is still a bit weird, “something like a classification”.
Instead of making “Material” inherit “Classification” I can even imagine to drop the “Material” definition altogether and just use normal a “Classification” as a material through the “HasMaterial” relationship (in which also the “IfcMaterialConstituent” percentages are set).
If we do keep the material as a seperate subclass, than It would be interesting to extend it with options for coloring and styling.

I have no real preference for singular attributes, I even think that plural is more clear for arrays.
If you do change attribute names I would go with lowerCamelCase, that’s also what we ended up doing in the ifcJSON project, I believe this was based on a naming convention for JSON.

I would change “namespaceUri” into “uri”.

1 Like
4

Yes, you’re right! Not all Linked Data ontologies can be losslessly uploaded to bSDD, since it has a strict data structure and limited relationship types. What we now call “domains” by definition are ontologies, but it takes some effort to convert and upload any ontology to bSDD. I think "dictionary is a safer term.

Same logic here. I’m trying to avoid confusion. “Classification” acc. Wikipedia is “the grouping of related facts into classes.”, so I would prefer “Class”, but don’t mind “Concept” as well. “Class” is also used in ISO12006.

So it would make bSDD more compliant with LD principles, at a small expense of clarity of the template. I don’t mind. It’s not a problem to display “countryOfUse” as “Countries of use” in the UI. Let’s hear more opinions.

I’m also aware I don’t know enough about Linked Data yet. Hope to meet and learn from experts at the LDAC school in June!

5

Note that in SML the meta-concept "Concept’ is used. Class is also fine but feels a bit more implementation (even LD) oriented.

Its not really about complex relations. Lets first agree that currently bsdd does not do relations at all! (the existing ones are meta-relations, not to be confused with relations…).

I very much support the deletion of Material from the meta-schema. Its out of place over there, on the wrong metalevel so to say.

I can understand plural from a json standpoint but would still conceptually prefer always-singular that can be used for 0, 1 or many target items. When ‘many’ you interpret as many singles…the other way round is more difficult (a singular plural…when you see a plural attribute and only have one element (in the array) it feels something is missing : )

term uri/namespace uri…it depends…in LD we have two kinds: base uri’s (graph URIs) indicating resources SAYING something about name space URI items…don’t know what is meant here.

6

Beware that any changes in terminology may one day shoot you in the foot if you plan to bring this work to ISO or CEN… So don’t treat terminology changes lightly.

1 Like
7

@artur_tomczak

“GroupOfProperties” → “PropertySet” again to avoid use of plural vs singular.
The meaning of “Classification” is overloaded:
According to NEN-EN-ISO 12006-3:2022, sect. 3.2, “Classification is process of assigning objects (3.4) to classes according to criteria”,
according to ISO 15926:2 (less relevant but as an example), sect. 4.8.1,"Classification is a relationship that indicates membership of a class,
so to avoid misleading semantics, “Classification” → “Class/Concept”

8

I support renaming NOW, and even a bit more drastic renaming to bring everything into shape.

  • prefer Dictionary to Ontology because as Michel noticed, BSDD Properties are data props (attributes) not object props (relations), so BSDD cannot capture full ontologies
  • prefer Class

Our current refactored schema is shown here, but it doesn’t do all desirable refactorings!

Please note the following (I use GraphQL types to describe):

  • every node has id: ID! (the URL)
  • most nodes have name regardless of which attribute is used for “preferred label”
  • every relation is named after the target (range), eg Domain->property->Property.
    • This is the main reason why we prefer singular. A domain has a multitude of Properties, yet the class Property is singular: why should the relation be named differently?
    • Whether a field is multivalued is determined by the type (in this case [Property]) not by the name.
    • If you need to change the cardinality (eg as we established with Artur, ClassificationProperty.unit must be single-valued not multi-valued) then the name doesn’t need to change
    • A field of the same meaning (Property.unit vs ClassificationProperty.unit) may be multi-valued in one case, and single-valued in the other case. But since the meaning is the same, it’s better to name it the same in both cases.

Bigger changes:

  • overlap-of-entity-classes-with-classificationtype: classificationType “DOMAIN” and “REFERENCE_DOCUMENT” must be removed. And I have my doubts about “COMPOSED_PROPERTY” (a Class is not a Property, and one can use PropertyRelation to model composition)
  • improve-relations-between-entities: a number of fields should become relations not attributes. In particular, currently there are 4 reference objects that are disconnected and unused
  • add-more-entities:
    • I definitely think PropertySet should become an object: it’s too important to be a mere string
    • and maybe also PhysicalQuantity, which relates unit to dimension

I suggest these changes are tackled after LDAC, where one of the student groups will tackle GitHub - SSoLDAC-2023/Challenge-Data_Dictionary and may produce some advancement, and I hope to have a BSDD session where these changes can be discussed.

Cheers!

9

Agree. That’s not an easy change and before takes place we want to consult it with all interested. One reason for change is that right now we misuse some of the ISO terminology, for example, the term “domain”.

@Nata_Ke Those are not the same. PropertySet indicates where to export/find a property in an IFC model while GroupOfProperties is an aggregating object. There can be a property which is located in a different PSet depending on an IFC class (entity). Anyway, GroupOfPropeties is singular, isn’t it?

We’re adding identifiers to the resources lacking it, like the ClassificationProperty. Is the content of your ID the same as of our “namespaceUri” (forget the name for now): “https://identifier.buildingsmart.org/uri/bs-agri/fruitvegs-1.0/class/apple”?

@VladimirAlexiev, you gave definitions from the LD nomenclature, but words such as ontology are also used outside of this context. (ontology - a set of concepts and categories in a subject area or domain that shows their properties and the relations between them). Let’s not forget that bSDD is not made solely for LD purposes, but there are multiple use cases, with the primary one being classifying IFC models in the authoring software.

The bSDD is a place where LD ontologies can be uploaded, but you’re right that those won’t be full ontologies. They need to comply with our strict data model, so it’s not without effort or loss of some aspects. That is the only way we see for supporting openBIM use cases. I’m looking forward to discussing it at LDAC if you see better solutions.

I agree with this one. That’s part of the ongoing discussion.

That is not the resolution I remember. We do intend to remain the current approach with lists of values. As I explained before, the “units” is a list, as there can be multiple units assigned to a property (unlike classificationProperty). For example, the property “length” can be of unit: [mm, cm, m, ft, …], but when applied in a certain context (classificationProperty) it must be of a specific unit, e.g. “cm”.

The connections are represented by outgoing URIs, so they are connected and used in a way. If you are talking about objects not being properly returned by GraphQL, that is indeed something that should be fixed. As discussed in the other thread (bSDD schema diagrams - #8 by VladimirAlexiev), the GraphQL is important but not of high priority, but we are open to contributions in that area if you are interested.

See you at LDAC!

10

Yes, as much as possible. The details are in all-entities-should-have-url. In particular, ClassificationProperty gets URL Classification.namespaceUri+"/"+propertyCode (same as in your RDF data).

ontology - a set of concepts and categories in a subject area or domain that shows their properties and the relations between them

And because BSDD has no relations, it should not be called “ontology”.

when applied in a certain context (classificationProperty) it must be of a specific unit, e.g. “cm”.

That’s exactly what I said, please read above.

4 reference objects are disconnected and unused
The connections are represented by outgoing URIs,

I’m talking about Country, Unit, ReferenceDocument, Language. What outgoing URLs do you mean?
These classes are not used in the other “payload” classes, and the respective strings in the “payload” classes (eg countryOfUse, unit etc), AFAIK, are not checked against the reference entities.

Eg you can’t tell whether documentReference should be a URL, identifier, or free text. See the refDoc sparql query for the variety of values (I only show top 8, there are worse examples further down):

image
image930×368 25 KB

GraphQL is important but not of high priority

We hope to change that.

1 Like
11

The nomenclature table ReferenceDocument is cleaner, see sparql query refDoc2. Suggestions for improvement:

  • write out specific rules about title. Eg
    • EN 15804:2012+A2:2019 title consists of two cumulative parts (base issue in 2012 and amendment issued in 2019)
    • The same standard designator lacks the issuing body BS. Also, I personally think that “EN” should be skipped. So I would rename this toBS 15804:2012+A2:2019
    • CEN/TR 14568:2003 includes 4 parts: issuing body, kind (TR=technical report), number, year
  • add URL based on the title
  • cut out T00:00:00 (fake ecompletion to “time” granularity) from the date field
12

You’re right about the unit and those 4 reference objects (sorry!), and good points about the ReferenceDocument maintenance.

Well, it boils down to how we interpret a relation.

bSDD relations - (as @MichelBohms called it: meta-relations) show how classes and properties are connected. For example:

IfcWall → IsEqualTo → EF_25_10 Walls

Engine → HasPart → Piston

With them, we built hierarchy, specialization and decomposition and show differences and similarities between classification systems. The list of “meta-relations” is complete in bSDD, but could be extended if needed. For example, if we have “HasPart”, might be good to add “IsPartOf”.

From what I understand, correct me if I’m wrong, the Linked Data relations you are missing in bSDD are the definitions of new, user-defined relation types, that could be used as the predicate in triples. For example:

Wall_01 → connects with → Wall_02

Wall_01 → holds → Window_03

Window_03 → is installed by → The manufacturer

If so, then yes, bSDD doesn’t allow defining that kind of new relations, and I also don’t see a need for it. Actual project data, if follows the IFC schema, would make use of the existing relations such as IfcRelAssigns or IfcRelConnects: 5.1.3.42 IfcRelationship - IFC4.3.2.0 Documentation .

13

Hi Artur

Indeed relation-issue now clear.

Note1: HasPart is actually to be interpreted as a TypicalHasPart (haspart on type level, giving rise to a Meronomy next to the Taxonomy) not to be confused with instance level.

Note2: I can understand that in IFC context you are not allowing enduser (instance) relations, but I also understood that bsdd could have meaning beyond bSI/IFC?

In practice we DO have ontologies/OTls with end-user relations. So we have to realize that the transformation to bSDD would filter them out then.

Alternatively they might be mapped to the right IFC-relation? (like now with the classes: relatedIFCEntity…)

Gr michel

Ps

Next bsdd workshop at ldac: will there be teams link too?

14

Do I get it right: “A piston by definition is a part of an engine, but it doesn’t necessarily mean that each engine has a piston”?

@MichelBohms, sure, bSDD is applicable outside IFC context. Still, I don’t fully see the advantage of having custom relation types. I’m hesitant, because that could significantly complicate the bSDD model. Could you please provide an example of a simple use case of user-defined relation and how you would like bSDD to support it?

15

We are now trying to implement URIs for ClassificationRelations (as well as ClassProperties, domains/dictionaries and organisations), to turn them into what I think is called first-class entities. By “relation” I mean bSDD relation, as explained in the posts above. Question to all Linked Data experts: How should such URL be constructed if we point to resources both in and outside of bSDD?

Let’s say we want to have a relation from ORIGIN to DESTINATION class. Let the origin has URI:

https://identifier.buildingsmart.org/uri/organisation/dict_name/version/class/origin

The destination 1 is within bSDD:

https://identifier.buildingsmart.org/uri/organisation/dict_name/version/class/destination_1

and the destination 2 is outside of bSDD:

https://otl.waternet.nl/def/destination_2

An idea we had was to have an URI like this for both internal and external relations:

https://identifier.buildingsmart.org/uri/organisation/dict_name/version/class/origin/reluri/https://otl.waternet.nl/def/destination_2

Is that acceptable, or do you have better ideas how to represent such “relation” resource?

cc: @VladimirAlexiev @Nata_Ke @jakob.beetz @pipauwel @Erik.bSDD

16

No, what you are talking about are ‘constraints’. I simply mean that decomposition is relevant for 2 meta levels: the data level (‘myengine haspart mypistoon’) and the ontology/type-level: ‘an engine typically has a piston’ (if it should be there it becomes a constraint). So the ontology-level haspart gives rise to a decomposition hierarchy referred to as a typical decomposition or Meronomy (compare the same for isSubClassOf resulting in a Taxonomy).

Wrt relationships: they are everywhere. Just take as example the W3C SOSA ontology for observations. The properties mentioned at for sosa:

  • hasFeatureOfInterest - A relation between an Observation and the entity whose quality was observed. For example, in an Observation of the weight of a person, the feature of interest is the person and the quality is weight.
  • hasResult - Relation linking an Observation and a Sensor or Actuator and a Result, which contains a value representing the value associated with the observed Property.
  • hasSample - Relation between a FeatureOfInterest and the Sample used to represent it.
  • hasValue - The value of a Result, e.g., 23 or true.
  • hostedBy - Relation between a Sensor or Actuator and the Platform that it is mounted on or hosted by.
  • hosts - Relation between a Platform and a Sensor or Actuator (or SamplingDevice) hosted or mounted on it.
  • isFeatureOfInterestOf - A relation between a FeatureOfInterest and an Observation about it.
  • isObservedBy - Relation between an ObservableProperty and the Sensor able to observe it.
  • isResultOf - Relation linking a Result to the Observation that created it.
  • isSampleOf - Relation from a Sample to the FeatureOfInterest that it is intended to be representative of.
  • madeObservation - Relation between a Sensor and an Observations it has made.
  • observedProperty - Relation linking an Observation to the Property that was observed. The observedProperty should be a Property (hasProperty) of the FeatureOfInterest (linked by featureOfInterest) of this observation.
  • observes - Relation between a Sensor and an ObservableProperty.
  • phenomenonTime - The time that the Result of an Observation/Actuation applies to the FeatureOfInterest - not necessarily the same as the result-time.
  • resultTime - The result time is the time when the Observation/Actuation act was completed.
  • usedProcedure - Link to a re-usable Procedure used in making Observation or Actuation. Typically a sensor or sensor-system, algorithm, computational procedure.
    …are all relationships interrelating sensors, observations, samples, observable properties, measured result values etc.etc. In a sense there are as many attributes as there are relations. True, relations can be more complex since the target/range is not a static data type but a reference to an instance that should be there etc.
17

hi @artur_tomczak ! Here’s an answer, sorry that it’s late:

  • For “relation within the same domain”, you can use https://identifier.buildingsmart.org/uri/organisation/dict_name/version/class/origin/relation/destination. The part relation is preferred to reluri since in RDF we talk of things, not their URIs.
    • Please note that if the relation is symmetric, you’d also need https://identifier.buildingsmart.org/uri/organisation/dict_name/version/class/destination/relation/origin…
  • For "relation across domains, but both are in bSI namespace, you can use https://identifier.buildingsmart.org/uri/organisation/dict_name/version/class/origin/relation/organisation2/dict2_name/version2/destination
  • For "relation to class outside of bSI namespace, use https://identifier.buildingsmart.org/uri/organisation/dict_name/version/class/origin/relation/otl.waternet.nl/def/destination. Please note that you can’t use : inside a URL