profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/pipauwel/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.
Pieter Pauwels pipauwel Eindhoven University of Technology Belgium http://pi.pauwel.be/

pipauwel/IFCtoRDF 37

IFCtoRDF is a set of reusable Java components that allows to parse IFC-SPF files and convert them into RDF graphs.

jyrkioraskari/IFCtoLBD 25

IFCtoLBD converts IFC (Industry Foundation Classes STEP formatted files into the Linked Building Data ontologies.

pipauwel/IFC.JAVA 19

JAVA class library for IFC

pipauwel/EXPRESStoOWL 11

EXPRESStoOWL is a set of reusable Java components that allows to parse EXPRESS files and convert them into OWL ontologies in the context of the Industry Foundation Classes (IFC).

TechnicalBuildingSystems/OpenSmartHomeData 10

This repository holds dynamic and static data of a smart home use case.

pipauwel/ifcParserLib 7

ifcParserLib is a set of reusable Java components that implement functionality for IFC file parsing.

pipauwel/IfcDoc 2

IFC Documentation Generator

pipauwel/product 2

Product Ontology

dennisrshelden/IFC.JSON-Viewer 1

An app that supports import of IFC.JSON open standard

pull request commentpipauwel/IFCtoRDF

ISSUE-34: Generate in-memory RDF graph

@lewismc tests run fine on my local machine, but not in the GitHub workflow action. Expected output is not found. Could you please check what the problem is? Thank you so much.

fkleedorfer

comment created time in 2 months

push eventpipauwel/IFCtoRDF

Pieter Pauwels

commit sha 2f3cdb8d9d1ffd00f872b201fb7e3bb5902b7357

update path of expected output

view details

push time in 2 months

push eventpipauwel/IFCtoRDF

Pieter Pauwels

commit sha 7317f3f1c8c2a47baa08b36014b98a711fd17fee

fixed tests

view details

push time in 2 months

issue commentpipauwel/IFCtoRDF

The .ser files

Thanks, I'll be looking forward to a pull request, or a more detailed suggestion. I am aware that there are better ways than reloading serialised objects from .ser files. It is very exciting to see that you found a solution.

jyrkioraskari

comment created time in 2 months

pull request commentpipauwel/IFCtoRDF

ISSUE-34: Generate in-memory RDF graph

@fkleedorfer it means that I am taking in this pull request, nothing else. Merging a complete fork sounds impossible to me, without at least a more detailed meeting and review.

@fkleedorfer: It would help me and @lewismc if you could generate specific ISSUES in this repository that you would like to see improved or revised. This allows us to take in specific PRs that target particular issues with marked issue numbers (see pull request check made by @lewismc). We also need to keep track of improvements on specific issues to be able to mark progress and changes in the changes.MD file that is used to generate a new Release. @lewismc can definitely help with this and is trying to do that. That makes things a bit more feasible on our side, and avoids having to "take in complete forks".

On a general note, we (or anyway I) did have a plan to reduce memory usage, also by avoiding to take too much into memory and reducing memory-intensive dependencies like Jena. I don't think we can avoid the Jena dependency, but the use of these serialised files (.ser) for types and entities is something that could really be improved. If you see a way out of those, that would be amazing.

fkleedorfer

comment created time in 2 months

push eventpipauwel/IFCtoRDF

Florian Kleedorfer

commit sha 7f4a075674186e061a04818736252c13cae02032

Upgrade jena and junit dependencies, improve tests With this commit, the tests provides more helpful output as to why they fail (if they do).

view details

Florian Kleedorfer

commit sha c78ad297787f4dc746961923c33d4c09b4a39658

fix typo

view details

Florian Kleedorfer

commit sha e186d494b6a65a46e1f9df3697a427334fb95e21

Merge branch 'master' of https://github.com/pipauwel/IFCtoRDF  Conflicts:  pom.xml  src/test/java/be/ugent/TestIfcSpfReader.java

view details

Florian Kleedorfer

commit sha 8bdad6de3999a9fe71a5d4708b52a1a589357296

Optionally produce in-memory RDF graph Adapts the interface of RDFWriter slightly so it's possible to pass it a graph that the converted IFC content is written to. This change is also used to adapt the tests.

view details

Florian Kleedorfer

commit sha 537abdb66db00cc7ad13bebf082e00a54d3b0346

Add writing to StreamRDF

view details

Florian Kleedorfer

commit sha c2e03861190f200245849ed4e10fcce5df397c25

Add writing to StreamRDF to IfcSpfReader * also refactors the code a bit to avoid duplication

view details

Florian Kleedorfer

commit sha 7669eafc0f3724464dca191f2824762f14243256

Improve logging Before this commit, the application generates too much log output, which uses way too many resources (IDE freezing up). This commit reduces log output to a minimum by using loglevel debug for most log statements.

view details

Pieter Pauwels

commit sha 32847123e4a962c040850191f15897acd0189202

Merge pull request #35 from Merkmalservice/refactor-interface-and-tests ISSUE-34: Generate in-memory RDF graph

view details

push time in 2 months

PR merged pipauwel/IFCtoRDF

ISSUE-34: Generate in-memory RDF graph

Issue: #34

This PR adapts the interface of RDFWriter slightly so it's possible to pass it a graph that the converted IFC content is written to. This change is also used to adapt the tests.

PR Checklist:

  • [x] there is an open issue on the IFCtoRDF issue tracker which describes the problem or the improvement.
  • [ ] the issue ID (ISSUE-XXXX)
    • [x] is referenced in the title of the pull request
    • [ ] and placed in front of your commit messages surrounded by square brackets ([ISSUE-XXXX] Issue or pull request title)
  • [x] commits are squashed into a single one (or few commits for larger changes)
  • [ ] IFCtoRDF is successfully built and unit tests pass by running mvn clean test
  • [ ] there should be no conflicts when merging the pull request branch into the recent master branch. If there are conflicts, please try to rebase the pull request branch on top of a freshly pulled master branch.

Sorry:

  • This PR is based on my previous one, #29, which is still pending. There is just one additional commit here.
  • The tests fail because the test cases still need updating
  • EDIT: Had to add another commit (write to StreamRDF)
  • EDIT: Had to add another commit (improve logging)
+289 -132

14 comments

4 changed files

fkleedorfer

pr closed time in 2 months

push eventpipauwel/IFCtoLBD

Pieter Pauwels

commit sha 9c9698221372457655014cd12516ea41fe545552

enabled conversion and inclusion of 3D geometry as WKT strings

view details

Pieter Pauwels

commit sha 01999b721bc3604581a072517d6e2987d8a45f43

enabled conversion and inclusion of 3D geometry as WKT strings

view details

Pieter Pauwels

commit sha 8e62fe7168a03fe5c5e20a808bf6963a7434d0b1

updated geometry processing to temporary version

view details

Pieter Pauwels

commit sha 324c5c7b133b0b80a046ddeb2ee0eac04cb3c69a

small edits value cleaning

view details

push time in 2 months

push eventpipauwel/IFCtoLBD

Pieter Pauwels

commit sha 324c5c7b133b0b80a046ddeb2ee0eac04cb3c69a

small edits value cleaning

view details

push time in 2 months

pull request commentpipauwel/IFCtoRDF

ISSUE-34: Generate in-memory RDF graph

IFCtoRDF and IFCtoLBD are very different, in several ways. In addition, this diversity of converters is in general also very confusing:

  • IFCtoRDF code here = the code you have been looking at
  • IFCtoLBD code at https://github.com/jyrkioraskari/IFCtoLBD: code that reuses and supports IFCtoRDF conversion as well as LBD in a number of levels of complexity -> you'll have to ask @jyrkioraskari about the status
  • IFCtoLBD code at https://github.com/pipauwel/IFCtoLBD: much more simplified conversion code that does not go through the entire ifcOWL conversion and delivers only simplified output. This fork diverged a lot from the repo by Jyrki, and I don't think it will go back there (no PR). This code relies on IFCtoRDF only to parse the IFC file. Code is very simple and incomplete in output (plus has a geometry branch).

Regenerating SPF files from IFCRDF has been done in one of the repositories here: https://github.com/BenzclyZhang. So that proves it is possible, so you may want to scroll through that, Yet, why would one go back to a STEP file.

LBD graphs: yes, size is a lot smaller. But a lot of content is also kept out, and there is no way to go back to the original IFC file. This version (IFCtoLBD) then also diverges from what buildingSMART certifies.

I am looking forward to seeing which choices you will be making :) (and I will close this issue at some point)

