Re: rdf semantics and timelessly true

Hello Pat,

people should be able to save application state like the "Counter hasValue"
example in a triple store. I do not see a problem with this as long as this
data is not published. Triple stores should be used for knowledge *and* data.
Everything else would be quite limiting and involve a big overhead saving
knowledge here and data there.

As for the foaf:name example: The degree of detail is inversely correlated
to the achievable community size (http://vimeo.com/51152934). The foaf 
ontology has such a broad audience that making time mandatory would be too 
much. If I understand you right you don't think that foaf is broken but
that it can be done better with a smaller community size.

Regards,

Michael Brunnbauer

On Wed, Nov 14, 2012 at 10:09:59PM -0800, Pat Hayes wrote:
> 
> On Nov 14, 2012, at 9:56 AM, Nathan wrote:
> 
> > Pat Hayes wrote:
> >> On Nov 14, 2012, at 8:42 AM, Nathan wrote:
> >>> Pat Hayes wrote:
> >>>> On Nov 14, 2012, at 8:03 AM, Nathan wrote:
> >>>>> Hi Pat,
> >>>>> 
> >>>>> Pat Hayes wrote:
> >>>>>> Its not impossible, and in a strong sense this is required by the current RDF semantics, which treats all RDF assertions as timelessly true.
> >>>>> Can you refine / expand on this please? I'd presumed RDF to have no consideration of time - e.g time-less; as opposed to being true for all time (timeless).
> >>>>> 
> >>>>> TIA,
> >>>>> 
> >>>>> Nathan
> >>>> Yes, time-less is a better way to put it. But it is so because URIreferences are assumed (and I know this is an idealization, but...) to be timeless in how they refer. Section 1.2 says:  "... the semantics simply assumes that ... a single URI reference can be taken to have the same meaning wherever it occurs. Similarly, the semantics has no special provision for tracking temporal changes. It assumes, implicitly, that URI references have the same meaning whenever they occur."
> >>>> In other words, no counters allowed. 
> >>> What about any data that changes? if <http://webr3.org/nathan#me> refers to "me", and I change my name from Nathan to Bob, then I cannot update my RDF to reflect this? or perhaps more realistically, my email address?
> >> Its fine to coin a new URI for yourself. The issue arises if you want to re-use your old URI to refer to something different. What you *ought* to do, according to the strict RDF rules (and TimBL's idea of "cool URIs") is to coin a new URI for the new thing and keep the old one meaning the same thing as it always did. But note, it is fine for this "thing" to be something that is dynamic, ie which has states that change with time. LIke a daily newspaper, for example. But then you need to be careful to distinguish this thing from one of its states... 
> > 
> > That makes sense, however I'd still like to clarify further, specifically on the distinction between something which changes states, and something who's properties may change over time.
> 
> OK, let me interrupt with a quick disclaimer. I DONT want to defend this distinction. There is a huge metaphysical/ontological sinkhole here that some very clever people have fallen into, trying to distinguish between things that have states and things that simply endure while their properties change. All that matters for the present discussion is that, however you describe this, to do so properly requires that you relate this thing to a property and a time: *three* entities that all have to be involved in the data record. [*1] As opposed to just relating two of them, the thing and its property, and relying on the "actual time" (AKA "now" or "the present") to play the role of the missing time reference. 
> 
> > 
> > To persist with the name example, a good percentage of females will have their surname change over time - so what do we do when today we have:
> > { <#mary> foaf:lastName "Thompson"@en . }
> > and tomorrow:
> > { <#mary> foaf:lastName "Davids"@en . }
> > 
> > How do we distinguish mary from one of her states?
> 
> Well, to be strict about it, we ought to say that names that are liable to get changed are names *at a time*, or perhaps in this case names *up to a time*, and that the name after that time (of marriage, in our culture) is a different name. OK, thats being very strict, because this kind of change is comparatively infrequent (in a single lifetime, I mean) and it is often assumed that such data is indeed intended to be "about the present", and that it will get updated from time to time. We even have special constructs, eg the "neé" relation to indicate a previous name, for this case. But try doing this for something which changes its state compartively rapidly, such as the noon temperature at a certain location, or the headline in the NYTimes. 
> 
> In your example, what happens to the first Thompson triple on the day after Mary gets married? Is it just deleted, and forgotten about? (But what about all the copies of it that may be cached in RDF stores anywhere on the Web?) Or does it get modified using a "neé" kind of property? And is the date of the change-over recorded? What about this new Davids triple: it wasn't always true: shouldn't the data record the date when it started being true, in case someone wants to check something historical, not just about what is true "now"? The more you ask quesitons like this, the more it seems that time information should have been in this kind of data from the get-go. 
> 
> Pat
> 
> [*1] The metaphysical debate is between those who want to associate the time with the property, and those who want to associate it with the thing. The former would say Mary's properties change, the latter would say that Mary changes her state. After years of arguing about this, I no longer care which you say: the basic logic is the same in both cases. 
> 
> 
> > 
> > TIA,
> > 
> > Nathan
> > 
> > 
> 
> ------------------------------------------------------------
> 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
> 
> 
> 
> 
> 

-- 
++  Michael Brunnbauer
++  netEstate GmbH
++  Geisenhausener Straße 11a
++  81379 München
++  Tel +49 89 32 19 77 80
++  Fax +49 89 32 19 77 89 
++  E-Mail brunni@netestate.de
++  http://www.netestate.de/
++
++  Sitz: München, HRB Nr.142452 (Handelsregister B München)
++  USt-IdNr. DE221033342
++  Geschäftsführer: Michael Brunnbauer, Franz Brunnbauer
++  Prokurist: Dipl. Kfm. (Univ.) Markus Hendel

Received on Thursday, 15 November 2012 07:13:56 UTC