w3c-lbd-cg / bot Goto Github PK
View Code? Open in Web Editor NEWBuilding Topology Ontology
Home Page: https://w3id.org/bot
Building Topology Ontology
Home Page: https://w3id.org/bot
Hi,
I think there is a mistake in BOT's HTML version within the section 4.1 BRICK Alignment Module. It says "The following namespace prefixes are used in the alignment to SOSA and SSN". Furthermore, there is a class alignment that it looks like it was borrwed from SOSA/SSN's page?
Just for your information.
Best regards,
Iker
When checking BOT with OWLAPI snippet:
File root = new File("Location of a local repository that contains bot.ttl");
IRI bot = IRI.create("https://w3id.org/bot#");
OWLOntologyManager m = OWLManager.createOWLOntologyManager();
m.getIRIMappers().add(new SimpleIRIMapper(bot, IRI.create(new File(root, "bot.ttl"))));
OWLOntology o = m.loadOntology(bot);
System.out.println("Start check");
OWL2DLProfile profile = new OWL2DLProfile();
OWLProfileReport report = profile.checkOntology(o);
for (OWLProfileViolation v : report.getViolations()) {
System.out.println(v);
}
I get the following violations:
Use of undeclared annotation property: http://purl.org/dc/elements/1.1/description in annotation [Annotation(http://purl.org/dc/elements/1.1/description "A simple ontology describing the topology of a building"^^xsd:string) in null]
Use of undeclared annotation property: http://purl.org/dc/elements/1.1/title in annotation [Annotation(http://purl.org/dc/elements/1.1/title "BOT"^^xsd:string) in null]
Use of undeclared annotation property: http://purl.org/dc/elements/1.1/Language in annotation [Annotation(http://purl.org/dc/elements/1.1/Language "en"^^xsd:string) in null]
Use of undeclared annotation property: http://purl.org/dc/elements/1.1/modified in annotation [Annotation(http://purl.org/dc/elements/1.1/modified "October 27th 2017"^^xsd:string) in null]
As reported by @mathib #43 (comment)
Regarding the mapping to DUL, I did a review of the mappings and this seems OK for me. Good job, Georg! Maybe the following can be considered for the alignment (?):
bot:intersectingElement rdfs:subPropertyOf dul:overlaps
bot:Interface rdfs:subClassOf dul:DesignedArtifact
bot:interfaceOf rdfs:subPropertyOf dul:hasCommonBoundary
We could define a simple Datatype Property to link a bot:Zone or bot:Element to its geometry
bot:hasSimpleGeometry a owl:DatatypeProperty ;
rdfs:domainIncludes bot:Zone , bot:Element .
that datatype property could link any bot:Zone or bot:Element to a literal that encodes its geometry. This could be left open and be defined as:
<site> a bot:Site ;
bot:hasSimpleGeometry """POLYGON((-77.050125 38.892086, -77.039482 38.892036, -77.039482 38.895393,
-77.033669 38.895508, -77.033585 38.892052, -77.031906 38.892086, -77.031883 38.887474, -
77.050232 38.887142, -77.050125 38.892086 ))"""^^geo:wktLiteral.
<element> a bot:Element ;
bot:hasSimpleGeometry """#VRML V2.0 utf8
Shape {
appearance Appearance {
material Material {
diffuseColor .8 0 .2
shininess .7
}
}
geometry Cylinder {
radius 1
height 8
side FALSE
top TRUE
bottom FALSE
}
}"""^^<https://www.iana.org/assignments/media-types/model/vrml>
I lost track of where the latest version is:
for the docs:
here in branch gh-pages vs lbd branch gh-pages
for the ontology
here in branch master vs lbd branch gh-pages
... is there some code duplication ?
ps. I just updated bot.ttl in this repo master branch
I think it would be great if BOT supported the concept of types/instances although I am having a hard time figuring out how to implement it.
I have worked on an example, which we should discuss at LDAC.
There are redundant labels in bot v0.3.1 , e.g. hasSubElement has two dutch labels:
´´´
hoster sub element
heeft sub element
´´´
Close issue after enhancement through:
As mentioned in #38. The current definition of bot:Site
says:
Site - Area containing one or more buildings.
A bot:Site is however a subclass of bot:Zone and also corresponds has a spatial 3D extent. Therefore, the definition in BOT should be updated to better reflect this. Proposal:
Site - a spatial 3D object containing one or more buildings
Maybe there should also be a reference to a standard defining the concept of site in a similar way? I'm unsure if there should be a closer connection to the human concept of "parcel"?
Currently the novel class bot:Site is not included in the closure constraint.
[] a owl:AllDisjointClasses ;
owl:members
( bot:Element
bot:Space
bot:Storey
bot:Building ) .
Some of the multi-language language labels have become updated after revisions of BOT
Supposed to be updated and a collection effort is running here:
https://docs.google.com/spreadsheets/d/1J5mEyblGU0M57XNpwQWxHbGlilRMzmCEqoU5FmOHILE/edit#gid=0
SPARQL query to filter bot concepts and properties with their language comments and labels from your local triple store:
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX owl: <http://www.w3.org/2002/07/owl#>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
select ?s ?lab ?des
where {
BIND( 'cn' AS ?lang )
{?s rdf:type owl:Class .
OPTIONAL{
?s rdfs:comment ?des .
?s rdfs:label ?lab.
FILTER (lang(?des) = ?lang )
FILTER (lang(?lab) = ?lang )
}
}
UNION
{?s rdf:type owl:ObjectProperty .
OPTIONAL{
?s rdfs:comment ?des .
?s rdfs:label ?lab
FILTER (lang(?des) = ?lang)
FILTER (lang(?lab) = ?lang)
}
}
UNION
{?s rdf:type owl:DatatypeProperty .
OPTIONAL{
?s rdfs:comment ?des .
?s rdfs:label ?lab
FILTER (lang(?des) = ?lang)
FILTER (lang(?lab) = ?lang)
}
}
FILTER( STRSTARTS( STR( ?s ), "https://w3id.org/bot#"))
}
As of #47
with a comment by @mathib (#47 (comment)):
Just noticed that bot:hasSubElement is not yet defined as being transitive.
In addition, the following additional property chain axiom might be beneficial and correct on >bot:containsElement:
owl:propertyChainAxiom ( bot:containsElement bot:hasSubElement )
In addition to bot:hasZeroPoint we should include a project rotation (ie. angle between project north and true north).
At the W3C call on October 9th this was agreed and just need to be implemented.
Currently bot:interfaceOf has a cardinality restriction of 2, which might be a problem.
For quantifying for instance a heat transmission area, it is correct that the cardinality will always be 2 (ie. the wall and the space), but for modelling linear transmission losses, one would need to specify the cold bridge as an interface between for instance two walls and a space or a window, a wall and a space.
Reporting here an email exchange I had with an senior researcher in the Semantic Web Community.
Zones, Buildings, Spaces, do have a spatial extent, but they should not be confused with their spatial extent.
The current definitions of bot:Zone and bot:Space is confusing wrt to this aspect.
We have DP bot:hasSimple3DModel (resp. OP bot:has3DModel) that link a zone to its 3D model encoded as a literal (resp. described using some dedicated ontology). This can be considered as the description of the spatial extent.
Aligning to Dolce:
Zone is some kind of redefinition of anything that has a spatial extent. So in a sense a "SpatialThing" with the understanding that "thing" also includes the interior of a boundary, and the boundary itself may be virtual It's really \exists hasSpatialExtent.SpatialExtent.
The distinction between spatial extent and spatial thing is primordial.
Re-including part of the Dolce terms definitions for clarity, we came to the conclusion that the following revision of the definitions would be important:
bot:Zone - A part of the physical world or a virtual world that is inherently both located in this world and having a 3D spatial extent; Sub-classes of bot:Zone include bot:Site, bot:Building, bot:Storey, or bot:Space. An instance of bot:Zone can contain other bot:Zone instances, making it possible to group or subdivide zones. An instance of bot:Zone can be adjacent to other bot:Zone instances. Finally, a bot:Zone can instantiate two relations to bot:Element, which are either contained in (bot:containsElement).
bot:Space - A part of the physical world or a virtual world whose 3D spatial extent is bounded actually or theoretically, and provides for certain functions within the zone it is contained in.
bot:interfaceOf
has no rdfs:range
or schema:rangeIncludes
defined, while the definition states:
Relationship between an interface and an adjacent zone or element.
Therefore, I would propose to add the annotation triples bot:interfaceOf schema:rangeIncludes bot:Element , bot:Zone .
to the definition
From 4 June 2018 (16:00 CET) telco meeting minutes (just one example):
[Documentation] First draft initiated: https://w3c-lbd-cg.github.io/lbd/bot/
while it should be https://w3c-lbd-cg.github.io/bot/
-- simon
domain of bot:hasSpace is a Storey. This is more specific than domain of saref4bldg:hasSpace (which is a building or a building space). if we consider that a storey is a building space, then bot:hasSpace is a sub property of saref4bldg:hasSpace
In Section 3.2 of https://w3c-lbd-cg.github.io/bot/, the first class mentioned is bot:Site, but the link points to bot:Building. There is another occurrence of bot:Site in the list of classes, where the link correctly points to bot:Site.
There are mismatches after changes between html docs and bot file e.g. hasZeroPoint
There has been a discussion on whether domain restrictions on
bot:hasBuilding, bot:hasStorey, bot:hasSpace
should be generalised to bot:Zone
or be kept restricted to e.g. bot:Building
.
See comments by me:
It is unclear to me why only bot:hasBuilding does not have bot:Zone as rdfs:domain but instead has bot:Site. Also bot:hasBuilding is a
rdfs:subPropertyOf
bot:containsZone
andbot:Site
is ardfs:subClassOf
bot:Zone
. We are breaking the pattern here applied tobot:Building
-bot:Space/ hasStorey
- hasSpace. From my experience on defining alignments the domain restrictions have been the main obstacle. I might want to use the bot:hasBuilding object property on something that is not abot:Site
.
and by @MadsHolten
Regarding the domain of
bot:hasBuilding
it was because the site is the only zone (in my opinion) that can host a building. With the domain being abot:Building
we automatically can infer all classesbot:Site, bot:Building, bot:Storey and bot:Space
only by the typed links between them which is strong in my opinion.
In essence there exists a trade off between semantic expressivness, e.g. automatically infer classes bot:Site, bot:Building, bot:Storey and bot:Space
vs. allowing BOT to be easily used as a top level in the AEC domain.
This issue should be solved at the LDAC 2017
Hi,
I cannot open or import the BOT ontology from the links provided with Protégé. I also tried to download the .ttl file and opening it with Protégé, but the result is the same.
Is anyone else having the same issue?
Iker
Hi All,
I was hoping you could clear up something for me. I have been looking over BOT and I was wondering how the concept of Space is being used?
The documentation says: Spaces may be contained in storeys, buildings, and construction sites and Spaces may intersect different storeys, buildings, and construction sites.
I see that a Storey hasSpace Space, am I correct in assuming this does not imply a contains relationship? What is the difference then between a space and a zone?
Kris.
Similar as #54 for bot:Site
, the definition of bot:Building
should be updated to reflect that it considers something that has a spatial 3D extent.
Definition in v0.3.1
An independent unit of the built environment with a characteristic spatial structure, intended to serve at least one function or user activity [ISO 12006-2:2013]
Proposal:
An independent unit of the built environment with a characteristic spatial structure, intended to serve at least one function or user activity [ISO 12006-2:2013]. A bot:Building is a part of the physical world or a virtual world that is inherently both located in this world and having a 3D spatial extent, is contained in a building site, and can contain one or more storeys that are vertically connected.
Hi!
most of the editing of BOT happens directly within the Turtle file using a text editor. However, it happens that typos occur and inconsistent files are uploaded to the github repository.
It might make sense establish an automated way to check a commit on consistency prior to merging it into the master branch. I know Continuous Integration from Travis CI for unit testing in software development projects. Does anyone know if this can be used for OWL2 ontology conformance testing?
Errata: ee04e35 should be fine, however the issue is still important.
We need to find a way to allow the access to the alignment ontologies via their URI.
For example the BRICK alignment ontology has this URI:
However, the redirect has not been implemented in the w3id
service. It would be great to change this. @maximelefrancois86 Is there a way to rewrite the htaccess to allow the use of the URI as above?
The original file is:
Options +FollowSymLinks
RewriteEngine on
# Turn off MultiViews
Options -MultiViews
AddType text/turtle .ttl
# In case of accept header <text/turtle>
RewriteCond %{HTTP_ACCEPT} ^.*text/turtle.*
RewriteRule ^$ https://w3c-lbd-cg.github.io/bot/bot.ttl [R=303,NE,L]
# If suffix ttl, redirect to turtle version
RewriteRule ^bot.ttl$ https://w3c-lbd-cg.github.io/bot/bot.ttl [R=302,NE,L]
# If suffix html, redirect to html version
RewriteRule ^bot.html$ https://w3c-lbd-cg.github.io/bot [R=302,NE,L]
# Default response: html
RewriteRule ^$ https://w3c-lbd-cg.github.io/bot [R=303,NE,L]
Maybe this could do the job:
Options +FollowSymLinks
RewriteEngine on
# Turn off MultiViews
Options -MultiViews
AddType text/turtle .ttl
# In case of accept header <text/turtle>
RewriteCond %{HTTP_ACCEPT} ^.*text/turtle.*
RewriteRule ^$ https://w3c-lbd-cg.github.io/bot/bot.ttl [R=303,NE,L]
# If suffix ttl, redirect to turtle version
RewriteRule ^bot.ttl$ https://w3c-lbd-cg.github.io/bot/bot.ttl [R=302,NE,L]
# If suffix html, redirect to html version
RewriteRule ^bot.html$ https://w3c-lbd-cg.github.io/bot [R=302,NE,L]
# Added by Georg:
# Redirecting to the respective alignment module
RewriteRule ^bot/BRICKAlignment$ https://raw.githubusercontent.com/w3c-lbd-cg/bot/master/BRICKAlignment.ttl [R=302,NE,L]
# Default response: html
RewriteRule ^$ https://w3c-lbd-cg.github.io/bot [R=303,NE,L]
Hi,
I am still having troubles reusing the BOT ontology. I tried importing the ontology in Protègè but it seems there is some problem. I with both "http://www.w3id.org/bot/bot.ttl" and "http://www.w3id.org/bot" URLs.
When I try to load the ontology, I get the following Load Error:
sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
How can I deal with this problem? Is there another way I can reuse the BOT ontology?
Thanks,
Iker
There's a problem with defining and using foaf:name as a datatype property because of a "datatype and annotation property ambiguity" in the source foaf ontology (see https://mailman.stanford.edu/pipermail/p4-feedback/2011-July/004010.html).
Other ontologies (e.g. SOSA, http://www.w3.org/ns/sosa/) use foaf:name as an annotation property.
If someone imports both SOSA and BOT, then the following error arises:
"Message: Illegal redeclarations of entities: reuse of entity http://xmlns.com/foaf/0.1/name in punning not allowed [DataProperty: name, AnnotationProperty: name]"
Possible solutions: not defining foaf:name as a datatype property? not using foaf:name at all?
Similarly as the new bot:hasElement
(superprop of bot:adjacentElement
and bot:containsElement
), there should probably also be a bot:hasZone
superprop for bot:adjacentZone
and bot:containsZone
?
Their might be a bug/ implementation error of BOT regarding its entity IRI and namespace
The entity is specified by the triple:
<https://w3id.org/bot#> rdf:type owl:Ontology .
Where there is no difference to the namespace:
@prefix bot: <https://w3id.org/bot#> .
I propose to change the entity IRI to the following (cf. also https://www.w3.org/TR/owl2-primer/, Section 8.2):
<https://w3id.org/bot> rdf:type owl:Ontology .
Probably this is causing also the problem with #39.
Best
Georg
We might want to ‘relax’ the domain restrictions (bot:Space) on the adjacentElement and containsElement properties, and not include the bot:Space domain restrictions. By doing so, a Site can also have an adjacentElement and containsElement relationship...
Up to now they have been removed completely from the ontology file.
In one of the upcoming next calls it should be determined whether outdated properties should be reintroduced, marked as deprecated.
Example:
bot:hostsElement a owl:ObjectProperty ;
rdfs:label "hosts element"@en ;
rdfs:comment "Relation between an element a) and another element b) hosted by element a). Example: inst:wall bot:hostsElement inst:window"@en ;
owl:deprecated "true"^^xsd:boolean .
The removed properties are:
bot:hostsElement
The current LOV entry for BOT is for BOT v0.2.0 and needs updating.
See https://lov.linkeddata.es/dataset/lov/vocabs/bto
I was wondering if their might be some ambiguity of the concept bot:Zone
rdfs:comment "An area or stretch of land
From our discussions and the subclasses drawn from Zone I was wandering if only mentioning Area and stretch of land in the description might be misleading as Zone describes things which have a volume.
The definition of the property bot:hasSubElement needs to be updated. It now still has the older definition:
hosts element - Relation between an element a) and another element b) hosted by element a).
The ISO Standard ISO 12006-2 is mentioned in some labels and comments but no reference is provided in the ontology document and html docs.
ISO 12006 Building construction - Organization of information about construction works - Part 2: Framework for classification, 2015. International Standardisation Organisation (ISO), Geneva, Switzerland.
Does it make sense to have an aggregation relationship in a topology ontology? Probably not. Isn’t it the idea to keep such things in the PRODUCT ontology only? => yes!
Documentation:
There is a need to annotate readme.md to clarify that alignments of BOT with other ontologies are provided.
Additional alignments:
At the moment the alignments are included with in bot.ttl. I would like to suggest to move the alignment into separate files similar to the approach in seas ontology alignment https://w3id.org/seas/SSNAlignment
I volonteer as assignee
elements adjacency currently cannot be represented, but is mentioned in the definition of an interface
As one bot:Zone instance cannot have a bot:adjacentElement AND a bot:containsElement to the same bot:Element instance, it would make sense to define them as disjoint properties in the BOT ontology?
If bot:containsElement is used from a bot:Space to a bot:Element, e.g.
inst:storey1 bot:hasSpace inst:spaceA .
inst:spaceA bot:containsElement inst:deskA .
one can infer correctly:
inst:storey1 bot:containsElement inst:deskA .
However, if bot:adjacentElement is used from a bot:Space to a bot:Element, e.g.
inst:storey1 bot:hasSpace inst:spaceA .
inst:spaceA bot:adjacentElement inst:wallA .
one cannot infer the following using BOT (which is correct):
inst:storeyA bot:containsElement inst:wallA .
This comes because this adjacent wall element can be adjacent to OR contained in the storey that contains the space, depending if the wall is resp. external or internal. If BOT would define a superproperty for bot:adjacentElement and bot:containsElement (e.g. bot:relatedElement), then one could infer from the above example with a propertyChainAxiom on bot:relatedElement (bot:containsZone bot:adjacentElement) that:
inst:storey1 bot:relatedElement inst:wallA .
The data modeler would have to define more precisely what the relation is between the storey and the wall: bot:containsElement or bot:adjacentElement.
The redirect from https://w3id.org/bot/bot.ttl is not working. Also content negotation on https://w3id.org/bot is not working. It redirects to an empty page: https://w3c-lbd-cg.github.io/bot.ttl
This probably should become https://raw.githubusercontent.com/w3c-lbd-cg/bot/master/bot.ttl?
Request by @deKlerk through a comment in LINK to update the definition of bot:Interface:
Current definition v0.3.1:
An interface is the surface where two building elements, two zones or a building element and a zone meet. It can be used for qualification of the connection between the two. A use case could be the qualification of the heat transmission area between a zone and a wall covering several zones.
Suggestion by @deKlerk:
An interface is the surface shared by two building elements, two zones or a building element and a zone. It can be used for qualification of the connection between the two. An example is the qualification of the heat transmission area between a zone and a wall covering multiple zones."
As at LDAC 2017 multilingual guests and speakers participate; we might ask them to provide for classes and object properties labels in multiple languages.
Languages added so far are:
Added could be
More over some of the comments require a revision after the lates release v0.2.0 e.g.
With some of the comments being commented in the current .ttl file
See [BCP47]
A. Phillips; M. Davis. Tags for Identifying Languages. September 2009. IETF Best Current Practice. URL: http://tools.ietf.org/html/bcp47
Or
https://msdn.microsoft.com/en-us/library/ms533052(v=vs.85).aspx
Line 42 of the current BOT gives an error while loading in Stardog db. I've found that line 42 (owl:versionInfo "0.2.0"^^xsd:date
) was causing issues, as it assigns a wrong datatype of 'date' to the ontology version string. I also guess the version number should be updated (string and URI)?
On the HTML documentation, the namespace is defined as http://www.w3id.org/bot#
. In the Turtle file, however, the prefix declaration is with an HTTPS URL instead: @prefix bot: <https://w3id.org/bot#>
. (This URL is also without www.
.)
Similar as #54 for bot:Site
, the definition of bot:Storey
should be updated to reflect that it considers something that has a spatial 3D extent.
Current v0.3.1:
A level part of a building
Proposal:
A part of the physical world or a virtual world that is inherently both located in this world and having a 3D spatial extent, is contained by one or more buildings, and is intended to contain one or more spaces that are horizontally connected. Storeys of a building are connected by means of vertical connections such as elevators and stairs.
I added the line "contained by a one or more buildings", to describe situations where you have multiple buildings that are connected via e.g. a shared garage as a storey.
We might need to add a line to avoid ambiguity such as exists in natural language: "storey" vs "floor" (and maybe "level" from as used by Revit to denote storeys)? => this was discussed in a LBD call, but I don't know if it was resolved back then.. Proposal for addition:
A bot:Storey is not limited to the meaning of "floor" or "level" as exists in natural language: it encompasses both zones above and below ground.
If a bot:Space runs over multiple storeys (e.g. a stairwell), it could be useful if, besides the bot:hasSpace relation from the lowest bot:Storey to the bot:Space, an extra object property (e.g. bot:intersectsSpace) can be defined from the higher bot:Storeys that intersect with the bot:Space.
Example:
inst:storey1 rdf:type bot:Storey ;
bot:hasSpace inst:spaceA .
inst:storey2 rdf:type bot:Storey ;
bot:intersectsSpace inst:spaceA .
Dear all!
in the branch the SAREF4BUILDINGAlignment ontology and the BRICKAlignment ontology are revised to fit the novel semantics of the latest BOT ontology.
The branch needs to be synchronised with the master branch with the changes to the documentation and the BOT ontology. Then it can be merged. I would need some git support for handling this sync and merge.
Thanks!
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.