fkleedorfer

comment created time in 3 months

pull request commentpipauwel/IFCtoRDF

ISSUE-34: Generate in-memory RDF graph

yes... well, when it comes to changing the output, then all sorts of other mechanisms start happening, as there are many opinions in that area, and then it better happens closer to BuildingSMART. That is of course possible, it just needs to take the correct route.

This IFCtoRDF version assumes a number of criteria, most importantly that it is based on the EXPRESS schema, which does not have that linenumber as an attribute - it is just native to the STEP language.

When stepping away from that criterium, it is possible to create better RDF graphs, which is/was the point of this IFCtoLBD conversion route (https://github.com/pipauwel/IFCtoLBD) that takes an entirely different approach for example regarding geometry and relations.

Before overly committing in code, be sure to sync with the Technical Roadmap of buildingSMART (leon.vanberlo@buildingsmart.org) so that your programming efforts can be of direct use and benefit.

fkleedorfer

comment created time in 3 months

pull request commentpipauwel/IFCtoRDF

ISSUE-34: Generate in-memory RDF graph

Thank you, @fkleedorfer. I noticed the different commits, PRs, and so on, and I go through them. I don't mind doing the full review and detailed double-check with the test data that I have and know. I just need a good moment in time (ideally today or tomorrow).

Thanks indeed for keeping out the extra commits for now. I don't mind adding them further down the road, so that the forks align as good as possible. Thanks a lot for sharing!!

fkleedorfer

comment created time in 3 months

issue commentpipauwel/IFCtoRDF

On deduplicating property values

These line numbers are internal object identifiers that are known and used inside the SPF file only (so I would always try to abandon them asap). If the rest of the line is identical, then the object has the same content (CartesianPoint X == CartesianPoint Y). So it is fine to simply use the same object (one instead of two - de-duplication). Yet, indeed, if one of those changes, one needs to be aware that it affects all occurrences. So therefore I backtracked and found it safer to keep them duplicate and just keep it as it comes in in the SPF file.

You seem to be talking about property values and duplicates there. If I am reading you correctly, keeping duplicates:

  • speeds up conversion time
  • keeps correct content
  • is safer if one makes edits
  • and there are no drawbacks (?)

In that case, it seems reasonable to maintain the duplicates during conversion. Do you see difference in the output?

fkleedorfer

comment created time in 3 months

issue commentpipauwel/IFCtoRDF

On deduplicating property values

If my memory does not abandon me here, this had been implemented using the --removeDuplicates flag / removeDuplicates option: https://github.com/pipauwel/IFCtoRDF/blob/3a884abb41420a47be80b38141e277a9dcb25993/src/main/java/be/ugent/IfcSpfReader.java#L54.

I thought that this was by default disabled, and output is thus by default simply generated as 'another couple of triples to represent the re-occurrence'. This is indeed preferred, because this would indeed avoid that, when somebody modifies the value, it is not modified for all references to that line.

Note that this code assumes IFC, which is by default read-only. I would not encourage modifying the content of the IFC, either in SPF or RDF, except if you really know what you are doing and it is small-scale. It requires a different software setup, imo.

fkleedorfer

comment created time in 3 months

pull request commentpipauwel/IFCtoRDF

ISSUE-34: Generate in-memory RDF graph

Hi both, yes that sounds fine. I'll do the merge and make the fix of the tests. Please give me some time. Thank you for your efforts.

fkleedorfer

comment created time in 3 months

pull request commentpipauwel/IFCtoRDF

Upgrade jena and junit dependencies, improve tests

I have not looked in detail yet, but I have a small note about the occasional: ERROR [main] (IfcSpfParser.java:189) - *ERROR 6*: Reference to non-existing line number in line: #1= IFCAPPLICATION(#3,$,$,$);

These errors are meant to pop up (as messages), because these specific test files are faulty IFC input files (indeed the line number is non-existing). So this test tests whether those errors are caught, output is zero, and code proceeds.

I'll repeat that this error handling and testing strategy needs to be improved.

fkleedorfer

comment created time in 3 months

issue commentpipauwel/IFCtoRDF

Upgrade IFCtoRDF to JDK11

@lewismc I agree, do you care to help with that?

lewismc

comment created time in 3 months

pull request commentpipauwel/IFCtoRDF

Upgrade jena and junit dependencies, improve tests

Thanks people, I fully agree that tests can be improved. The help is much appreciated.

fkleedorfer

comment created time in 3 months