Matches in ESWC 2020 for { <https://metadata.2020.eswc-conferences.org/rdf/submissions/Paper.110_Review.2> ?p ?o. }
Showing items 1 to 10 of
10
with 100 items per page.
- Paper.110_Review.2 type ReviewVersion.
- Paper.110_Review.2 issued "2001-01-29T13:43:00.000Z".
- Paper.110_Review.2 creator Paper.110_Review.2_Reviewer.
- Paper.110_Review.2 hasRating ReviewRating.1.
- Paper.110_Review.2 hasReviewerConfidence ReviewerConfidence.4.
- Paper.110_Review.2 reviews Paper.110.
- Paper.110_Review.2 issuedAt easychair.org.
- Paper.110_Review.2 issuedFor Conference.
- Paper.110_Review.2 releasedBy Conference.
- Paper.110_Review.2 hasContent "Comment after Rebuttal: Thank you for the clarifying comments which resolved many of my initial doubts. However, I am still having an unsure feeling about the mappings that are used for the extraction of YAGO4. The authors did not clarify the workflow of creating the mappings in their rebuttal (e.g., did only one person create those mappings; has there been peer-reviewing / crowd-sourcing / data-driven checks; ..). As the mappings are the central part of the new knowledge graph and are responsible for its correctness, this should be made very clear. As most of my doubts have still been resolved by the rebuttal of the authors, I am raising my final evaluation to "weak accept". --------------------------------------- The authors present the YAGO4 knowledge graph which combines Wikidata instances and parts of its type system with the very constrained ontology of schema.org. The YAGO4 knowledge graph is considerably large in size with almost 10K classes and up to 57M individuals as well as 326M facts. Despite its size, the main benefit of the resource is the very restrictive ontology which uses SHAQL constraints to ensure that the knowledge graph is in a consistent state. In general, I very much like the idea of the paper as Wikidata is in fact not properly accessible by a reasoner. Consequently, a logically consistent version of the knowledge graph has much potential for further use. The SHAQL constraints provide a nice foundation for a consistent and extensible graph. However, these constraints may also make it difficult to extend the knowledge graph further as new entities or facts have to comply to every constraint (and if the constraints are too restrictive, then a part of valid information might be excluded from the graph). But this is not a problem as it is intended that way. Although the research idea is very interesting, I think the paper/resource in its current state has still room for improvement. Among other things, it lacks a lot of detail in several places and contains some inconsistencies. Consequently, I evaluate the submission as "borderline paper". These are the problems that I see in particular: MISSING DETAILS ------------------ 1) I am missing a more detailed description of underlying resources (schema.org, Wikidata), so that the reader can better understand how you create the new knowledge graph out of them. For me, this is more relevant than, e.g., the description of previous YAGO versions (page 1) as they don't have an immediate impact on the current version. 2) The paper has only a rather superficial comparison of YAGO4 with related knowledge graphs. It should be more apparent how YAGO4 is different from other graphs (e.g. DBpedia), especially in terms of reasoning capabilities. 3) How were the mappings in sections 2.2 and 2.3 established? And in particular, how has it been made sure that the mappings are correct? As these are a central part of your knowledge graph, this should be made clear. 4) Page 3, "Disjointnesses": How do you resolve inconsistencies that come up due to the disjointnesses during the creation of YAGO4? For example: The class "Person" is disjoint with "CreativeWork", but the resource "Peter Pan" [1] in Wikidata is an instance of both. Which one do you keep (if any)? 5) Page 4, "Functional Constraints": How do you decide which of the properties are functional? And how do you resolve inconsistencies that may come up? For the property "birthPlace", for example, Wikidata lists only the most specific place of birth, but other knowledge bases like DBpedia assign multiple places of birth of varying granularity to a person. 6) Page 4, last paragraph: Has a portion of the removed facts been inspected and were the facts all actually "wrong"? What kinds of errors are fixed by removing them? 7) Page 10, "Applications": The fact itself that previous versions of YAGO have been used in several projects doesn't say much about the current version as it is - at least to my understanding - rather different from all its previous versions. Seeing some kind of application (e.g. reapplying the new version of YAGO to some old project, or at least showing what it can do better than Wikidata with the improved reasoning capabilities) would be really great here. INCONSISTENCIES ------------------- 8) Page 5, Section 2.2: You state that only "leaf-level classes are taken from Wikidata", but in section 3 (page 8) you say that you include all classes into YAGO4 that are sub-classes of a class that has been mapped to schema.org. How is that possible if you only take the leaf-level classes from Wikidata? Or do you mean in section 2.2 that you map the leaf-level classes of schema.org to Wikidata? 9) Page 9, Table 1: What kind of sameAs links to Wikipedia do you extract? The numbers for the "W" and "E" flavours (42M and 25M) seem a little high to me given that these flavours have only 15M and 5M instances. READABILITY -------------- 10) Section 3 is, in my opinion, really hard to digest. At the start of the section some high-level information about the complete extraction procedure (maybe with an overview figure and a couple of examples) would aid my understanding more than a low-level description of the implemented algebraic operators. This might also help understanding the description of the extraction workflow on page 8. NITPICKS (FORMATTING, TYPOS, ..) ------------------------------------- 11) lowercase (Section 2: "person" and "thing") vs. CamelCase (Section 2.1: "BioChemicalEntity", "Event",..) classes 12) The same for properties (e.g. Section 2, first paragraph: "birthDate" vs. "capitalof") 13) Different formatting of facts (Section 2.3: "wd:Q42 wdt:P31 wd:Q5" vs. "yago:Douglas_Adams rdf:type schema:Person") 14) Page 8, second bullet point: "sub-classes" vs. "subclasses" 15) Page 8, fourth bullet point: "subclass of" in italics but "instance of" in quotes 16) Page 4, middle: "the range of the birthPlace property" should be "the range of the birthDate property" 17) Page 1: You give four sources for YAGO but do not cite the other mentioned knowledge graphs (e.g. DBpedia, BabelNet, NELL, KnowItAll) at all [1] https://www.wikidata.org/wiki/Q107190"".