(Aside. If I just hit "reply to all" on these messages, it automatically includes <[email protected]>, even though this is not listed as a recipient. /Aside)
I think I understand what Jeremy is getting at. If I remember correctly, we had very much this discussion back when we were drafting the original "named graphs" paper. Let me have a stab at explaining it. There are (speaking intuitively) RDF graphs all over the internet, represented using RDF surface syntaxes. RDF/XML documents, Trig documents, quad stores, etc. etc.. But these things are not, strictly speaking, graphs, even if we ignore the fact that they can be modified. Lets assume that they are all cast in stone, so they are not g-boxes. Still, they aren't graphs, because two of them can be different and yet describe the very same graph. So what are they, exactly? They are things that bear the same relation to graphs that a token of the letter "A" bears to the first letter of the English alphabet. Or, they are things that bear the same relation to graphs that actual physical copies of Moby Dick bear to the novel written by Melville. Or, they are things that bear the same relation to graphs that RDF classes bear to the sets that are their extensions. To all intents and purposes, they are just like the the more abstract things, but there can be many of them corresponding to each one of those. They are exemplars, tokens, concretions, intensions, representations, ... choose your favorite analogy... of graphs. When we wote the named graph paper, we wanted the names to name these things rather than "abstract" graphs, because these are the things that one can store, transmit, copy and generally do processing on. These are the actual RDF data, and the RDF graphs are a kind of abstraction of them, something like the parse tree of a sentence as opposed to a copy of the sentence in an actual document. So we needed a way to define these things, but it wasnt easy to do that in a philosophically elegant way. So we used the quick and slightly dirty construction of pairing the graph with its name to represent the particular thing that the name names. This way, one can have two or more named graphs which are distinct, each has its own name distinct from the other names, but they are all copies of (tokens of, intensions of) the same actual graph. And this simple trick avoids the consequence that we wanted to avoid, and which your example illustrates, which is that if we really were naming the graphs, then my name for my graph would also become a name for your graph if you happened to have a copy of my graph. Which does not sit well with the idea of having deferencable names like URLs. So, to emphasize, this is not going all the way to g-boxes. The idea was not to give a name to a box which just kind of happens to have a graph in it, or something with a state which can be changed with time. It was to give a name to the actual graph-like things, but with the understanding that we are talking about something more like actual datastructures, or actual documents, than mathematical abstractions. Things that can be put on websites, stored in a file at at an address, given copy protections and pointed at using IRIs. Those are the graph-things that the names of named graphs were supposed to be naming. Given the g-box discussion, we could identify these things with 'fixed' g-boxes whose state is not allowed to change, but I am less happy with this convention, as the g-box idea introduces the whole business of temporality, state change and so on, which is a huge can of worms that really is not relevant to the "intensional" notion that Jeremy is talking about here. So to introduce all this, then to immediately cancel it by saying the box if 'fixed', is confusing, and conceptual overkill. Personally, I like the letter-A analogy, and would be very happy to have the notion of a token of a graph, being any datastructure or document which encodes or parses to the graph. But not something with a state, not labile or dynamic, just as fixed and eternal as any other RDF notion. And if we do this, then we have a three-way relationship between a name, the graph token it names, and the graph exemplified by the graph token, and we can run your account of datasets without mentioning boxes or implying anything about change and time. Just replace "g-box" with "graph token" (or whatever we decide to call it. It is, of course, a named graph using the conventions from the original paper.) And then your g1/g2 example entailment does not hold, as I think it should not. Pat On Sep 16, 2013, at 5:19 PM, Jeremy J Carroll wrote: > > > > On Sep 11, 2013, at 8:14 PM, Sandro Hawke <[email protected]> wrote: > >> On 09/11/2013 06:21 PM, Jeremy J Carroll wrote: >>> >>> This section defines a vocabulary item rdf:Graph in addition to those in >>> [RDF-SCHEMA]. >>> This is the class of resources that are RDF graphs. If a resource in this >>> class is identified by an IRI, and that IRI is used to name a graph in a >>> dataset, then within that dataset the resource SHOULD correspond to the >>> named graph. >> >> Does it not follow from this definition that: >> >> PREFIX : <http://example.org/#> >> PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> >> :g1 :p 1. >> :g1 a rdf:Graph. >> :g2 a rdf:Graph. >> GRAPH :g1 { :a :b :c } >> GRAPH :g2 { :a :b :c } >> entails: >> :g2 :p 1. >> >> (assuming the "SHOULD" is taken as something we can count on) ? > > > Hi Sandro > > this is an excellent question, and one that I takes motivates your discussion > of box-model on the WG mailing list. > > I am not very comfortable with a YES, but, given the text I suggested a YES > it would be. > > In essence I think I want an intensional semantics rather than an extensional > semantics, suggested text below; I start with philosophical discussion. > > In maths, we typically refer to Sets with intensional semantics, in RDF we > refer to classes with extensional semantics. You have this exactly backwards, which is rather confusing :-) > > So if I have a class > > jjc:Friends rdf:type rdfs:Class ; > rdfs:comment "Jeremy's friends" . > > and also a class > > jjc:SandrosFriends rdfs:type rdfs:Class ; > rdfs:comment "Sandro's friends" . > > in the unlikely event that we have exactly the same friends, RDF semantics > does not confuse the intent. Right. Classes in RDF might have the same members but still be distinct. SO RDF classes are not mathematical sets. But what is your point here? Is this a problem? (Why?) > > A view would be that RDF Semantics achieves this by moving the semantic > intent more to the property rdf:type … > > So, we could scrub the idea of having a class, and instead define a property. > > An alternative proposed modification, which clarifies my desired NO to your > entailment > > [[ > 3.7 The rdf:namesGraph property > > This section defines a vocabulary item rdf:namesGraph in addition to those in > [RDF-SCHEMA]. > > rdf:namesGraph is an instance of rdf:Property that is used to state that a > resource is a name for a graph. > > A triple of the form: > > R rdf:namesGraph G > > states that G is an RDF graph and R is a name for the graph G. > If R is an IRI, and that IRI is used to name a graph in a dataset, then > within that dataset the resource G SHOULD correspond to the named graph. > > The rdfs:domain of rdf:namesGraph is rdfs:Resource. No rdfs:range is > specified. > ]] > > > === > > With this my particular use case to add metadata about the graph as an > intensional as opposed to an extensional object would be addressed as follows. > > PREFIX : <http://example.org/ > #> > PREFIX rdf: < > http://www.w3.org/1999/02/22-rdf-syntax-ns > #> > > GRAPH :g1 { :g1 rdf:namesGraph _:g ; rdfs:comment "An example graph" } > > > > > Jeremy J Carroll > Principal Architect > Syapse, Inc. > ------------------------------------------------------------ IHMC (850)434 8903 home 40 South Alcaniz St. (850)202 4416 office Pensacola (850)202 4440 fax FL 32502 (850)291 0667 mobile (preferred) [email protected] http://www.ihmc.us/users/phayes
