- From: Nathan <nathan@webr3.org>
- Date: Wed, 03 Nov 2010 22:18:35 +0000
- To: Jonathan Rees <jar@creativecommons.org>
- CC: Larry Masinter <masinter@adobe.com>, "www-tag@w3.org" <www-tag@w3.org>
Jonathan Rees wrote: > Just to be clear, the goal here, I think, is not to argue for or > against tdb: or duri:. The problem to be solved is that people are > talking about duri: and tdb: but don't have a good publication to cite > that describes them. Right now we should be focussing on how to help > Larry publish the clearest document possible as a contribution to the > larger conversation about "identifiers". Good point and noted, will be interesting to see the uses of duri and tdb in the wild once this is published, thus will have another read over and pass on any constructive comments I have :) > On Wed, Nov 3, 2010 at 10:42 AM, Nathan <nathan@webr3.org> wrote: >> so in an n3/turtle version of the above, should I be using tdb's or duri's >> and in which combination? what are the consequences of using the wrong ones? > > I know how Larry feels about RDF, so I'll try to answer for him. > > The semantics of tdb: is pretty clear, I think: expressed in RDF we have > <duri:T:U> foaf:primaryTopic <tdb:T:U>. > (For those of you who have as much difficulty with the role-noun > pattern as I do, '-- foaf:primaryTopic --' should be read '-- has, as > its primary topic, --'. http://xmlns.com/foaf/spec/#term_primaryTopic > ) > > The semantics of duri: is a bit more complex but also clear in > RDF-land I think. The expression in RDF is awkward since it involves > the ternary relation "A is {what B was like at time T}". Rather than > invent the three necessary RDF properties I'll just write it that way. > <duri:T:U> is {what _U1 was like at time T} > where _U1 is {what U identified at time T}. > We don't usually reify the "identified by" relation in RDF, or worry > about changes in the relation over time, since there is little benefit > in doing so. If we thought that U "identified" two different things at > two times, we probably wouldn't want to call either of those things > <U>. For most purposes we can take <U> = _U1, and we have > <duri:T:U> is {what <U> was like at time T} > > You seem to be pretty good with RDF and reasoning, so you should be > able to figure out how to use tdb: and duri: based on the above > semantics. Unless the RDF semantics were updated to include seeing URIs as anything other than RDF names / logical constants, and to provide for schemes having meaning, and introduced semantics for temporal change, then figuring this out would be a bag of worms I'd rather not get in to! Saying that, my typical feeling on the matter of temporal change with regards RDF, is that you should assemble a graph of statements you are going to consider based on some out of band knowledge of time, probably considering the publishing/authoring date of the document/message containing the statements, thus only considering statements made within a specific time range - a temporal subgraph if you will - just as we do in life when reading historical documents about a particular subject. I guess the out of band information could, and probably often will, be based on date-times found within RDF statements (such as dc:published "1997-03-11"^^xsd:date), thus it stands to reason (!) that the out of band information could also be gathered from within the timestamps of duri and tdb scheme URIs found within statements. FWIW, duri scheme appears perfectly clear, tdb with fragments or where a doc describes multiple things (_Things_ described by) isn't so clear. > If you're familiar with Memento, {what <U> was like at time T} should > look familiar. In an earlier email I expressed the relationship in > terms of "representations". Indeed I have, nice project, also it's aligned with my earlier comments about considering the publishing date of the message/document to establish some temporal anchor, rather than the information within the document/message, so slightly different, but yep I follow :) > I'm not sure how to make the document say all this better than it > already does (beyond the suggestions I already sent). If you can > figure out where it's unclear that would be helpful. Agree, I'll give it another once over as I did have a few editorial comments. > It's not clear whether one can use duri: for things other than > "information resources". I would assume not, but I don't think > generalizing it to, say, physical objects (what my hand was like in > 1976) adds any logical complexity. I don't think the document should > talk about this twist. Should that be clear? I guess specifically I wonder if fragments should be allowed in (1) duri and (2) tdb, the tdb case is the one I wonder about most. Best, Nathan
Received on Wednesday, 3 November 2010 22:19:37 UTC