google / digitalbuildings Goto Github PK
View Code? Open in Web Editor NEWDigital Buildings (ontology and SDK) currently being used by Google internally to manage our own buildings.
License: Apache License 2.0
Digital Buildings (ontology and SDK) currently being used by Google internally to manage our own buildings.
License: Apache License 2.0
Describe the bug
The Instance validator seems to be having performance issue when used with a python version higher than 3.6.8
To Reproduce
Run with python 3.9.1 for example
Expected behavior
The validator will take up to 8 min in the phase after:
Generating universe ...
Universe generated successfully
OS (please complete the following information):
MacOs
Describe the bug
When i run instance validator against an building_config.yaml file I now get the following error output error:
oli@zerocool:~/temporary/digitalbuildings/tools/validators/instance_validator$ python3 instance_validator.py -i /media/sf_shared/Building_Config_Test.yaml
Starting validator...
Starting universe generation...
Starting config validation...
Loading config files...
Validating syntax please wait ...
Opening file: /media/sf_shared/Building_Config_Test.yaml, please wait ...
Starting config validation...
Validating entities ...
Traceback (most recent call last):
File "instance_validator.py", line 104, in
handler.RunValidation(args.filenames, args.modified_types_filepath,
File "/home/oli/temporary/digitalbuildings/tools/validators/instance_validator/validate/handler.py", line 96, in RunValidation
entities = _ValidateConfig(filenames, universe)
File "/home/oli/temporary/digitalbuildings/tools/validators/instance_validator/validate/handler.py", line 67, in _ValidateConfig
return helper.Validate(entities, config_mode)
File "/home/oli/temporary/digitalbuildings/tools/validators/instance_validator/validate/handler.py", line 224, in Validate
if not validator.Validate(current_entity):
File "/home/oli/temporary/digitalbuildings/tools/validators/instance_validator/validate/entity_instance.py", line 84, in Validate
return iv.Validate(entity) and gv.Validate(entity)
File "/home/oli/temporary/digitalbuildings/tools/validators/instance_validator/validate/entity_instance.py", line 433, in Validate
if not self._ConnectionsAreValid(entity):
File "/home/oli/temporary/digitalbuildings/tools/validators/instance_validator/validate/entity_instance.py", line 305, in _ConnectionsAreValid
if not (self.universe.connection_universe and entity.connections):
AttributeError: 'ConfigUniverse' object has no attribute 'connection_universe'
I have tried this with both my custom building_config and also the suggested demo version from fake_instances/GOOD/good_building_connections.yaml
When I tested against a previous version of the DBO the file validated.
To Reproduce
Steps to reproduce the behavior:
python3 instance_validator.py -i "path to building instance"
Expected behavior
I expected the validator to either validate or report on what was not configured correctly within my building_config.yaml
I'm in the middle of a literature review on the current state of building ontologies. I believe digitalbuildings
warrants inclusion. Do you have any publication, if not it would be nice if you added a citation section to the readme?
Creating a DOI would be nice as well - https://github.blog/2014-05-14-improving-github-for-science/
line 215 - setpoint: "Control target of process or system."
Although Wikipedia and the Collins English Dictionary might suggest otherwise. I believe the tag "setpoint" relates to the English phrase "set-point" as it relates to a target quantity that has been set for a controlled variable.
The following is the result of the ontology validator.
Starting Yaml Validator!
Findings in fields/telemetry_fields.yaml
ERROR : Field "water_leak_sensor" is not a valid construction
Findings in SAFETY/entity_types/ABSTRACT.yaml
Traceback (most recent call last):
ERROR : Field name "water_leak_sensor" is undefined.
The second error is redundant and confusing.
A few options:
There is a path bug in the instance validator when it is called from a different folder.
To Reproduce:
python3 ./tools/validators/instance_validator/instance_validator.py -i ./ontology/yaml/resources/pis.yaml
output:
Validator starting ...
Passed syntax checks!
Generating universe ...
UnitUniverse undefined in ConfigUniverse
FieldUniverse undefined in ConfigUniverse
Universe generated successfully
Invalid namespace: FACILITIES
Invalid type
ch-zrh-eurd is not a valid instance
file content example:
ch-zrh-eurd:
type: FACILITIES/BUILDING
id: 17400aae-c49a-49d4-a585-8a234f29532d
# Floor 08
ch-zrh-eurd-08:
type: FACILITIES/FLOOR
id: 36092aaf-4a0b-4961-b209-6d01f823b440
connections:
ch-zrh-eurd: CONTAINS```
The duct furnaces currently observed are essentially AHUs with heating-only (and in observed instances some type of recirc damper).
They handle outside air and return air, and meet the current definition of an AHU. Either propose an additional rule for distinguishing DFR from AHU, or consolidate.
I don't think chilled
water is pure H2O
. Chilled water is a solution
.
There's a lot to do here.
Certain devices send multistate data that should be mappable to the same standard state in DBO. Here is an example:
discharge_fan_speed_mode:
present_value: "points.discharge_fan_speed_mode.present_value"
states:
HIGH:
- "1"
- "4"
MEDIUM:
- "2"
- "5"
LOW:
- "3"
- "6"
VFD: "7"
"OFF": "0"
The instance validator does not support this type of 1:many definition for standard states; it will be necessary to modify it to support this mapping.
Ontology_match_lib.py is great to find the closest type with the proximity level e.g. NONE, CLOSE, INCOMPLETE and EXACT. May I suggest to enhance the tool so it can display the closest set of abstract types?
For example, a FCU consist of the following point:
real_fields = {
"chilled_water_valve_percentage_command",
"chilled_water_valve_percentage_sensor",
"discharge_fan_run_command",
"discharge_fan_run_status",
"schedule_run_command",
"zone_air_temperature_sensor",
"zone_air_temperature_setpoint",
}
fit = ont.find_best_fit_type(real_fields, 'HVAC', 'FCU')
When I ran the tool, it would display the following result:
MATCH COMPLETENESS: 'INCOMPLETE'
MATCHED TYPE: 'FCU_DFSS_DFVSC_ZTC_CHWZTC_DTC_CO2C'
ACTUAL FIELDS TYPE FIELDS REQUIRED
======================================= ======================================= =======================================
chilled_water_valve_percentage_command chilled_water_valve_percentage_command True
chilled_water_valve_percentage_sensor chilled_water_valve_percentage_sensor False
discharge_air_temperature_sensor True
discharge_air_temperature_setpoint True
discharge_fan_run_command discharge_fan_run_command True
discharge_fan_run_status discharge_fan_run_status True
discharge_fan_speed_percentage_command True
schedule_run_command schedule_run_command False
zone_air_co2_concentration_sensor True
zone_air_co2_concentration_setpoint True
zone_air_temperature_sensor zone_air_temperature_sensor True
zone_air_temperature_setpoint zone_air_temperature_setpoint True
The closest type it returned was FCU_DFSS_DFVSC_ZTC_CHWZTC_DTC_CO2C (a new type created by me for another FCU device). Due to the match completeness was ‘INCOMPLETE’, so it still did not fulfil the requirement. Upon looking for the most appropriate abstract types, I could get CHWVM, DFSS and ZTC to create the following new type:
FCU_DFSS_CHWVM_ZTC:
id: "8815310973633036290"
description: "tbc"
is_canonical: true
opt_uses:
May I know whether you could enhance the tool to display the following extra table? By viewing the below example, I could easily know that I need to create a new type with the abstract type listed in the table.
ACTUAL FIELDS TYPE FIELDS ABSTRACT
======================================= ======================================= =======================================
chilled_water_valve_percentage_command chilled_water_valve_percentage_command CHWVM
chilled_water_valve_percentage_sensor chilled_water_valve_percentage_sensor CHWVM
discharge_fan_run_command discharge_fan_run_command DFSS
discharge_fan_run_status discharge_fan_run_status DFSS
schedule_run_command schedule_run_command
zone_air_temperature_sensor zone_air_temperature_sensor ZTC
zone_air_temperature_setpoint zone_air_temperature_setpoint ZTC
Looking for additional MQTT Datapoint name (descriptors, etc) for the following (BMS points) Internal PID loop Variables for AHU, FCU, PACU. There is no current sub fields for say Proportional, Integral, Derivative gain values.
BMS Point name:
Zone Temp HTG PID P gain
Zone Temp HTG PID I gain
Zone Temp HTG PID D gain
Zone Temp HTG PID Interval
Zone Temp CLG PID P gain
Zone Temp CLG PID I gain
Zone Temp CLG PID D gain
Zone Temp CLG PID Interval
Thanks
Hello,
I am trying to understand the ontology. However, I found it a little bit complicated but it seems to be interesting.
I would like to know if there are any mappings to Brick, SSN, or SAREF, this may enhance my understanding of the ontology.
Thank you,
Amir
We currently support users providing the --input parameter multiple times to validate multiple individual files. It would also be useful to have an --input-dir parameter that lets the user validate an entire directory without individually specifying all the files contained within.
The point type alarm is multistate, and therefore requires state definitions. Update the logic of the validator to enforce this.
When adding new YAML object types, how do you generate the 19-20 digit ID string?
That every id attribute being divisible by 4 would seem to imply it's auto-generated, though I cannot find any such auto-enumerator or other schema within the repo.
Does the validator generate said id string on some kind of merge trigger?
Cheers,
Drew
Describe the bug
At the moment one unit is mapped only to one physical quantity name.
However there are many cases where a unit can measure physical quantities with different aliases.
For instance meters can measure length, height, level, etc.
There are also many adimensional quantities that would map to no_units (typically ratios and factors, like power factor or daylight factor).
I suggest to add the possibility to have "aliases" of quantities.
For instance for "meter" the main quantity would be "length" and it can have "level", "height", "width" as aliases/synonyms.
Thanks!
To Reproduce
N/A
Expected behavior
N/A
Screenshots
N/A
OS (please complete the following information):
N/A
Additional context
N/A
MODEL_HVAC.MD is out of date (not all general types are included). Add descriptions for all of these.
Also add similar documents for the other namespaces.
For the instance validator, change the pattern of multiple variable assignment to use a NamedTuple.
I apologies if my contributions so far have not been received well. It was my intention to make a constructive contribution, but I think I have made some mistakes with the way I have engaged with this so far.
digitalbuildings/ontology/yaml/resources/subfields/subfields.yaml
line 50 - building: "Applies to the entire building or group of zones within building (e.g. Building_Air_Static_Pressure_Sensor)"
In the case of a "Building_Air_Static_Pressure_Sensor", I assume this tag means the static pressure of the index run ductwork supplying fresh air to the building. I assume it's not a weighted average of static pressures within the building itself, nor a group (perhaps an array?) of static pressures for each zone within the building. If I am correct here, the terms "index run" and "fresh air" would also need defining.
This looks like an interesting project! I'm curious as to what is the intended scope, especially in contrast to existing schemas like IFC. As stated in the readme, it does borrow heavily from Brick schema, so perhaps mentioning how it plans to fit into the Brick ecosystem would be interesting too :)
Section 3 of the RDF Example README alludes to the "Carson ontology" when instantiating business logic.
Simple question - where can one learn more about said Carson ontology?
I have exhausted the requisite 30 minutes of phrase searching across the broader web, and have read @charbull's PoCBoC paper twice. "Carson" doesn't appear there either.
The example in the README appears it could be a BAS SDK, not unlike OLGA or the ALC SDK I've worked with in the past. A way of representing hierarchical relationships in the BAS as objects, of sorts.
Curiosly,
Drew
How do you create an instance in RDF? I created a building config YAML file following https://github.com/google/digitalbuildings/blob/master/ontology/docs/building_config.md i.e.
# Building
UK-LON-S2:
type: FACILITIES/BUILDING
id: FACILITIES/123456
Running the validator on this works fine. But then I assumed you could pass this file to the rdf_generator
but the following
python rdfformat/rdf_generator.py --input=/home/david/dev/digitalbuildings/.data/building_config.yaml --output=/home/david/dev/digitalbuildings/.data/digital_buildings.rdf
throws the error
NotADirectoryError: [Errno 20] Not a directory: '/home/david/dev/digitalbuildings/.data/building_config.yaml/FACILITIES/entity_types/Facilities.yaml'
The help indicates:
rdfformat/rdf_generator.py:
--input: The path of the input file
--output: The path of the output file
But it actually appears to expect --input
to be the root folder of the ontology (which matches the readme)
Are there any tools to convert a building config into say a TTL file like Brick?
Describe the bug
Should the instance validator kick up an error when connections are used in the building_config.yaml file that are not defined within the ~/ontology/yaml/resources/connections/connections.yaml file within the ontology?
To Reproduce
Steps to reproduce the behavior:
ZONE-202:
type: HVAC/ZONE_HVAC
id: CDM/110111
connections:
UK-LON-X1_L02: CONTAINS
AHU-1: BOB
python3 instance_validator.py --input path/to/building_config.yaml
*$ python3 instance_validator.py --input /media/sf_shared/test.yaml
Validator starting ...
Generating universe ...
Universe generated successfully
Validating syntax please wait ...
Opening file: /media/sf_shared/test.yaml, please wait ...
Validating entities ...
All entities validated
Expected behavior
I expected the validator to fail as "BOB" is not defined as a connection in the connections.yaml
OS (please complete the following information):
OS - Ubuntu 20.04.02 LTS
Repository cloned from master on 4/3/2021
The classes under SubField/Measurement
and Unit
are equivalent sets (i.e. all classes are same). Why is this?
Additionally, in Protege, when I look at Unit/Concentration
(usages), parts_per_million
comes up (and confirmed in RDF):
However, when I then click on the Concentration below:
It actually resolves to the Subfield/Measurement/Concentration
class. Is this expected? Can others reproduce? Why does this happen?
Please could you describe the unit Kelvin
and why this is tagged as standard
?
How are units applied? i.e. units.yaml contains different units for flowrate with cubic_meters_per_second as STANDARD. We generally name points "Supply Air Flow" for the standard (our standard measure is l/s) and "Supply Air Flow ms" when there's a meter with a non-standard unit.
I don't see anywhere that units are associated with either fields or equipment, is this something which hasn't been finalized?
Also there's a broken link in ontology_config.md
line #280
Describe the bug
In IBRSDK demo, trying to export selected floors as separate IBRs. Dev tools shows Uncaught ReferenceError: download is not defined at HTMLButtonElement. Files do not download.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
I would expect multiple, independent IBRs consistent with the floors checked to automatically generate and download from the browser.
OS (please complete the following information):
MacOS Catalina v10.15.7
VS Code 1.51.1
Node v14.15.1
Additional context
I tried to troubleshoot by moving script further down index.html to see if it needed to load after the button, with no luck. Based on my limited exposure to Node, my best guess is that the index file is having an issue calling the download() function with three params in the got module.
Perhaps I have also missed an instruction elsewhere in the repo and simply don't have my local instance configured properly.
digitalbuildings/ontology/yaml/resources/fields/telemetry_fields.yaml
Lines 175 to 176 in d884a08
Parsers have issue with the above. Should have:
...
---
There is a battery_charge_status
in an entity type field, but the charge measurement is missing in the subfields.
Organize ABSTRACT types by function. Ex: all DX types should be in the same section, all SF types should be in the same section
We currently do not model the BMS (or other network) architectures distinctly from the system they control (e.g. HVAC). It may be desirable in certain deployments to model both the devices being controlled and the controllers themselves as separate entities.
Proposal: Add namespace for BMS (or NETWORK to be less specific) and define types/connections for it.
Describe the bug
Disjoint classes have extensions in common.
To Reproduce
from rdflib import Graph
db = Graph()
db.load("digitalbuildings.xml")
violations = db.query("""
SELECT DISTINCT ?classA ?classB ?violation WHERE {
?classA (owl:disjointWith|^owl:disjointWith) ?classB .
?violation rdfs:subClassOf* ?classA,
?classB .
}
""")
len(violations)
> 3358
Expected behavior
len(violations)
> 0
OS:
macOS Big Sur v11.4
note: divide concepts by point and entity
We have been told that the Remote/Local is the important parameter to be stored in the cloud database e.g. firestore. I have tried to search the equivalent point name defined in the telemetry field list, but I could not get any name that matches to it. May I know whether there is an existing name that is pointing to this “Remote/Local”
The value set for this “Remove/Local” SCADA point name is “Remote” and “Local”, and the definition of the value is shown as below:
Remote – The system is controlled remotely
Local – The system is controlled locally
Describe the bug
When installing the dependencies for the instance validator, the following error appears:
error: Setup script exited with error: command '/usr/bin/x86_64-linux-gnu-gcc' failed with exit code 1
To Reproduce
Steps to reproduce the behavior:
digitalbuildings/tools/validators/instance_validator/
python3 setup.py install --user
error: Setup script exited with error: command '/usr/bin/x86_64-linux-gnu-gcc' failed with exit code 1
Expected behavior
Able to install dependencies for the instance validator
OS (please complete the following information):
Linux, Debian x86
Additional context
Ontology validator was successfully setup. Issues encountered onl for the instance validator
Francesco to bring up in UDMI working group on 5/12
Okay, I'm about to get more critical - because I think this is an issue, not a question. I don't understand why this has been closed without answering the question?
I understand the project used OWL. I am not sure that immediately means that a meaningful Ontology has been created. There's a number of examples of unexplained jargon here. For example, how does this project describe what "Building Static Pressure" means (are things getting hotter)? What is a "setpoint" (am I about to achieve something in a tennis match)? Jargon is often discussed in this project, but not defined in an organised way. A meaningful Ontology needs to carefully describe domain specific terms used (perhaps with multiple understandable examples). Has this been peer-reviewed?
As a "model" this project wouldn't be open to such criticism and I think the term is a better fit at the moment.
Originally posted by @aidan-parkinson in #45 (comment)
This is great work. Good to see
However, the word "Ontology" to my understanding implies a high level of validity (to me at least). An example of which might be "energetics" and "quantum mechanics" as two fundamentally different types of observation.
Isn't this really another "Social Construct" representing quite a contextually dependent system of significant inherent bias? Why was the term "Model" not used for this project, as potentially a more valid and widely used term?
From my perspective there is a danger that the name of this project is over-selling its possible applications. Sorry to be a headache!
Describe the bug
Instance validator thread keep listening after the report is published
To Reproduce
Steps to reproduce the behavior:
run the validator on the s2 file
Expected behavior
After the report is published the instance validator needs to exit
Describe the bug
The ontology validator does not help the user to understand build failures because of the way it presents errors to the user.
For example:
ERROR : Unit "meters_per_square_second" has the unknown measurement type "linearacceleration"
What is the error? Is it with meters_per_square_second or with linear_acceleration? Pretty unclear. It also gives no guidance about what to fix.
Instead of raising the unhelpful error above, the validator should output something more like this:
ERROR : Subfield 'linear_acceleration' is undefined, but the unit "meters_per_square_second" references it. Define the subfield or assign the unit to another subfield.
This sort of user-friendly error message should be added everywhere, for everything.
@tasodorff @charbull I think brightness should be moved to measurement and not be a measurement descriptor.
Thoughts?
Thanks,
F
I'm watching this project with interest as it's aligned with my research topic (ML and built environment).
Do you intend on adding some examples? I think that would really help, i.e. a minimal yaml example and perhaps a tutorial on how to validate and generate a DRF. Also, it's not really clear to me what I'd do with the RDF, some notes on the application of RDF would be useful.
And do you intend adding some sort of mapping between the representation and the source data - i.e. the main use I have for any building representation is to enable me to query the BMS data I require for my models. So for each sensor I would want to include a field which would contain some sort of query string which would allow me to access a data lake the histories data was stored in, or perhaps the bacnet id's to directly query the BMS. I'm not 100% but neither Haystack or BrickSchema seem to address this other than having say a cur
and hist
tag.
Finally it's not really clear what the ibr project is all about. The readme implies it's a file format "that can be adapted to multiple use cases " but the example shows a building floorplan. It's not really clear how you'd adapt it to other use cases.
The instance_validator.py is the python script to validate a building ontology YAML file. In the YAML file, the type of device is compulsory e.g. FCU_DFSS_CSP_CHWDC. This instance_validator.py will validate whether the point name list for a respective device fulfills the requirement.
It is advisable to build a tool to extract the type of a device based on the list of point names of the device and the entity type it belongs to.
For example, if a user runs the tool to get the device type for FCU-11 with a list of points names e.g. pn1, pn2. The user would just need to pass in "FCU" entity type together with all the point names as the arguments e.g. tool --entity_type="FCU" --point_name="pn1, pn2". The output will retrieve the type e.g. FCU_DFSS_CSP_CHWDC.
Describe the bug
When trying to built the docker following this example, step 27/30 fails.
To Reproduce
Steps to reproduce the behavior:
% ./build-docker-image.sh
Using https://github.com/EcoStruxure/OLGA.git as git repo URL
Using master as git branch
Using OLGA as project
Using OLGA-Core,OLGA-Ws as subprojects
Using OLGA-Ws as Maven artifact ID
Using 0.0.5 as version
Using ecostruxure/olga:latest as the Docker tag
Sending build context to Docker daemon 3.584kB
Step 1/30 : FROM alpine/git as clone
---> 8f5f87e1dbac
Step 2/30 : ARG url
---> Using cache
---> af5efd494ea7
Step 3/30 : ARG branch
---> Using cache
---> 98dc352216ea
Step 4/30 : WORKDIR /app
---> Using cache
---> 4570109b47ff
Step 5/30 : RUN git clone -b ${branch} --single-branch ${url}
---> Using cache
---> e0520e2dc2a7
Step 6/30 : FROM maven:3.5-jdk-8-alpine as build
---> fb4bb0d89941
Step 7/30 : ARG project
---> Using cache
---> aeba4bf3d4f8
Step 8/30 : ARG subprojects
---> Using cache
---> 202620a431b2
Step 9/30 : WORKDIR /app
---> Using cache
---> 5e3e3bfbbe92
Step 10/30 : COPY --from=clone /app/${project} /app
---> Using cache
---> d5bcb57a8d71
Step 11/30 : WORKDIR /app/${project}
---> Using cache
---> ad0c768b884a
Step 12/30 : RUN mvn --projects ${subprojects} clean install -DskipTests
---> Using cache
---> 6c57ef6d40b4
Step 13/30 : FROM maven:3.5-jdk-8-alpine
---> fb4bb0d89941
Step 14/30 : ARG project
---> Using cache
---> aeba4bf3d4f8
Step 15/30 : ARG artifactid
---> Using cache
---> 3885bc681dc2
Step 16/30 : ARG version
---> Using cache
---> 0017c7c1897d
Step 17/30 : ENV artifact ${artifactid}-${version}-with-dependencies.jar
---> Using cache
---> fcfb5af4fe3c
Step 18/30 : ENV M2_HOME ${MAVEN_HOME}
---> Using cache
---> e88f4af25cd3
Step 19/30 : ARG REPO=mcr.microsoft.com/dotnet/core/runtime-deps
---> Using cache
---> 42d1902900f0
Step 20/30 : RUN apk add --no-cache icu-libs openssl-dev
---> Using cache
---> 432729cb87cc
Step 21/30 : ENV DOTNET_SYSTEM_GLOBALIZATION_INVARIANT=false LC_ALL=en_US.UTF-8 LANG=en_US.UTF-8
---> Using cache
---> 2ec1b2f24ffe
Step 22/30 : ENV DOTNET_SDK_VERSION 2.1.607
---> Using cache
---> 6944623b6da3
Step 23/30 : RUN wget -O dotnet.tar.gz https://dotnetcli.azureedge.net/dotnet/Sdk/$DOTNET_SDK_VERSION/dotnet-sdk-$DOTNET_SDK_VERSION-linux-musl-x64.tar.gz && dotnet_sha512='61caf6602b8a2aa89769b3e91ddaec963d8ab9f802cd7f6c6da4f02426358712bc2bb0930e7ee3a81d75c7607039543b554cb8ed50e45610655f9e91ed0f2f17' && echo "$dotnet_sha512 dotnet.tar.gz" | sha512sum -c - && mkdir -p /usr/share/dotnet && tar -C /usr/share/dotnet -xzf dotnet.tar.gz && ln -s /usr/share/dotnet/dotnet /usr/bin/dotnet && rm dotnet.tar.gz
---> Using cache
---> 26df7bcc17d7
Step 24/30 : ENV DOTNET_USE_POLLING_FILE_WATCHER=true NUGET_XMLDOC_MODE=skip
---> Using cache
---> b6972fd69e7f
Step 25/30 : RUN dotnet help
---> Using cache
---> 1e1ac47645cc
Step 26/30 : WORKDIR /app
---> Using cache
---> d1b6538e6ae4
Step 27/30 : COPY --from=build /app/${project}/${artifactid}/target/${artifact} /app
COPY failed: stat /var/lib/docker/overlay2/599d6faae67bccbef0c845ae0404d8ca76feea148940b305da03c788e46592b2/merged/app/OLGA/OLGA-Ws/target/OLGA-Ws-0.0.5-with-dependencies.jar: no such file or directory
Expected Behaviour:
Building of the docker is successful.
OS:
Ubuntu GNU/Linux 18.04 LTS
In the generation of RDF from yaml, it appears that when uses
are declared for a type, this translates into a rdfs:subClassOf
relationship. uses
, however, seem like they should be data properties on a type as opposed to a superclass, where I would expect implements
to define the superclass(es) for a type. Can you explain a little bit more how this works / why it works this way?
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.