Re: "tdb" and "duri" URI schemes...

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