Showing 22 pages using this property.
A | |
|---|
| Ankesh Summary Abox Gregory Shangguan 1 + | You are right. The authors are suggesting … You are right. The authors are suggesting a method for speedy reasoning (consistency checking in the paper) over large Aboxes stored in RDB. At the same time I would agree with you that the title of the paper doesn't say anything about the work being specific to RDB. hing about the work being specific to RDB. |
| Ankesh Summary Abox Gregory Shangguan 3 + | It would have to be done exhaustively, i.e … It would have to be done exhaustively, i.e. all individuals would have to be considered one by one. Check the table that contains images (f-values) of individuals and roles. Now if these images are part of the partition keep the individuals in original Abox. All these operations can be carried out using join and selection. n be carried out using join and selection. |
| Ankesh Summary Abox Gregory Todd Williams 1 + | LUBM is synthetically generated, and as la … LUBM is synthetically generated, and as larger data-sets increase the number of individuals increase, but their relationship remains similar. Therefore all LUBM data-sets share a common behavior.
:* I have no idea how inconsistency is reached in summary Abox. I looked at LUBM ontology, and there appears to be no axioms for deducing inconsistencies. No two classes are described as disjoint, there is no all-values restriction, (no inverse-functional or functional props), no cardinality restrictions, no two individuals are explicitly stated as being different. So I think we can deduce a graduatestudent1 to be Professor or Publication as-well, without getting a clash. So it is very surprising that there is even a clash.
:* improving summarization/ filtering- no idea as of now. Filtering transitive role assertions would be worth investigating. But bottom-line to all improvements would be that they should be easily implementable using standard SQL queries. implementable using standard SQL queries. |
| Ankesh Summary Abox Gregory Todd Williams 2 + | I think this computation is done prior to … I think this computation is done prior to application of tableaux algorithm. It simply refers to cardinality of R-successors initially in the Abox. This value would be used to calculate upper bound using the formula in section 3.2. Precisely it would give the cardinality of P(a). Filtering is done before application of tableaux algorithm. However, I'm not sure if taking the maximum works even when R is transitive. e maximum works even when R is transitive. |
| Ankesh Summary Abox Shangguan 2 + | I would think so. But how are you going to … I would think so. But how are you going to keep track whether an inconsistency was artificially created? One way, that paper has discussed, is to verify its image in A. Is there other way? I don't think I have understood your question. Please ask again after the presentation. . Please ask again after the presentation. |
C | |
|---|
| Carroll2005named question 1 by lebo + | Good questions. ONE: I believe the answer … Good questions. ONE: I believe the answer is not explicit in the article, but it seems to be implied. Consider the quote from section 8.1: "We will consider two such intentions expressed by the properties swp:assertedBy and swp:quotedBy. These take a '''named graph''' as a subject ...." Then, note in Fig. 1 that the subject of swp:assertedBy is labeled as an rdfg:Graph. From these two pieces of information, it seems that a named graph can be identified as being rdf:type rdfg:Graph. More formally, for a named graph ng, ng is in the class extension of rdfg:Graph (ICEXT(I(rdfg:Graph))). Thus, if a URIref u is countered, and it is the subject of a triple ''u rdf:type rdfg:Graph'', then the crawler knows it's a named graph. TWO: I believe the assumption is that the crawling will occur over a set of named graphs and that the crawler will somehow have knowledge of how to obtain rdfgraph(ng) from name(ng). Consider first that in named graphs, all graphs have a name (i.e., there is no "default graph" like in SPARQL). Therefore, if a crawler is already crawling a graph, that means it already had some way of obtaining it. In whatever way the crawler obtained that graph, it would obtain other graphs. The last paragraph of section 3.5 seems to indicate that method of retrieval is independent of the named graphs approach. What is important is that a name is associated with each graph and that there exists a way to obtain the graph (and such a way is not specified in the article). ch a way is not specified in the article). |
F | |
|---|
| Fokoue2006summary question 1 by lebo + | You are right. We would not be able to summarize in that case. In-fact I would bring this up for discussion during my presentation, more so from the point of view of non-existence of unique name assumption. |
G | |
|---|
| GRIN Ankesh + | Will be explained in the talk |
| Graph Features SWS + |
# You make a very valid point that just b …
# You make a very valid point that just being an "OWL" ontology does not mean that you actually use all of the constructs (is typing classes to owl:Class sufficient for being "OWL"?). I would like to find out the answer to your bet, but I wouldn't place any myself. Why do you think that cardinality restrictions are not used? (TBD...)
#two
#three
#four s are not used? (TBD...)
#two
#three
#four |
| Gregory Todd Williams Graph Summaries Jesse Weaver + | The evaluation section is a mess. The axis … The evaluation section is a mess. The axis labeling in figure 8 is unintelligible if, as you mention, the values are to be understood as lg(error) = ~25. Another issue in the evaluation is the (somewhat suspicious) use of a subset of SwetoDBLP that has only ~0.8 edges for every node (which seems like it might lead to a somewhat uninteresting graph). t lead to a somewhat uninteresting graph). |
H | |
|---|
| Hu2007discovering question 1 by lebo + |
# The authors specify that a mapping ''m' …
# The authors specify that a mapping ''m'' contains a relationship ''t'' that holds between the ''u'' and ''v''. I think this definition is confusing as the authors never make use of this ''t''. Simple mappings seem to find equivalence relationships, and contextual mappings seem to find subsumption relationships. Personally, I think that it would be useful if the system allowed human users re-run certain phases, and to make adjustments between runs. '''Phase 3''' checks the consistency of attribute/property mappings, and this could be facilitated if users could step in and clarify the relation/class mappings (to specify equivalence, subsumption, &c.).
# As I mentioned in the preceding item, the consistency checking phase checks the consistency of mappings between, ''assuming'' (or provided) that the relation/class mappings have been computed correctly. I think the unspoken assumption is that relation/class mappings are more likely to be correct (and this is probably reasonable, particularly if the ''Des'' function has access to good descriptions, and if the number of entity relations in the database and classes in the ontology is small). So, I don't think that the presence of '''Phase 3''' indicates a ''lack of confidence'' so much as a recognition that attribute/property matching is more difficult than relation/class matching, but is easier in the presence of the latter. t is easier in the presence of the latter. |
J | |
|---|
| Jesse Weaver Presents Named Graphs GTW 1 + | My best guess is that they allow an unname … My best guess is that they allow an unnamed graph in TriX in order to be compatible with the existing RDF standard. If one wanted to convert a graph from RDF/XML representation to TriX, what would one put as the name of the graph (since there is no equivalent in RDF/XML)? I believe the statement "each graph should be named with a URIref" is just a recommendation in order to comply with the named graphs approach presented in the paper (which does not include an unnamed graph). So, in short, unnamed graphs are probably allowed for compatibility with RDF, but they are not recommended so that such a TriX/TriG representation will comply with the named graphs approach. ill comply with the named graphs approach. |
| Joshua Taylor presents Discovering Simple Mappings Between Relational Database Schemas and Ontologies Joshua Taylor 1 + | The ''Marson'' system is compared against … The ''Marson'' system is compared against the 2006 ''Ronto'' system which was developed by a team disjoint with the authors. The comparison with the ''Simple'', ''VDoc'', ''Valid'' systems seems a bit odd. The authors have developed a four-phase process for generating mappings, and have a reason for designing each phase. They then compared their system against crippled versions of itself. It is not particularly surprising, in my opinion, that it tends to come out on top (although, in the case of OBSERVER/Bibiography, the ''Valid'' system even does a little better). Rather than having shown that ''Marson'' is a good system (compared to other systems in the world), it seems that the combination of techniques present in ''Marson'' is better (usually) than a subset of those techniques. sually) than a subset of those techniques. |
M | |
|---|
| Mappings RDB Ontology Ankesh + |
# An example from Wikipedia, particularly …
# An example from Wikipedia, particularly http://en.wikipedia.org/wiki/Relation_(mathematics) : <blockquote>An example of a ternary or triadic relation (i.e., between three individuals) is: "X was-introduced-to Y by Z", where (X,Y,Z) is a 3-tuple of persons; for example, "Beatrice Wood was-introduced-to Henri-Pierre Roché by Marcel Duchamp" is true, while "Karl Marx was-introduced-to Friedrich Engels by Queen Victoria" is false.</blockquote> This (somewhat contrived) relation could be represented using a relational database. It would be a "relationship relation", and each row would store an X, a Y, and a Z. In order to represent this relationship using a triple based model, it is necessary to introduce some sort of "introducing event" objects which correspond to the rows of the table, and which would be the domain of three properties, say, introduction_event:person1, introduction_event:person2, and introduction_event:introducer. A similar thing has to happen if the database contains a '''Person''' table with three attributes, ''name'', ''birthdate'', and ''gender''; the difference is that it does not seem strange to us to introduce '''Person''' objects—they're just people.
# The authors are using this example to show how the ''validation process'' would eliminate an inconsistent mapping. (Their language is a bit unclear, though.) Presumably the mapping between ''hasID'' and ''id'' would be discovered based on the results of ''Des(hasID)'' and ''Des(id)''. Though in this example "hasID" and "id" are distinct tokens, they might, in reality, have some more complex descriptions which have some similarity. If this ''isn't'' the case, it is hard to imagine the authors' system overcoming ''any'' lexical differences in terminologies that arise between databases and ontologies.
# Immediately below '''ContextMatch'', the authors write "In lines 6–8, the algorithm repeatedly examines each attribute in the relation ((to determine)) whether it is a categorical attribute or not." Based on the way that they ''use'' the categorical attributes, a categorical attribute is one in which a partitioning of instances based on their attribute values corresponds to some partitioning of the disjoint subclasses of the class at hand. disjoint subclasses of the class at hand. |
| Medha GRIN Presentation Gregory Todd Williams 1 + | Yes you are right. The constraints are ext … Yes you are right. The constraints are extracted from graph and seem to rely on at least some bound nodes in the query graph.
Your doubt about details of the queries used for evaluation is correct. There are no details given w.r.t. the standard size of query graph used in the evaluation and effectiveness of GRIN index on different queries and query graph sizes.
I believe it is fair to assume by a given query graph will have ''some'' bound nodes, as most realistic queries do have some bound nodes.
alistic queries do have some bound nodes.
|
| Medha GRIN Presentation Jesse Weaver + |
Yes, I guess predicate can be unbound, b …
Yes, I guess predicate can be unbound, because an unbound predicate an be simply represented as a wildcard, but you have specify the path length.
While this is my understanding, it depends on the subgraph matching algorithm that they use after identifying portions of the original RDF graph to be searched for finding variable bindings. I have not looked at the subgraph matching algorithm and hence cannot authoritatively say whether queries without bound predicates will work or not. without bound predicates will work or not. |
| Medha GRIN Presentation Joshua Shinavier 1 + | You question is more or less is same as the doubts raised by other people on this forum. Please refer to my answers there. |
Q | |
|---|
| Questions for Distributed Reasoning Ankesh + |
#('''Jesse Weaver''') In section one, the …
#('''Jesse Weaver''') In section one, the authors state: 'In rule based reasoners, the OWL ontology definitions are first compiled into a set of rules.' I believe this is what you described as the 'latter approach' in your question. While the paper does not explicitly and unambiguously state how they are handling the rules, it is my assumption that they are doing exactly as you described. This does matter because their system only handles 'single-join rules' (rules having two subgoals that join on one variable), and it is assumed that such a compilation of the OWL ontology under OWL Horst semantics will result in only single-join rules. (I believe this is shown in a previous paper of theirs, cited as (8) in this paper.) Yes, this would possibly result in a large number of rules. However, that may actually be advantageous for the rule-partitioning approach, since they cite as a weakness of rule-partitioning the lack of number of rules to distribute among computational nodes.
#('''Jesse Weaver''') I, too, am concerned with their choice of data sets. You are correct in that they do not discuss the OWL expressivity of the datasets; it would be nice to know what kinds of rules were compiled from the respective ontologies. LUBM and UOBM are both synthetic datasets, and MDC is unknown to me. (The authors refer to MDC as their 'own data-set' in section six.) This is especially a concern when comparing domain-specific data partitioning with graph data partitioning. In figure five, the authors show that domain-specific data partitioning speeds up nearly as well as graph data partitioning, but this seems like it benefits from the lack of interrelations in LUBM data. If it were more interrelated/interconnected, then it seems like it would be more difficult to come up with a good domain-specific data partitioning. a good domain-specific data partitioning. |
| Questions for Distributed Reasoning GTW + | ('''Jesse Weaver''') You make a good point … ('''Jesse Weaver''') You make a good point. While they provide a parallel algorithm for reasoning ''after'' partitioning, they do not propose a parallel algorithm for data partitioning itself. Algorithm one seems to indicate that a single computational node does the partitioning and then sends the tuples to their assigned owners. Such a paradigm is actually well known to significantly affect performance due to the lack of parallelization in the partitioning part of the computation and the amount of overhead spent sending tuples to each computational node. This is particularly expensive on large data sets distributed across a large number of computational nodes. (I don't believe this problem is clearly reflected in the evaluation because they only try scaling to 16 nodes. Such an approach is unlikely to scale well to tens of thousands of computational nodes like on a Blue Gene/L.) My intuition is that, unless there is a parallel algorithm for efficiently and sufficiently partitioning a graph, then it is unlikely that this approach will scale well to very large data sets and/or very large numbers of computational nodes. very large numbers of computational nodes. |
S | |
|---|
| Summary Abox Ankesh Joshua Taylor 1 + | Given that authors intend to keep it simpl … Given that authors intend to keep it simple, tractable while using RDB, complexity of computing the mapping may not be too high. I wouldn't be able to clearly define an f, but I can try describe the algorithm that can produce the mapping (using simple SQL queries).
* If in the second last step of the algorithm described below we do not care if concept sets are subset (i.e. only same concept set matters), then we can estimate complexity based on above algorithm. It is surely polynomial, and something like n*n, excluding the time for concept set comparison- depends on RDB. or concept set comparison- depends on RDB. |
| Summary Abox Ankesh Joshua Taylor 2 + | I would request you to repeat the first po … I would request you to repeat the first portion of your questions. I'm afraid I couldn't follow your description completely. w.r.t your question, I think, summary technique and filtering are independent in every sense. They explicitly describe how the filtering techniques (or tableaux algorithm) can be applied to summary Aboxes as well. can be applied to summary Aboxes as well. |
U | |
|---|
| Udrea2007grin question 1 by lebo + | This is a good question. The answer is two … This is a good question. The answer is two fold. In GRIN index building and query execution, authors have made use of some graph mining, clustering algorithms, which I am not very familiar with. Since the features and performance characteristics of these two algorithms are not know and also there isn't a lot of literature present on usage of these algorithms for RDF graphs, it's difficult to comment on whether or not performance characteristics of these algorithms affect efficiency of GRIN index. lgorithms affect efficiency of GRIN index. |
