Re: defn of Named Graph

On Sep 19, 2013, at 9:52 AM, Sandro Hawke wrote:

> ....
> So, I hereby propose we give up on all this until after we solve the change-over-time problem for RDF.  
....

Well, I do have other things to do in my life, but I think this is a very bad stance to take. The change-over-time-problem is not ever going to be "solved". it is not a problem with a solution. If it were, there would be one accepted tense logic and one accepted semantic theory for programming languages. But this type/token business does not require us to solve it. It is a much simpler, more basic kind of clarification that does not depend in ANY WAY on the change-over-time issue. With the greatest respect, Sandro, your obsession with time and change has, I believe, hindered progress here. You keep going back to that issue, even when we have finally managed to agree (at least I thought we had) that the surface/token/named-graph vs. abstract graph distinction did not depend upon time or change, or even involve it. 

>  I'm happy for us to talk that out amongst ourselves, or to do it in a community group, or...  I dunno.  But obviously it's not an RDF WG thing.
> 
> As a first draft, I might state that problem as:   
> 
> Sometimes people write context-sensitive RDF like { :Alice :age 10 }, instead of decontextualized RDF like { :Alice :born 1852 }.  It would be helpful to have a standard way to indicate and reason about the intended context of context-sensitive graphs.   (In this case, the context of the first graph would have to be 1862 for both graphs to be true, give or take time-of-year factors.) 
> 
> Meanwhile, even RDF which is not inherently context-sensitive (like the above graph using the :age predicate), often turns out to be context-sensitive because it conveys something about the state of the world, and the state of the world sometimes changes. 

No. That the world changes state is true. That this implies, or requires, that RDF must be contextual, is false. Thinking that the first entails the second, is one of the most stubborn mistakes that people make when thinking about this stuff.

>  For instance, a foaf:name triple might turn out to be true for only certain years, if the subject changes their name.   And a foaf:mbox triple is true only when the subject has the given email address.    
> 
> Finally, even when an RDF graph contains information that in theory never changes, like birth dates or molecular weights of chemicals, in practice it might change because of errors being corrected or the truth becoming known with more precision.     For example, with a little historical research we might learn that the girl who inspired Alice in Wonderland was 10 in 1862, and put that in an RDF Graph.   With more research, we might discover her actually birthdate was 4 May 1852, and update our RDF database accordingly.

True, but irrelevant. Updating errors can happen with any data; it does not make the data itself contextual. That is not information changing with time because it does not imply that the information is about the 'present'. 

> 
> Aside from these issues of change-over-time, spacial context might turn out to be important to track.  Do people want to write graphs like { :SanFrancisco a :NearbyCity }, which are true only for an observer near San Francisco?

Even if they do, do we want to encourage them? 
> 
> And, of course, it is vital when gathering RDF data from many sources to establish and reason about the trustworthiness of each source.

Again, true but utterly irrelevant to the point being discussed. 
> 
> The challenge here is to provide a general model for how RDF data can be managed coming from multiple different sources, with different contexts and trustworthiness.

We had made some progress in keeping various different issues distinct, and you have managed in a few paragraphs to get at least four of them completely muddled up again. Just saying "general model" does not help disentangle the confusion. We will not get any kind of useful model if we just keep getting different ideas confused with one another. Trustworthiness has got diddly-squat to do with time and state change. Updating is not contextual assertion. The fact that the world is dynamic does not imply that our representations must be contextual. 

>  Further. we should if necessary define vocabulary terms and other mechanisms to improve interoperability and functionality of general RDF data exchange.
> 
> Now, of course, I'm thinking about the Dilbert Problem [1] (and [2]).   My solution would be something like this:
> GRAPH :2011q1 {
> <http://example.com/e-1> <http://example.com/hasCubicle> <http://example.com/c-1000> .
> <http://example.com/e-2> <http://example.com/hasCubicle> <http://example.com/c-1001> .
> <http://example.com/e-3> <http://example.com/hasCubicle> <http://example.com/c-1002> .
> }
> GRAPH :2011q2 {
> <http://example.com/e-1> <http://example.com/hasCubicle> <http://example.com/c-1001> .
> <http://example.com/e-2> <http://example.com/hasCubicle> <http://example.com/c-1000> .
> <http://example.com/e-3> <http://example.com/hasCubicle> <http://example.com/c-1002> .
> }
> :2011q1 dc:temporal [ :begins "2011-01-01"^^xs:DateTimeStamp; :ends "2011-03-20"^^xs:DateTimeStamp ].
> :2011q2 dc:temporal [ :begins "2011-03-20"^^xs:DateTimeStamp ].

I like this also, but it requires us to re-write the RDF semantics. It not hard to do this: as you know, I have already done it. But it is a real change. 

> 
> I'm wondering a little about making a Community Group for this.
> 
> More immediately, I'm wondering what the RDF WG is supposed to do about all this

The WG has already decided to not do anything about any of this. 

> , and what I'll be telling the Director about Jeremy's     comment at the next Transition Meeting.

I had better not put into an email what I would like you to say :-)

Pat

> 
>      -- Sandro   
> 
> [1] http://danbri.org/words/2011/11/03/753
> [2] http://lists.w3.org/Archives/Public/public-rdf-wg/2011Nov/0019.html
> 
> 
>> Dan
>> 
>>  
> 

------------------------------------------------------------
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)
phayes@ihmc.us       http://www.ihmc.us/users/phayes

Received on Friday, 20 September 2013 08:45:23 UTC