dataesr/scientific-paragraphs-categorization huggingface dataset:
Response: Thank you for the suggestion. To address this comment and provide more discussion and conclusions to the survey, we added Section 4. 5 that summarises our observations with respect to the dataset profiling methods, updated Section 5. 8 that discusses our observations on vocabulary usage in RDF datasets and added Section 6. 6 that discusses dataset profiles in the context of the applications, which we made while reviewing respectively, dataset profiles extraction methods, vocabularies for representation of dataset profiles and features as well as applications. We have also expanded overall conclusions in Section 7. R1: Minor: * in the beginning of section 2, it is mentioned that the notion of an "atomic feature" is introduced, but it only described as a leaf in the hierarchy. It is unclear what those atomic features are in the end, why it is clear that they cannot be further subdivided, and why it is important.
Response: Thank you for the insightful comment. In the previous version of the survey, "Atomic feature" was used to describe a feature that has no descendants in the hierarchy. In the current version of the survey we revised the description of the features, such that the notion of atomic feature is not used anymore. * Please use a blank before a reference (i. e. , "reference [1]", not "reference[1]". ) Response: Thank you, we adjusted the format. * p. 3: "set of RDF triples shared" -I would rather suspect that two datasets share entities, but it is unlikely that they share exactly the same triples about those entities.
Reviewer R2: R2: First, there is a lack of precise framework defining the notions used. The paper actually does not define what is a dataset. This is not very strict, while catalogues and main used vocabularies like DCAT try to make crucial distinctions like dataset vs distribution. "Descriptive metadata, i. e. profiles" on p1 is also disturbing. Profiles are not limited to what is called descriptive metadata for many (e. g. , access metadata is not descriptive metadata). In fact for several communities working with descriptive metadata, the notion of "application profile" could conflict with the one of "dataset profile" that is quite different. Response: Thank you for the comment. As suggested by reviewer, to clarify the notions used in the survey, we added definitions of RDF dataset (in accordance to the VoID definition), RDF dataset profile and RDF dataset profile feature to the introduction of the survey.
R2: The state-of-the-art is very extensive, and constitutes a very useful resource for would-be reader. This is probably indeed the first time this is attempted at such a scale! But there are two problems with it: Even though it is extensive, it is incomplete with respect to dataset profiling. Authors focus on gathering references for dataset (quality) analysis. This is good, but there are important efforts that are not mentioned, about creating frameworks for expressing profiles, especially providing (or re-using) vocabularies. These could have been compared with what the authors proposed. DCAT and VOID are refered but the analysis is very cursory. More domain-specific efforts have been ignored: for example, the Health Care and Life Science community has researched a dataset profile ( http://www.
w3. org/2001/sw/hcls/notes/hcls-dataset/ ? ). In the geographic domain, the EU initiative GeoDCAT-AP should also be studied. The state-of-the-art on profiling and quality also misses reference to relevant ISO standards: domain-specific as for the geo ones that influence GeoDCAT-AP or more general like the ISO25000 family (esp 25012). Response: Thank you for the comment. The authors are aware that domain-specific approaches to profile and annotate datasets exist. However, to ensure high relevance and applicability, this survey focuses exclusively on cross-domain approaches, which are agnostic to the domain of the profiled data. We added this statement to the introduction of the survey to clarify the scope of our work. R2: There are inconsistencies in the way the references are used. First, in section 2 many references are given for different profiles features.
Most of them are data analysis papers. For a gathering of features, simple references to a vocabulary or inventory (e. g. a dataset catalogue) that exhibit the features would be enough to give a requirement for the topic. Actually this would be more convincing than a piece of academic work, possibly very technical, which may fall short giving a practical motivation for what it does (as the focus would be on an algorithm or an experiment). For example DCAT has properties for representing the domain/topic of a dataset. There is no need to refer to  [59]  that extracts such topics. On the other hand, section 3 that gathers methods to extract profile features doesn't refer to these papers that have been cited in section 2, that presents such methods. This is quite a missed opportunity. Furthermore, some of the references in section 2 seem superfluous for explaining what specific features are: I am not sure one would need both  [6]  and  [35]  ([6] looks more relevant) or both  [52]  and  [53]  or both  [36]  and  [37].
Response: Thank you for the comment. As suggested by the reviewers, we revised the references in Section 3. In particular, we attempted to be more explicit by citing technical papers in the feature definitions (note that some technical papers are cited explicitly as examples and not as references for the features). We also limited the citations to only the most relevant ones. With respect to the relevant vocabularies mentioned by the reviewer, in the revised version of the survey we provide an overview of vocabularies for representation of dataset profiles and features in Fig. 3   Response: Thank you for the comment. The citation [97] (  [86]  in the new version of the survey) was updated, as suggested by the reviewer. Regarding the choice of data quality dimensions, we note that there are different patterns for data quality dimensions in the Linked Data field, from which we cited  [9] ,  [77]  and  [85].
In this work, we collected commonly used quality features and we reordered them in a manner that matches the global dataset features profiles taxonomy that we introduce giving rise to the following groups of quality features: (1) Trust, (2) Accessibility, (3) Representativity, and (4) Context (cf. Section 3. 2). R2: In section 3. 2 the authors should make more explicit whether they re-use the matter of [97] for a subset of the systems there, if they extend that matter. If that section contains original material, it should be more explicit. If not, then it can be considerably shortened. Response: Thank you for the comment. The citation [97] (  [85]  in the new version of the survey), provides a detailed review of 21 general data quality assessment tools. In our survey (Section 4. 2 of the revised survey version), we summarized selected methods and techniques for dataset profile extraction with respect to the quality features according to the proposed dataset feature taxonomy.
We revised the description in Section 4. 2 to make it explicit. R2: In section 3. 3 it's unclear whether all systems mention really "extract" temporal characteristics (as written in the title of the section), or if they just manage them: -Semantic pingback as it is described in the text mostly focuses on cases where a dataset is being re-used in other sources. In principle the pinging doesn't change the content of the original dataset, and thus doesn't facilitate consistency and timeliness per se. It's possible that the publishers would integrate changes based on the pings, but it's not essential to the general pinging approach. Response: Thank you for the comment. In the context of the survey, we are interested in the service for dynamic features extraction in Semantic Pingback even if it is considered optional in the general pinging approach.
This system is particularly useful for detecting the stability of links/backlinks. We updated the description in the current Section 4. 4, to clarify this point. R2: -Memento is a mechanism to serve different time versions of data. It represents data that can be used to compute temporal characteristics (for example number of versions) but it doesn't extract them by itself. Response: Thank you for the comment. Here, we are mainly interested in the temporal relationships that the system can provide, i. e. , the first-memento, last-memento, next-memento and prev-memento. This system relates to the growth rate dataset profile feature. We updated the description in Section 4. 4 to clarify this point. R2: In section 4. 2 and 4. 3 tools are presented that compute statistics or make assessments based on them.
But these tools don't really motivate the need for statistics to be already expressed in a profile. On the contrary, they compute these statistics or extract features themselves, by querying the data and/or running inferences. It's not very difficult to extract say, the number of properties used in a dataset. And it's more reliable than using already published profile data, which could be outdated -for data assessment tools this is crucial. Response: Thank you for the comment. The applications for data curation, cleansing, maintenance (described in the section 4. 2 of the initial version of the survey) and schema inference (described in the section 4. 3 of the initial version of the survey) rely on the statistical characteristics of the datasets. Some of these applications can use, verify and update dataset profile features (e.
g. including statistical characteristics of datasets) and may in turn generate additional statistics that can become part of the dataset profile. We added a clarification of this point to the beginning of the application section (Section 6 in the revised version of the survey). R2: Then, the stats on vocabulary usage analysis in section 5 is very promising, but it doesn't look reliable. The data is from early 2015, probably it has changed one year later. There are some finding that are very surprising, such as Creative Commons being used only for 12 datasets. As the authors write it themselves later in the paper, there must be more data out there with CC Licenses. More importantly, it's uncertain whether table 2 really gives the info the authors claim it gives in the paragraph p17-18. The text says that LOD2 is used to find info on how many times a vocabulary is used in datasets.
But this doesn't mean that the vocabularies are used in these datasets for dataset profiling (i. e. to describe datasets, e. g. instance of dcat:Dataset). For example Dublin Core and FOAF can be used to described many types of resources that are not datasets. If the authors have indeed filtered in the LOD2 data the statements that are about datasets, this should be explained in more details. Without these details, one will infer that the data is not about datasets, and thus that it's not very informative for section 5 in general.
Response: We thank the reviewer for this observation. The reviewer rightly noted that just because a vocabulary is widely used, it does not mean that it is the best one for dataset profiling. Based on popular terms, however, we can suggest that they are more likely to be used if they are already known, and if they are also fit for purpose. We have updated the data as per the latest LOD2 statistics (re-checked 19 January 2017). The numbers show consistency in the usage of the main vocabularies and their reliability in terms of being stable/growing number of instances. The updated the corresponding table in the paper (Table  3 ). We have also added this sentence to the paper to reflect the above: " While we were unable to filter the instances of dataset profiling-specific terms from our suggested vocabularies while examining their usage statistics in LOD2, we can gain some insight into which ones may be more widely adopted by looking at the existing overall statistics and dataset usages.
It is reasonable to assume that users will be more willing to adopt terms from widely-used vocabularies for representing dataset profiles, as long as they are fit for purpose. " R2: Finally, the paper completely falls short on presenting the "RDF vocabulary for unambiguously identifying dataset features" that was promised in the abstract. A link is given to http://data. data-observatory. org/vocabs/profiles/ns , but the elements of this vocabulary are not listed and documented. And there's no instruction/example of how to use it. Shall it be combined with existing vocabularies? Is it an alternative to all of them, combined? Response: Thank you for the observation. In the revised version of the survey we focus on the systematic review of the existing vocabularies, rather than proposing a new vocabulary.
R2: Minor comments: R2: -p1: "As the Web of Data is constantly evolving, manual assessment of dataset features is neither feasible nor sustainable. " This statements is debatable. Sure, it won't be possible to profile all datasets manually, but one could argue that it would be a feature of good providers that they provide at least some profile metadata. Response: Thank you for the comment. Indeed, good providers would aim to provide profile metadata. Nevertheless, doing so manually on a regular basis, weil covering a broad range of features would not scale. We adjusted the wording in the paper to clarify this point. R2: -p5: the difference between stability of URIs and stability of links is quite unclear, as the only definition given to characterize the stability of links refers to stability of URIs.
Response: Thank you for the comment. Whereas the stability of URIs is rated with respect to the source dataset, the stability of links/backlinks is rated with respect to the stability of the linked URIs in other linked datasets. We adjusted the description in Section 3. 4 to clarify this point. R2: -p5: the relation between the references in section 3 and the criteria at 2 is unclear at times. For "selecting the smallest set of relevant predicates representing the dataset in the instance comparison task", do the predicates correspond to a specific criterion in section 2? (are they RDF this is supposed to tell what the literature says (knowing that not all scientific papers have large impact) or whether this is aiming to make a 'chosen' summary of that (the authors making a weighted account of what the literature has reported).
Response: Thank you for the comment. As suggested by the reviewers, Section 2, which is newly added, explains the adopted reviewing process and describes the nature of this survey explicitly by giving the reader a bird's-eye view on the RDF datasets profiling problem while providing some examples of worm's-eye view especially in terms of feature extraction methods, application-driven profiles and vocabularies for profiles representation. We also stress on the fact that this survey is dedicated to Linked Data but more specifically for RDF datasets profiling of which we have added concrete definitions to the introduction.
R3: When representing features, it would be good to perhaps include examples and concrete values to illustrate what they really are. Otherwise the true meaning of mentioning a feature is left too vague. The current text of the section looks like it could be equally well have been given as a simple table or list, but of course the section should do more as juts present a list; it should also make the reader understand how the list was composed. So, assuming that the content of the list is fair, it is recommended that the justification gets more attention. Response: Thank you for the suggestion. We revised the corresponding section (Section 3) and added an explanation on how the taxonomy of dataset profiling features in the survey was constructed along with more comprehensive description of the features.
R3: In section 3 the authors use the word 'review'. In addition to mentioning all the tools and approaches it would be interesting to see what the review entails. After all the review more or less by definition implies that the tools and approaches are considered from a chosen perspective and it would be good to clarify the perspective and its motivation. Response: Thank you for the comment. In addition to summarization of different features, methods, tools, vocabularies and applications presented in the initial version of the survey, in the revised version we have provided a systematic classification of these items with respect to a taxonomy containing semantic, qualitative, statistical and temporal categories of dataset profile features linking the items discussed in the survey to these categories, such that the reader can determine relevant features of a dataset profile as well as identify existing extraction tools and vocabularies for generating and representing relevant profile features.
(Section 5) and link them to the taxonomy of dataset profile features introduced in Section 3. (Section numbers refer to the revised version of the survey). R2: In 2. 2 there is a problem with the reference for the classification of quality characteristics, which is presented as coming partly from [97]. This is only an 'under review' paper, without URL nor publication context, so it's unclear what the source is. As a matter of fact the authors mention in [97] have published a very recent paper in this very journal, "Quality Assessment for Linked Data: A Survey: A Systematic Literature Review and Conceptual Framework", so I've used this one. When I've done the comparison, I found many differences, even some features that are classified in different dimensions, which I guess would be found in any recent work of the authors of [97].
includes the classes Dataset, DatasetDescription, LinkSet, TechnicalFeature. The authors distinct dataset from RDF graph, Terms, FOAF for general metadata and SCOVO -the Statistical Core Vocabulary 17 for statistical information. VoID is already widely used in the Web of Data, as documented by Table 2, depicting the use of VoID descriptions among the 1014 datasets and per category in the current inventory of the Web of Data Category Datasets (Percent) Social Web 6 (1. 16) Government 75 (40. 32) Publications 14 (13. 46) Life Sciences 29 (32. 58) User-gen. Content 6 (10. 91) Cross-domain 5 (11. 36) Media 2 (5. 41) Geographic 15 (36. 59) Total 140 (13. 46) Table 2 Adoption of VoID across LOD Datasets per Category (Source: http://linkeddatacatalog. dws. informatik. uni-mannheim. de/state/). where dataset refers to "meaningful collection of triples, that deal with a certain topic, originate from a certain source or process, are hosted on a certain server, or are aggregated by a certain custodian.
http://purl. org/NET/scovo 18 http://linkeddatacatalog. dws. informatik. taxonomic and mapping relations among both con- cepts and entities and is a well used means to describe links between concepts and entities across datasets. By providing an established vocabulary for less strict rela- tions, for instance, broader or narrower, respectively broaderMatch and narrowerMatch, it enables the rep- resentation of taxonomic relationships as well as the alignment of different schemas and knowledge bases, i. e. datasets. uni-mannheim. de/state/ 19http://www. w3. org/TR/vocab-dcat/ 20 https://www. w3. org/TR/2009/ REC-skos-reference-20090818/.
A custom-written software (SPECTY) implementing this routine was separately developed using the SCILAB open source coding tool and the batch processing options of OriginPro software (OriginLab Corp. ) yielding the same results. While both the syntax and the philosophy of the SCILAB open source coding tool and the batch processing options of Orig-inPro software are different, in both coding environments SPECTY is structured in a similar way. Figure  3     built-up time constants along with the duty ratio and the range of frequencies), the software applies Equation 1 to find the attained value of the surface photovoltage just at the end of the illumination period (called "s" in Figure  3 ), then in a similar way, the software uses Equation 2 to find the attained value of the surface photovoltage after photo-carrier recombination during the "in-dark" period (called "r" in Figure  3 ).
Conclusion In summary, we proposed and demonstrated a novel automatic numerical simulation routine that enables the simulation of spectroscopy curves of the average surface photovoltage during the frequency-modulated excitation of photovoltaic materials, provided that the values of the time constants of the SPV dynamics are specified as set-up parameters in the software. We implemented this routine to check calculated time constants associated to the minority-carrier lifetime obtained with singlepoint FMI-KPFM on a silicon nanocrystal solar cell. The obtained results were not only confirmed by the numerical analysis, but additional information about the photo-carrier dynamics was found, which otherwise would not be accessible solely from the mathematical fit of the measured data. We also implemented a numerical simulation routine to check the pertinence of the mathematical model used in intensitymodulated scanning Kelvin probe microscopy measurements of a polymer/fullerene bulk heterojunction device.
3D urban data CityGML files for several major cities like Lyon, Berlin, New York are currently available. CityGML is an evolving standard that has been extended 2  in several ways to incorporate several information like indoor facilities  (Kim et al. , 2014) , dynamic properties  (Chaturvedi and Kolbe, 2015) , cultural heritage  (Finat et al. , 2010)  etc. One recent work proposed an extension to represent urban evolution  (Chaturvedi et al. , 2017)  by focusing on changes in features of city objects. But this work is limited in its capability to represent multiple points of views of urban evolution. Study of urban evolution requires representation and management of multiple points of view of historians and urban planners. In this article, we inspire from the work done by  (Chaturvedi et al.
The ability to see and work with multiple possible scenarios is a common problem in software development. Version control systems  (Spinellis, 2005)  are now commonly used to develop softwares, which let users independently develop programs. Developers can switch to alternate view of development of code, for example, addition of new features. They review the code, come to a consensus and merge the proposed changes on the official branch, usually referred to as the master brunch or even trunk. Distributed version control systems  (Milewski, 1997)  even let users fork entire repositories, thereby letting multiple concurrent development by various business players. These solutions on first look may seem to match the requirements for managing information related to urban evolution. However, existing solutions including the latest version control system (VCS) like GIT  (Loelinger and MacCullogh, 2012) , Pijul 3  (inspired from categorical theory of patches  (Mimram and Giusto, 2013) ) have focused on managing line based changes.
This line-based tracking approach, now almost a standard way is helpful in software development since VCS must cater to the needs of developers in different programming languages with varying syntax. Linebased differences between two codes targets human coders. This is not very useful to understand differences between city objects represented by CityGML (a structured data format using XML or JSON) that have undergone changes. Geogig 4  , an application for distributed versioning of geospatial data, tackles this problem for structured geographic data. It makes use of GIT vocabulary and shows the feature differences between two versions in a very user-friendly manner. One particular advantage of Geogig is that anybody familiar with GIT can use it. However, it does not currently support CityGML files and also it focuses on tracking user-made changes to geographical data files.