- From: Pat Hayes <phayes@ihmc.us>
- Date: Thu, 14 Mar 2013 22:31:19 -0500
- To: Antoine Zimmermann <antoine.zimmermann@emse.fr>
- Cc: public-rdf-wg@w3.org
On Mar 14, 2013, at 12:45 PM, Antoine Zimmermann wrote: > To paraphrase Pat Hayes's "In defence of logic" (IJCAI 1977), I'd say that modern mathematical notation is the most successful language ever developed to express formal concepts. > > I have asked for a precise, mathematical account of what is being defined in the "scope" section of RDF Semantics, and what I get is the long English prose below. I hope you read it all :-) > Let me examine the formalisation given in the middle of the text. > > > So, we have a set SCOPE of scopes and the infinite set B of bnodes. There is a mapping sc from bnodes to SCOPE. > > Let us write bn(G) the set of bnodes in a graph G. > > An RDF graph G is a set of RDF triples such that there exists a scope s such that for all bnode b in bn(G), sc(b) = s. This scope is necessarily unique (from your axiom 1), so we can call it the scope of the graph, and note it sc(G). Yes, if you prefer that way of describing it. I myself think that the syntactic scope for bnodeIDs is the best way to describe it, since more readers will be familiar with the idea of a syntactic scope for local identifiers, and also it is closer to the practical implementation issues (which never deal with actual bnodes, only with texts containing bnodeIDs.) > Then there is this new concept "copy", that is neither in Concepts nor in Semantics. I was not proposing to put this into the specification. I put it in the email to you because you wanted a mathematical account, and apparently had not read the one I published in the ISWC slides. (And I confess, because I thought you might appreciate the elegant simplicity of that way of phrasing it.) > How are the readers supposed to understand anything if Concepts says one thing, Semantics says another thing, and the emails exchanged by the WG say yet another thing? Anyone who actually reads through the email archives of any WG will find a plethora of ideas that did not make it into the final specification. The 2004 datatyping design went through, if I recall correctly, 17 versions before we chose the one in the final spec. > In any case, this notion of copying then taking the union is exactly what is defined in RDF Semantics 2004, simply formulated with other words. It is the operational translation of "standardising apart". No, it is not exactly that, because if the graphs in the set being merged share bnodes, then these are not standardized apart. In your two-triple example with the common bnode, this copying version of merge will produce a union rather than a 2004 merge. The total number of bnodes in the copy-merge graph equals the total number of bnodes in the graphs being merged, and this works if they share bnodes or not. But this whole account of bscopes and copying is only one way to describe the idea, and its not the one I am suggesting we use in the specification. > But this is not the union of RDF graphs, so either you should provide a different formalisation or you should revise the definition of merge. > > In the end, I still do not understand what the proposal is. Peter has proposed that the current text in Semantics is the proposal that we should accept next week. I second that proposal. > If you yourself cannot formalise it correctly, how will the WG ne able to assess it? > > > Still, could you say what problem this proposal is addressing? I believe I have described this in a previous email. See below for a summary. > What should be the impact on conformant implementation? Are there any concrete consequences on how implementation deal with semantics? No, because implementations do not in fact conform to the 2004 account of bnodes. This change brings the abstract syntax into line with what implementations actually do. It is a correction to the abstract model, not an improvement to the practice of RDF. > What I think scope is supposed to address is giving guidelines for applications to decide what to do with a bunch of triples they are confronted to: should they deal with the bunch as a single set, or should they separate the triples in several sets (for instance, the triples come from different sources)? When the triples are partitioned, there is no problem with the treatment of bnodes as in RDF 2004. I think there is. To repeat the essential issue: given the 2004 account of bnodes and graphs, how can any implementation tell, given two RDF documents which describe graphs containing bnodes, whether one bnode in one graph is or is not the same bnode as one in the other graph? Pat > > > > AZ. > > > > Le 14/03/2013 04:29, Pat Hayes a écrit : >> >> On Mar 13, 2013, at 11:32 AM, Antoine Zimmermann wrote: >> >>> Please, could you show the mathematical definitions of all this. I >>> do not understand what is a scope with the text of Semantics. >> >> Make sure you have the latest version, as the text was tweaked last >> night to improve the clarity. In the form given there, it uses the >> idea of a syntactic scope for bnodeIDs. The notion of syntactic scope >> (the scope of a local variable or a local identifier, or a bound >> variable, in logic) is surely a common idea for any logician or >> computer scientist. (Which is why I thought it might be easier for >> most readers to define it this way.) >> >> I will try to review the current proposal as succinctly as I can, but >> it does require some care to say it correctly, keeping the two levels >> distinct. >> >> 1. An RDF graph is a set of triples. (2004) >> >> Implicit in this is that *any* set of triples can be viewed as being >> a graph. This includes 'silly' sets, such as a set of triples >> containing just one triple chosen at random from every RDF/XML >> document ever published, or the set of triples containing a URI which >> rhymes with "bong" when spoken in Icelandic. As this illustrates, not >> all *sets* of triples are RDF graphs that correspond to any actual >> RDF source or RDF document. >> >> 2. RDF graphs can be expressed using an RDF surface syntax. (2004) >> >> 3. In such a surface syntax, blank nodes may be represented by blank >> node identifiers (bnodeIDs) (2004) >> >> 4. Any RDF surface syntax MUST define the scope of bnodeIDs in that >> syntax. (New, but in fact almost universally assumed in practice >> since 2004.) >> >> 5. We require that (all the bnodeIDs used in defining the triples in) >> any graph described by such a surface syntax MUST be contained within >> a single scope. (New, but in fact capturing how RDF graphs are >> treated since 2004.) (But scopes may extend beyond a single graph, as >> they do in datasets.) >> >> 6. Two graphs described by documents with different scopes, or from >> sources defining different scopes, CANNOT share a blank node. (New, >> but often assumed since 2004, even if using a different >> terminology.) >> >> 7. The set of all triples in a given scope is called a scoped graph. >> (New definition) >> >> 8. Observation. In actual usage, what people mean when they say "RDF >> graph" is almost always a scoped graph, that is, a graph whose >> triples are described fully in a document or datastructure or source >> which defines its own bnodeID scope, so that bnodeIDs are local names >> in that document or datastructure or source. Any graph described by >> an RDF/XML or NTriples document, for example, is a scoped graph. In >> some cases, people refer to graphs which are subgraphs of a scoped >> graph. I do not know of any examples of anyone needing to consider a >> graph that is not a subset of a scoped graph. >> >> Now, you asked for a "mathematical" account of bnode scoping, and >> what I have given you above is an account which refers to syntactic >> matters in a surface syntax. Perhaps you don't feel this is >> sufficiently mathematical. OK, I can do it purely mathematically, >> entirely at the abstract level, if you prefer. (This is taken from >> http://www.slideshare.net/PatHayes/blogic-iswc-2009-invited-talk, >> starting around slide 16.) >> >> We introduce a set of things called bscopes, and a relation called >> "in" between bnodes and bscopes. (This is a different notion of scope >> than the one I have been using until now, though they are very >> closely related. In the ISWC talk, I called them 'surfaces'.) Every >> bnode is in exactly one bscope (this is the first axiom). An RDF >> graph is a set of triples **such that every bnode in the set is in a >> single bscope** (that is the second axiom), and we can then say that >> the graph is in the bscope. (This sounds like it is an extra >> condition on the 2004 graph model, but its not, since the 2004 >> version simply does not mention bscopes.) We allow more than one >> graph to be in a bscope, but not for one graph to be split across >> bscopes. Two graphs in the same bscope might share a bnode, of >> course. The truth conditions refer to mappings on the bnodes in a >> bscope, as you would expect. >> >> The definition of merge in this model is, we make copies. A *copy* of >> a graph G is an equivalent graph G' in a different bscope. The merge >> of a set S of graphs is a graph comprising copies of all the graphs >> in S, all in a single bscope, with a 1:1 mapping between bnodes in S >> and bnodes in the merge. That's it. We can define scoped graph and >> complete graphs just as before, in the obvious ways. >> >> The connection between syntactic scopes and bscopes is that every >> syntactic scope for bnodeIDs is required to define a single bscope >> for the blank nodes identified by the bnodeIDs in the scope. In fact, >> you could (Richard's idea) *define* bnodes to be pairs of a bnodeID >> and a bscope, and then show that this satisfies the axioms; but >> that's not actually necessary, and it might be confusing. (Though it >> does show that the axioms can be satisfied, if that needs showing.) >> >> (I actually like the bscope idea better, but it would require us to >> slightly tweak the definition of RDF graph, which I suspect will be >> too large a pill for the WG to swallow, which is why I havn't tried >> to get them to swallow it.) >> >> Detailed responses to your email below, in-line. >> >> >>> I can see several intepretations: >>> >>> >>> 1) there is a mapping s from the set of all blank nodes to the set >>> of scopes (and what's a scope is not specified beyond that there is >>> a set of them). So, given a bnode b, I can say what's its scope by >>> s(b). >> >> Yes. That is another way to express the bscope idea, above. (b in c) >> iff s(b)=c >> >>> I am very much against this design >> >> Can you say why? As it (1) requires no changes to the 2004 semantics >> (extensions, but no changes) (2) completely solves the issue we have >> with merging vs. unioning (3) does not change any entailments or >> truth-conditions (4) is very easy to describe and (5) apparently >> conforms better to the way RDF is actually used in practice, I would >> not be willing to give it up without seeing a very convincing >> argument against it. Your being against it does not, in itself, >> comprise such an argument. >> >>> , but it's not clear that the ED of RDF 1.1 Semantics is rejecting >>> this one (especially given the remarks that Pat made during >>> previous discussions on the topic). I would object formally to such >>> a design. >> >> Do you have any technical objections? Can you say why you would >> object formally to this design? >> >>> 2) scopes form a partition of the RDF triples, so a triple belong >>> to a single scope. A set in the partition is a complete graph. The >>> problem is that the union of two different complete graphs is not a >>> complete graph. >> >>> I don't like this design at all, although it is already much better >>> than the first one. >> >> Again, can you say why? >> >>> 3) a scope corresponds to an RDF graph, and scopes can overlap >> >> No, that completely throws away the entire point of having a scope. >> In any case, scopes *don't* overlap. If they did, there would be no >> way to know how to interpret a local variable. >> >>> (mathematically, there is a mapping M from the set of scopes to the >>> set of graphs). A graph in a scope is a scoped graph (or >>> mathematically, there exists a scope s such that M(s) contains the >>> graph). The set of triples in the graph of a scope form a complete >>> graph (M(s) is a complete graph). Possibly, the set of complete >>> graphs is closed under set union (so that the union of two complete >>> graphs is still a complete graph). This would be much better, yet >>> not completely up to my expectation >> >> Can you say what it is that you expect here? >> >>> , but there are indications that the chosen design in the current >>> ED is not this one. >> >> Indeed not. >> >>> There are probably other ways to interpret the current text. >> >> Have you got the newest version? I find it hard to see how this text >> can be understood in any other than the intended way. >> >>> I would be curious to know what would be your respective >>> formalisation, Peter and Pat, if you had to write it independently >>> of one another. I had the impression, reading some of your emails, >>> that your understanding of scope was different. >>> >>> >>> In any case, I fail to understand why scope should have any >>> consequences on the truth of a set of triples. >> >> It doesn't. But it does provide a natural extent to define the >> existential bnode mapping on. A bnodeID is now exactly like an >> existential variable bound by a quantifier which extends over the >> scope (or, if you prefer, the bnode is the quantified variable, >> extending over the bscope; although this is a bit problematic,. and >> bnodes don't have any lexical form to bind. The best way to map >> abstract bnode syntax to logic is by using Piercian graphical >> syntax.) Which is exactly the intent of the original RDF design, in >> fact, but we couldn't state it with this degree of precision at the >> time. >> >>> Thus my plea to revert to the semantics of bnodes as in Semantics >>> 2004. >> >> There is no change to the truth-conditions of a set of triples. But >> we do require that the set is (described by a document all of whose >> bnodeIDs are inside a single scope) (In a single bscope), in order to >> apply the bnode semantic rules. >> >> Pat >> >> >>> >>> If scope impacts the semantics at all, then there should be a >>> separate definition of the truth of a scoped graphs, as opposed to >>> the truth of a set of triples. Something like: >>> >>> "A scoped graph G in scope s is true in interpretation I iff there >>> exists a mapping A from the bnodes in s to resources of I such that >>> [I+A](M(s)) is true, otherwise it's false." >>> >>> Note that A is independent of the graph G, it only depends on the >>> complete graph M(s). >>> >>> >>> >>> AZ >>> >>> >>> PS: this is a bit redundent with my complete review that will >>> follow (tomorrow I hope). >>> >>> >>> >>> Le 13/03/2013 16:57, Peter Patel-Schneider a écrit : >>>> ISSUE-107 concerns what to do with blank nodes. This includes >>>> cross-graph blank node scopes. >>>> >>>> The current draft of Semantics >>>> https://dvcs.w3.org/hg/rdf/raw-file/default/rdf-mt/index.html >>>> includes a solution to blank node scoping. I propose that this >>>> solution be adopted by the WG as the result of the issue. >>>> >>>> The basic idea is to introduce the notion of a blank node scope. >>>> RDF graphs within a single scope can share blank nodes, graphs >>>> not in the same scope cannot! This makes blank-node-renaming >>>> unnecessary during graph merging. (Of course, in a surface >>>> syntax, different blank nodes may have the same b-node name, so >>>> these names may have to be changed when merging in a particular >>>> syntax.) >>>> >>>> For graphs not in the same scope, nothing changes. For graphs >>>> in the same scope not sharing blank nodes, nothing changes. For >>>> graphs in the same scope sharing blank nodes, these blank nodes >>>> are interpreted uniformly. >>>> >>>> This last breaks a feature of RDF, that a set of graphs entails >>>> their merge. There is a new definition in Semantics (complete >>>> graphs) that shows when this feature is retained. >>>> >>>> >>>> >>>> This solution needs changes in Concepts, minimally introducing >>>> the notion of a blank node scope, but maybe also talking about >>>> how blank node scope can be determined by different surface >>>> syntaxes. >>>> >>>> I suppose that there is also the issue of whether all the RDF >>>> graphs in a dataset are always in the same blank node scope. It >>>> may be that it is not reasonable to say that this is the case, >>>> because datasets are already sometimes used as if they do not >>>> share blank nodes. >>>> >>>> >>>> >>>> peter >>>> >>> >>> -- Antoine Zimmermann ISCOD / LSTI - Institut Henri Fayol École >>> Nationale Supérieure des Mines de Saint-Étienne 158 cours Fauriel >>> 42023 Saint-Étienne Cedex 2 France Tél:+33(0)4 77 42 66 03 >>> Fax:+33(0)4 77 42 66 66 http://zimmer.aprilfoolsreview.com/ >>> >>> >> >> ------------------------------------------------------------ IHMC >> (850)434 8903 or (650)494 3973 40 South Alcaniz St. >> (850)202 4416 office Pensacola (850)202 >> 4440 fax FL 32502 (850)291 0667 >> mobile phayesAT-SIGNihmc.us http://www.ihmc.us/users/phayes >> >> >> >> >> >> >> > > -- > Antoine Zimmermann > ISCOD / LSTI - Institut Henri Fayol > École Nationale Supérieure des Mines de Saint-Étienne > 158 cours Fauriel > 42023 Saint-Étienne Cedex 2 > France > Tél:+33(0)4 77 42 66 03 > Fax:+33(0)4 77 42 66 66 > http://zimmer.aprilfoolsreview.com/ > > ------------------------------------------------------------ IHMC (850)434 8903 or (650)494 3973 40 South Alcaniz St. (850)202 4416 office Pensacola (850)202 4440 fax FL 32502 (850)291 0667 mobile phayesAT-SIGNihmc.us http://www.ihmc.us/users/phayes
Received on Friday, 15 March 2013 03:31:59 UTC