Re: defn of Named Graph

On 09/20/2013 04:44 AM, Pat Hayes wrote:
> 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

Sorry....     Hopefully you at least find this satisfying, enjoyable, or 
entertaining from time to time.

> , 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.

To me, it would be "solved" if there was a way to handle 
change-over-time that worked for my applications and that you didn't 
think was "broken" wrt RDF Semantics.    Hopefully other members of the 
community would like it, too. I don't think we need the perfect 
solution, or even consensus at this point.   Just something that some of 
us can use in our software with some reasonable hope it'll function as 
expected, and not violate the specs in any problematic way.

>   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 come back to it obsessively because there is such a dirth of other use 
cases.  (Perhaps I have a bias of wanting to solved for other uses 
cases; I'm trying hard to keep that in check.)      In recent weeks, I 
tried to keep this discussion to being just about identity without 
touching on change-over-time, but frankly I don't find the use cases 
compelling.

I'm now confident that you and I (and Jeremy) agree the problem we're 
trying to solve in this thread is this: people seem to want to have 
different properties on one "graph" than on another, even when the 
"graphs" happen to have the same triples.

But why do they want this?   As I poke at that problem, either it turns 
out this functionality doesn't actually matter to them, or they need it 
because they are actually dealing with "graphs" which could at least 
potentially change over time.

Do you have a use case (involving RDF on computers) for having different 
properties on different "graphs" (which happen to have the same 
triples), and which does not involve "graphs" changing over time?

(the rest of this email is beside the point, just some inline responses 
to your comments.)

>>   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.
>

I'd like to understand this, but let's wait on that until you actually 
want to talk about the change-over-time problem.

>>   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'.

It's data changing with time, not the world changing with time. 
Transaction time vs valid time, in the terminology of bitemporal 
databases.     It's something to consider and potentially rule 
out-of-scope in designing something to handle change-over-time.


>> 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.

Obviously, yes, that's not about change-over-time per se.   But these 
are closely related topics -- other uses for named graphs -- and it's 
quite likely IMHO that any design will handle these with closely related 
machinery.

>> 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.

Sorry it came out muddled.    I was just trying to enumerate the various 
problems that I want to use named graphs to solve, mostly in the 
change-over-time space.   Since I was proposing that we start working in 
that space, I wanted to cast a fairly broad net as a starting point -- 
then you could push back and say (for instance) that data corrections 
should be out-of-scope.


> 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.

Again, I don't quite understand why it's a change, but that's probably a 
distraction at the moment, so let's come back to it if necessary.

>> 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.

Well, it needs to do or say *something* to address Jeremy's comment, and 
now also the comment from Paul Groth.
>
>> , 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 :-)

Hmmm.    I can't even guess which direction you're aiming your friendly 
ire.   (me, the wg, jeremy, w3c process, tim, ... ) *shrug*

      -- Sandro

> 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 Tuesday, 24 September 2013 13:31:37 UTC