dataesr/scientific-paragraphs-categorization huggingface dataset:
It can be used to demonstrate the entire building life cycle, including the processes of construction, operation, and maintenance  [83]. The BIM data is structured and defined using open BIM standards like IFC (Industry Foundation Classes). The integration of BIM and GIS can avoid unnecessary efforts in redundant modelling with focus on reusing the available data. For instance, models of buildings are produced in both domains for different applications, such as design and construction in BIM, and spatial analysis in GIS. With BIM and GIS integration, more detailed 3D city models can be built by reusing the BIM data. These enriched models can be used to perform environmental analysis, e. g. GIS can provide insight about flood-prone areas and give BIM designers detailed information to model the location, orientation, and even construction materials of structures such as buildings  [1].
Much work has been done on this integration, particularly of IFC and CityGML, which are two popular open standards in the BIM and 3D GIS domains  [2, 19-21, 24, 37, 47]. Despite several attempts, the two domains remain disconnected owing primarily to the differences in the underlying modelling approaches with respect to geometry, semantics, schema, level of detail, etc. [2, 20] ; a situation that we refer to as the BIM-GIS quagmire. Relevant to these efforts is the development of the new open standard LandInfra (Land and Infrastructure) by the OGC (Open Geospatial Consortium), which was designed as a 'connecting bridge' between the BIM and GIS domains (Fig. 1 ). LandInfra is an open conceptual data model for the representation of land and civil engineering infrastructure features. It integrates concepts from CAD (Computer Aided Design), BIM, and GIS, and has overlaps with CityGML and IFC.
For instance, many of the LandInfra feature types are similar Fig. 1  LandInfra a connecting bridge between IFC and CityGML, but is conceptually, semantically, and geometrically closer to CityGML to the thematic classes in CityGML, such as Building, Road, Railway, LandSurface (ReliefFeature in CityGML), etc. [55]. Furthermore, both LandInfra and CityGML use ISO 19107 geometry types  [25]  for representing the geometry of the features. Like CityGML, LandInfra also has a UML (Unified Modelling Language) based conceptual model and a GML (Geography Markup Language) encoding, InfraGML. In addition, the Land-Infra Alignment requirement class is based on the buildingSMART IFC Alignment 1. 0 standard  [55]. It was developed jointly by the OGC and the buildingSMART Infrastructure IfcAlignment project team to ensure interoperability between the two standards in the future.
In this paper, we thus start with a brief overview of CityGML, IFC and LandInfra, then proceed to describe how LandInfra is used in theory and in practice. Afterwards, we provide a comparative analysis of the LandInfra conceptual model with CityGML and IFC. We then present three real-world use cases that could benefit from a BIM-GIS integration using LandInfra. We also discuss some minor issues in the data model of LandInfra standard, which we found through our analysis of the standard. We close the article with conclusions and future work.
LandInfra and InfraGML Originally from the spatial world, LandInfra  [55]  was recently proposed as the successor to LandXML  [40]. LandXML is an XML based, open data model for the representing civil engineering and survey measurement data  [40]. It is not recognised as an official standard by any standards organization like OGC or ISO, which created a confusion in the marketplace concerning the future of the standard. To align LandXML with the OGC standards, a LandGML Interoperability Experiment  [50]  was initiated by the OGC in 2004 to make LandXML compliant with the OGC GML standard for geospatial data. Following this effort in 2013, LandInfra SWG (Standards Working Group) reviewed LandXML and made efforts to determine how to continue its support to the existing users in the best possible manner.
LandInfra (and InfraGML) in theory and practice LandInfra is a relatively young standard and at present it is difficult to identify any concrete examples of its usage in practice; the majority of scientific articles that mention LandInfra only describe the need to consider it in future work. There are many papers discussing the relationship between LandInfra and the ISO 19152 Land Administration Domain Model (LADM), see for instance  [15, 33, 34, 42, 66, 67, 78]. In these papers, InfraGML is cited, alongside other models such as CityGML and LandXML, in relation to harvesting the existing 3D data that is collected to open up the possibility of creating a 3D cadastral database. There are several papers discussing the integration of LandInfra in specific use cases. Kara et al. [34]  assessed the use of several different models to provide a valuation information model for property taxes.
The research also raised several important points such as the lack of flexibility for extensions in the LandInfra conceptual model and the unavailability of real world InfraGML datasets in practice. Devys  [17]  discussed interoperability, between the RailTopoModel  [81]  and Land-Infra, for railway infrastructure and proposed a mapping between the two models. Labetski et al. [39]  analysed the usage of LandInfra as a framework for extending the definition of the LODs for roads in the transportation module of CityGML, but found that the lack of the concept of levels of detail in LandInfra made it irrelevant. [49]  also propose to analyse LandInfra in the context of roads but for the purpose of determining limitations in current data standards for road assets and create recommendations towards an improved standard in order to apply SW (Semantic Web) technologies to build a prototype solution for road asset data conflation.
On the other hand, a number of software packages and libraries are available which can be useful for practitioners and researchers dealing with CityGML. Most of the software are recent and well-maintained. For instance, citygml4j 4 is an open source Java library for reading/writing CityGML datasets; 3D City Database  [84]  is a database solution to store, and manage CityGML models on top of a standard spatial relational database (PostGIS and Oracle); azul 5 and FZK 6 are popular CityGML viewers for macOS and Windows, respectively and so on. [16]  provides a list of available software for CityGML. IFC has the widest usage and software support among these standards, but the standard is implemented inconsistently by different software, which limits compatibility in practice. In particular, most BIM and building design software can export from its native (internal) formats to IFC, but there is a degree of information loss while doing so.
e. using ADEs or Generics in CityGML, and Property Sets in IFC. This would require the development of additional software support to handle such CityGML and IFC datasets. Furthermore, these extensions are essentially 'trial balloons' and are not official standards. They could be developed by anyone using different naming conventions and different geometric and semantic notations  [11]. Problems related to data interoperability between IFC and CityGML would still exist. < LandInfra provides a step closer in the integration of BIM and GIS by integrating these concepts in its data model to provide extensive semantic data for land and infrastructure features. Further, LandInfra is an official standard of the OGC, unlike CityGML or IFC extensions. As such, LandInfra can act as a connecting bridge between BIM and GIS for applications that need both types of data as shown in the use cases.
However, it is hard to claim that LandInfra is the answer to many BIM-GIS integration problems at present. First, as it stands, LandInfra is clearly a standard that is much closer to the standards of 3D GIS than to how objects are modelled in BIM world, which in practice will greatly limit its interoperability with BIM formats like IFC. Second, the data model of LandInfra cannot be extended or modified, which limits its use in practice especially since it aims as bridging different communities. Third, the current lack of example usage and available InfraGML datasets makes extensive testing and validation difficult. The fact that there is no software packages to read/write, edit, or manipulate LandInfra makes it rather difficult to convince practitioners to convert their datasets to it. We fear that without a push for open implementations and greater concern for the implementability of the standard, there is a danger that the standard will languish and be unused, as has been the case with a few OGC open standards.
In order to avoid this last issue, we are working on two solutions: (i) a LandInfra ADE for CityGML, which will encourage the adoption of LandInfra's features, and (ii) InfraJSON, a JSON based encoding for InfraGML, which can be explored at our public GitHub repository: https:// github. com/tudelft3d/InfraJSON. Despite the precedence set by the high usage of GML (XML) in various OGC standards, GML is a bulky and cumbersome encoding that is hard to use, and thus it is often disliked by both users and developers  [41, 79]. By contrast, JSON provides an easy-to-use and easy-to-read alternative, such as with CityJSON 10 , which is a JSON based encoding of CityGML. The research leading to this paper is a part of the research project 3D4EM (3D for Environmental Modelling) in the Maps4Society programme (grant No.
2. InfraGML is developed as a multi-part standard and each part has a separate XML schema file (XSD). When trying to validate an InfraGML dataset containing more than one type of requirement class (such as Facilities with LandSurface) against one XSD, validation errors are reported. A 'wrapper schema' (like in CityGML) which links the XSDs of all the parts of InfraGML is missing. 3. LandInfra Document class contains 'information in permanent form approved by one or more signature' [55]. It is derived from LandInfra Feature class and therefore has an optional spatial representation (spatialRepresentation). It is not clear what the spatial representation of a document could be: that described in the document, the spatial location where the document is located, or other possible interpretations.
Social network systems rely on very large underlying graphs. Consequently, to achieve scalability, most data analytics and data mining algorithms are distributed and graphs are partitioned over a set of servers. In most real-world graphs, the edges and/or vertices have different semantics and queries largely consider this semantics. But while several works focus on efficient graph computations on these "multi-semantic" graphs, few ones are dedicated to their partitioning. In this work, we propose a novel approach to achieve edge partitioning for multi-layer graphs, which considers both structural and edge-types (labels) localities. Our experiments on real life datasets with benchmark graph applications confirm that the execution time and the inter-partition communication can be significantly reduced with our approach.
All these proposals significantly improved the graph computations but the performance tends to degrade when the graph is particularly skewed, like the ones in social networks. In  [1] , the new version of GraphLab, named PowerGraph, is proposed to overcome the limits of previous solutions for computing real life graphs which follow the highly skew degree distribution (power-law graphs). They introduced a new computation model named GAS that factors the vertex program along edges, to achieve the scalability of graph computation via partitioning graph data by edge instead of vertex. The graph processing module in Spark, GraphX  [7] , also employs a similar idea to GAS but provides more edge partitioning strategies to program developers. In addition to their large scale, real graphs are also characterized by their heterogeneity.
In other words, the vertices and edges in real world graphs usually have different types or attributes, which can largely impact the execution of graph algorithms deployed over them. While some recent works deal with heterogeneous network partitioning  [8, 9]  or clustering  [10, 11] , much additional efforts are still required to transfer vertex partitioning to edge partitioning, and to consider the relation between locality and label distribution has not been studied well. In  [12] , the authors present the C 3 R framework to detect user communities based on novel regularized spectral clustering approach that is able to perform an efficient partitioning of multi-layer user relations graph. But the time complexity of the framework, which is introduced by the graph Laplacians computation is a limit for real (very large) datasets.
Experiments To evaluate our partitioning method on multi-layer graphs, we consider three graph-basic fundamental operations used in graph analysis and mining: Finding users with similar interest, Shortest Paths and Random Walk, over our real-world datasets. We conduct the experiments on a Spark(1. 6. 1) [16]  platform which is deployed on a 16 nodes cluster representing 100 cores. Observe that while the memory available allowed to store and handle our experimental datasets, we discard this centralized solution which was quickly outperformed by distributed solutions for our experiments. As the workload, i. e. , the number of edges, is balanced between partitions for each partitioning strategies used in experiments, we focus on the runtime of each method to evaluate their performance. TWITTER: An excerpt of Twitter with around 2 million vertices and 85 million edges corresponding to the sole f ollow links  [17].
There exists a label l on an edge (u, v) to depict the interest of u for the posts (tweets) of v on topic l. 17 labels are extracted from a supervised classification model to tag the different edges: leisure, technology, entertainment, labor, social, disaster, sport, life, environment, religion, law, politics, business, health, education, climate, war. HIGGS  [18]  dataset built from the graph derived from Twitter during the discussions and interactions on the news of discovery of elusive Higgs boson on 4th July 2012. For this dataset no topic is considered but we distinguished 4 different interactions between users extracted in this graph and used to tag the edges: following, replying, mentioning and retweeting. These datasets are large enough to illustrate the benefit of our partitioning approach.
In Figure  3 , we observe that for the Twitter graph the communication cost linearly increases with the number of partitions for all partitionings. However our partitioning strategy largely reduces the execution time. For instance with 100 partitions, we obtain a gain of 0. 84, 0. 3 and 0. 33 for the random, EdgePartition2D or PowerGraph partitionings respectively. We perform similar experiments with Higgs graph and results are depicted in Figure  4. Our method also outperforms existing ones for this dataset with a similar gain which enlightens that our approach remains efficient for graphs with a small number of distinct labels. Indeed, our partitions present a topic-homogeneity, so few distinct labels inside a partition, whatever the number of existing labels is. In plus we group edges based on topological proximity.
The rationale is that our partitioning considers the connectivity and the labels for building blocks. So the resulting partitions usually present large subgraphs extracted from restriction graphs. Since the shortest paths are computed on the restricted graph of a chosen label, the computation is more likely to stay within a partition and thus reduces the communications between partitions. For the competitors the vertices which belong to the same restriction graph are allocated to much more partitions. So the vertex replication factor will be higher and more messages between partitions are required when performing a computation leading to higher runtimes. We make similar observations for the Higgs dataset (Fig. 6 ), so our partitioning strategy is also efficient for graphs with less labels.
In Fig. 7 , we see the benefit of our partitioning algorithm when performing independent-label random walks on Twitter dataset with a 30%-70% decrease for the runtime compared to executions on partitions produced by GraphX strategies, and around 5-10% decrease for GraphLab. The rationale is that with our partition building the random walk is likely to remain in the same partition since our partition algorithm considers graph distance and labels. Fig. 8  presents the results for correlated-label random walks on Twitter dataset. We notice that our method, M etaBlock hasCM L, always provides the best execution times. The gain is even more important compared to independant-label random walks. This is due to our building which groups edges considering the topics and their correlation.
Conclusion In this paper, we present our approach for edge partitioning for multi-layer graphs which takes into account the locality of graph structure and the distribution of edge labels. We introduce new metrics, like Edge Connectivity Score and Blocks Profile Matrix, to determine the edge allocation. Our experiments on real-world datasets illustrate that the partitioning provided by our proposal allows different classical graph algorithms for graph analysis or graph mining to be executed much faster than when using another graph partitioning strategy. As future work, we first intend to extend our proposal to support more complex graph models, where for instance the vertices also have different types of labels. We also plan to investigate a self-adaptive mechanism to determine the different parameters of our algorithm such as the number of seeds.
35 This has been realized in single docking studies,  [36] [37] [38] [39] [40]  where two proteins known to interact are docked to each other, in arbitrary docking studies,  41  where proteins from a benchmark set are docked to arbitrarily chosen proteins, and in complete cross-docking (CC-D) studies,  11, [42] [43] [44] [45]  where all vs all docking is realized on a given dataset. In the present study, we combine these different types of information to decipher the complexity of protein surfaces and give clues about the many interactions a protein may have (Figure  1 ). Given a protein, we predict patches at its surface based on some intrinsic properties of that surface and on properties inferred from the behavior of the protein with respect to others in docking calculations. We F I G U R E 1 Schematic representation of our workflow.
We further exploit the way in which our predicted patches are grown, starting from a seed that is progressively extended. Specifically, we demonstrate that predicted patches' seeds can be used to localize IRs with high precision and to determine whether a protein has a few or many partners. We provide sets of experimentally known interaction sites and regions and CC-D results for our dataset of 262 proteins, along with a computational tool, called dynJET 2 , for predicting interacting patches based either on protein sequence and structure analysis or on any pre-computed residue based property. All data and implemented code are available at: http://www. lcqb. upmc. fr/dynJET2/. S1 ). This indicates a large variation of protein size inside the dataset (21 residues for the smallest protein vs 789 residues for the largest one).
| Protein interfaces: PPI-262 and PPI-262 ext We defined two datasets of experimental protein-protein interfaces, namely PPI-262 and PPI-262 ext (Figure  S1 ). Both datasets comprise only interfaces buried within "biological units" or "biological assemblies," as annotated by the authors of the PDB structure or by PISA software. 47 This ensures that the interfaces we consider carry a biological meaning. PPI-262 comprises 329 ISs (see definition below, in subsection Surfaces and interfaces) extracted from the PDB files associated to P-262 and PPI-262 ext comprises 370 IRs (see definition below, in subsection Surfaces and interfaces) defined from PDB files of close homologs of the proteins from P-262. To construct PPI-262 ext (see Figure  S1 ), we first searched for homologs of the 262 proteins from P-262 in the PDB.
We downloaded the pre-computed set of PDB structures clustered at 90% sequence identity from ftp://resources. rcsb. org/sequence/clusters/. This set was determined using BLASTClust with the arguments -p T -b T -S 90. We then filtered out structures with a resolution poorer than 5 Å resolution. 23 642 functional ISs were detected on these structures and were then mapped onto the query proteins from P-262 by performing global pairwise sequence alignment (using the blosum62 matrix, with the Biopython package  48  ). ISs were then merged into IRs.
| Complete cross-docking Given an ensemble of proteins, CC-D consists in docking each protein against all others in the dataset, including itself. CC-D was performed on P-262 using the MAXDo (Molecular Association via Cross Docking) rigid-body coarse-grained docking program. 42 Statistics were computed from the generated conformations (docking poses) to determine the propensity of each residue from each protein to be found in a docked interface. We define the interface propensity (IP) of residue i, belonging to protein P, as  11, 42  : IP P i ð Þ = N int,P i ð Þ N pos,P ð1Þ where N pos,P is the total number of docking poses considered for protein P and N int,P (i) is the number of docking poses where residue i lies in the interface. In order to limit the number of docked interfaces to reconstruct, which is the most time-consuming part of the analysis, we considered only the lowest energy docking poses (less than 2.
| Surfaces and interfaces A residue is considered to be at the surface of the protein if it displays at least 5% of relative accessible surface area (rasa), as computed by Naccess. 55 Experimental and predicted interfaces are exclusively comprised of surface residues. Experimental interfaces are detected on known PDB complex structures, considering only biological assemblies. We define two types of interfaces, namely interacting sites (ISs) and interacting regions (IRs). ISs are detected in single PDB structures by using the INTBuilder software  56  (www. lcqb. upmc. fr/INTBuilder/) with a distance threshold of 5 Å. They may represent single-or multiple-partner interactions (Figure  2A ). For instance, let us consider a ternary complex comprised of proteins P 1 , P 2, and P 3. If both P 2 and P 3 bind to P 1 but are not in contact with each other, then we will define two single-partner ISs at the surface of P 1 (Figure  2A , middle panel).
To construct PPI-262 and PPI-262 ext , we retained only ISs and IRs of reasonable sizes, that is, comprising more than five residues. Predicted interfaces are identified by the dynJET 2 software (www. lcqb. upmc. fr/dynJET2/). Given the sequence and the structure of a query protein, dynJET 2 predicts the location of potential protein binding sites on the protein surface. 24 dynJET 2 implements a clustering algorithm and scoring strategies specifically aimed at detecting the different layers of a protein interface, namely the support, the core and the rim. 57 These three layers are defined for known experimental interfaces by comparing their solvent accessibilities in the presence and absence of the partner. 24 Support residues are buried with and without the partner, core residues become buried upon binding to the partner and rim residues are exposed in the presence and absence of the partner.