buildingSMART / bSDD

The buildingSMART Data Dictionary repository, where we publish the documentation, examples and more. We don't publish here the data, the source code of the bSDD service or the front end of the website.
https://www.buildingsmart.org/users/services/buildingsmart-data-dictionary/
MIT License
135 stars 36 forks source link

Ontology quick comments #31

Open aothms opened 2 years ago

aothms commented 2 years ago

Very quickly scrolled through https://github.com/buildingSMART/bSDD/blob/master/RDF/preview-bsdd-rdfs-0.3.ttl and provide some quick comments:

First note. I'm not an expert on ontology development.

No domains on properties. This makes it quite hard to understand and use probably.

Double:

bsdd:ReplacedObjectCode a rdf:Property ;
  skos:prefLabel "Replaced Object Code"@en ;
  rdfs:range xsd:string .

bsdd:replacingObjectCode a rdf:Property ;
  skos:prefLabel "Replacing Object Code"@en ;
  rdfs:range xsd:string .

Vvisual:

bsdd:VisualRepresentationUri a rdf:Property ;
  skos:prefLabel "Vvisual Representation URI"@en ;
  rdfs:range xsd:string .

Pparent:

bsdd:ParentClassificationCode a rdf:Property ;
  skos:prefLabel "Pparent Classification Code"@en ;
  rdfs:range xsd:string .

Uunit:

bsdd:Uunit a rdf:Property ;
  skos:prefLabel "unit"@en ;
  rdfs:range xsd:string .

bsdd:QudtUunit a rdf:Property ;
  skos:prefLabel "QUDT reference"@en .

Everything range string, I'd look for ways to enforce more consistency in the data, e.g prevent Netherlands/Holland/NL/nl/The Netherlands. I understand that there needs to be a reasonable sync between RDF <-> database, so it might not be possible, to normalize everything into classes (or maybe it is...).

bsdd:CountryOfOrigin a rdf:Property ;
  skos:prefLabel "Country Of Origin"@en ;
  rdfs:range xsd:string .

I wouln't expect relationship as a class. What's the intention here:

bsdd:ClassificationRelation a rdfs:Class ;
  skos:prefLabel "ClassificationRelation"@en .

XSD can be imported as an ontology:

bsdd:MinInclusive a rdf:Property ;
  skos:prefLabel "Min Inclusive"@en ;
  rdfs:range xsd:float .

bsdd:MaxInclusive a rdf:Property ;
  skos:prefLabel "Max Inclusive"@en ;
  rdfs:range xsd:float .

bsdd:MinExclusive a rdf:Property ;
  skos:prefLabel "Min Exclusive"@en ;
  rdfs:range xsd:float .

bsdd:MaxExclusive a rdf:Property ;
  skos:prefLabel "MaxExclusive"@en ;
  rdfs:range xsd:float .

bsdd:Pattern a rdf:Property ;
  skos:prefLabel "Pattern"@en ;
  rdfs:range xsd:string .

skos:note/rdfs:comment?

bsdd:Description a rdf:Property ;
  skos:prefLabel "Description"@en ;
  rdfs:range xsd:string.
Baars-IT commented 2 years ago

Hi Thomas,

Thanks for your comments!

Double: bsdd:ReplacedObjectCode a rdf:Property ; skos:prefLabel "Replaced Object Code"@en ; rdfs:range xsd:string .

bsdd:replacingObjectCode a rdf:Property ; skos:prefLabel "Replacing Object Code"@en ; rdfs:range xsd:string .

They're not duplicates, these are ISO 12006-3 properties. It is about "being replaced by" and "replacing". If "A" replaces "B" then for "A" ReplacingObjectCode will be "B" and for "B" ReplacedObjectCode will be "A".

Vvisual Pparent Uunit

Typos will be fixed

Everything range string, I'd look for ways to enforce more consistency in the data, e.g prevent Netherlands/Holland/NL/nl/The Netherlands. I understand that there needs to be a reasonable sync between RDF <-> database, so it might not be possible, to normalize everything into classes (or maybe it is...).

Ranges are checked upon input in the bSDD. RDF is (at least for the moment) meant for output only. Not sure if it is useful to have all range values listed in the ttl. Some of the ranges can still be extended (e.g. range of units).

XSD can be imported as an ontology:

Not sure what you mean by this, can you give an example?

skos:note/rdfs:comment?

I think you mean replace "bsdd:Description" by one of those? The documentation of skos:note says "it could be a definition, information about the scope of a concept, editorial information, or any other type of information.". "Description" is more demarcated definition which I think can be useful. rdfs:comment: "is used to provide a human-readable description of a resource" Looks like can use this one. Or add a predicate saying that bsdd:Description is same as rdfs:comment.

Thanks again for your comment!

aothms commented 2 years ago

They're not duplicates, these are ISO 12006-3 properties. It is about "being replaced by" and "replacing". If "A" replaces "B" then for "A" ReplacingObjectCode will be "B" and for "B" ReplacedObjectCode will be "A".

Ok, but I don't think it makes a lot of sense to define both in the data. E.g in a sparql query it's trivial to query in both directions:

SELECT ?x WHERE {
  <bsdd:Wall> <bsdd:ReplacedObjectCode> ?x .
}

SELECT ?x WHERE  {
  ?x <bsdd:ReplacedObjectCode> <bsdd:Wall> .
}

XSD can be imported as an ontology:

Not sure what you mean by this, can you give an example?

Instead of redeclaring bsdd:MinInclusive, you can use the existing xsd:minInclusive. I also don't know the mechanics by which this precisely works, but I see this in OWL examples all the time, e.g: http://drobilla.net/2012/09/08/how-to-define-a-datatype-in-rdf.html

<http://example.org/AnswerishInteger>
    a rdfs:Datatype ;
    rdfs:comment "An integer between 24 and 42 inclusive" ;
    owl:onDatatype xsd:integer ;
    owl:withRestrictions (
        [
            xsd:minInclusive 24
        ] [
            xsd:maxInclusive 42
        ]
    ) .

Looks like can use this one. Or add a predicate saying that bsdd:Description is same as rdfs:comment.

I also wasn't 100% sure on this. But yes, i'd say just use rdfs:comment when you serialize the data.

VladimirAlexiev commented 1 year ago

Also see https://bsdd.ontotext.com/new/ in particular https://bsdd.ontotext.com/new/#suggested-improvements (Artur is working on a lot of these suggestions).

I wouldn't dare use xsd:minInclusive etc because these are used on datatypes, whereas bsdd:Property is a class.

I even wouldn't dare map bsdd:dataType to XSD datatypes because