Joshua Shinavier Networked Graphs

From Semantic Portal Wiki

Presentation given at CSCI 6966 Advanced Semantic Web (Fall 2008) - Lesson 6

Presentation slides: Image:ASW-Joshua_Shinavier-presentation2.ppt

• Speaker: Joshua Shinavier
• Title: Networked Graphs: A Declarative Mechanism for SPARQL Rules, SPARQL Views and RDF Data Integration on the Web
• Authors: Simon Schenk, Steffen Staab
• Conference: WWW2008
• URL: http://www2008.org/papers/pdf/p585-schenkA4.pdf
• Date of Presentation: 2008/10/02

Questions

ID	Question	Name	Answer
Joshua Shinavier Networked Graphs Gregory Todd Williams 1	The modeling of g:definedBy statements used to define RDF views seems strange and limiting given the stated goals of the paper. Is there a reason to include "FROM" and "FROM NAMED" clauses in the query string rather than as triples in attached to a view resource? By including them in the query string, reusability (a stated goal) seems to be made harder as query strings need to be edited. Also, the use of QNames and relative IRIs in the query strings yield a system that I don't believe is actually backward compatible as stated -- by the time the query string is available as the object of a g:definedBy triple, the lexically defined namespaces from the defining RDF document will be lost, and the query will be impossible to execute. Is query expansion performed and simply not discussed in the paper?	Gregory Todd Williams
Joshua Shinavier Networked Graphs Gregory Todd Williams 2	Does anything prevent a view from being defined as infinitely recursive, leading to a dataset that has no fixpoint? The paper briefly mentions in section 7 (Complexity) that they limit discussion to only construct patterns without blank nodes (required to create an infinite dataset), section 5 (Semantics) seems to imply that such models are allowed, yet the discussion seems to gloss over how the implementation deals with this (ignoring the problem by assuming a fixpoint will be reached eventually).	Gregory Todd Williams
Joshua Shinavier Networked Graphs Jesse Weaver	Maybe I'm misunderstanding something in the paper. The last paragraph of section 6 (right before section 6.1) states: "Tabling means we save intermediary results during the iterative computation, instead of recomputing them when needed." However, section 6.2 states: "After every iteration, every QueryNode updates its table of results. Only new results are returned to other nodes." This gives me the impression that, in actuality, everything is still being "recomputed," but "only new results are returned." Therefore, this tabling does not prevent redundant work as claimed. Do I understand this correctly?	Jesse Weaver
Joshua Shinavier Networked Graphs Joshua Taylor 1	In 6. IMPLEMENTATION, the authors describe their algorithm for determining the fixedpoint of a graph/view. They write, "In some more details, the procedure starts with the true statements, which are extensionally lister, or which can be derived from views, which do not use negation. //Though, I thought that views could use negation…// We call this underestimate U1. Statements in U1 are known to be true. U1 is used to compute an overestimate O1 by evaluating all views against this set of true statements. The result will be an overestimate, because U1 was still incomplete and therefore bound negation will succeed in too many cases. //So views can contain negation…//" (emphasis added) I do not see how they can guarantee that O1 will be an overestimate. It is generated based on U1 whose elements are known to be true, but which is not yet the set of all true statements. Then if O1 does not depend on views using negation, it would seem that O1 could be another underestimate. In 5.1 Requirements …, RDF Schema the authors state "that NGs are expressive enough to alternatively model the RDFS inference rules as view definitions." I imagine a a U1 containing "X rdf:type A", "A rdf:subClassOf B", and "B rdf:subClassOf C", which would lead to an O1 containing U1 as a subset, and also "X rdf:type B", and perhaps "X rdf:type C". Yet O1 is clearly not an overestimate. What am I missing here?	Joshua A. Taylor
Networked Graphs Ankesh	In example 5 in description of NG :mikesProject, graphs containing foaf description of each member are named explicitly. So when a member joins (or an existing member leaves) the NG definition for :mikesProject would have to be changed. This may not be desirable. Is there a way that we could query desired NGs from the available descriptions of every accessible NG?	Ankesh Khandelwal
Schenk2008networked question 1 by lebo	The extension of named graphs that the authors describe looks like it will be very useful in Semantic Web applications. A couple of pragmatic questions. Do the QNames in the rdf:Literal values of g:definedBy inherit the prefix bindings defined in the Networked Graph file? Tucking query expressions into literals seems to be a recurring theme (e.g., Fresnel does it for SPARQL and FSL expressions). However, my experiences with managing query expressions within literals has been clunky at best. Has anyone proposed an analogous rdf:Property that indicates a URI that should be dereferenced to obtain the query expression? If so, where. If not, is it needed? It seems that this would fit well within a development environment.	Tim Lebo
Schenk2008networked question 2 by lebo	In the Related Work section, the authors compare Networked Graphs to ActiveXML: "The semantics of ActiveXML documents is also defined using a fixpoint, but unlike NGs, ActiveXML documents are infinite in general." What does "infinite in general" mean and why is it not desirable?	Tim Lebo
Schenk2008networked question 3 by lebo	In the Related Work section, the authors compare Networked Graphs to NRL: "NEPOMUK Representation Language NRL ... allows for various ways to specify 'views', which are defined with a procedural semantics in contrast to the declarative semantics of NGs." What is the distinction between procedural semantics and declarative semantics?	Tim Lebo

Attendees

Tim Lebo