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:

simpleGeometry as a geo:wktLiteral

<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.

simpleGeometry as a Virtual Reality Markup Language

<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.

Example

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:

#64

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:

• the bot:Zone would be a sub-class of dul:PhysicalObject (or dul:PhysicalPlace),
• bot:has3DModel would be a sub-property of dul:hasRegion
• the range of bot:has3DModel would also be dul:SpaceRegion

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 and bot:Site is a rdfs:subClassOf bot:Zone. We are breaking the pattern here applied to bot: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 a bot: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 a bot:Building we automatically can infer all classes bot: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:

https://w3id.org/bot/BRICKAlignment#

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...

• [Georg Schneider] An addition to the BOT docs is needed to clearly state that BOT describes the topology of a building and not geometrical aspects. A link to suited approaches as the Regional connection calculus (RCC8) needs to be mentioned. A reference to the respective paragraph in the paper needs to be made.

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:

• English ""@en
• Danish ""@da
• German ""@de
• Italian ""@it
• Dutch ""@nl

Added could be

• French ""@fr
• ...

More over some of the comments require a revision after the lates release v0.2.0 e.g.

• bot:adjacentElement
• bot:hasSpace

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!