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

Larry Masinter wrote:
> What about having the date optional... 
> so you could say tdb::<uri>  if you really don't want
> to give a timestamp.

That'd work too, in either flavour:

  tdb [ ":" <timestamp> ] ":" <uri>

or

  tdb ":" [ <timestamp> ] ":" <uri>

> But I still can't think of a use case.

I can :) there a lot of published data out there where the thing and the 
thing described use the same URI, I'll be wrapping up those URIs in 
tdb's when referencing them from my own data, hopefully, and don't need, 
want or have a date to ascribe. Think of it as wanting to identify the 
thing described by the current description (as the web currently works).

>>> And duri with data: doesn't make sense to me.
> 
> Well, it "makes sense", it just doesn't do anything
> (unless, I suppose, the data URI scheme were to change?)
> 
>> Likewise to some extent, however, with duri:
>>
>>  duri:2010:tdb:data:,The%20US%20president
> 
> I don't like this much, although I understand it.
> Just putting the date in tdb:2010:data:,... seems simpler.

I agree, but also it removes the possibility of:

   tdb:1996:duri:2010:<uri>

However the primary reason for mentioning was so that timestamp wasn't 
required in a tdb, the above consideration was why i suggested removing 
the timestamp rather than making it optional. I can though work with either.

>> and non temporally bound:
>>   tdb:data:,The%20US%20president
> 
> Can you give a scenario where this would be useful?

Yes I can actually, where the data uri encodes a doc or an image of me 
for instance - data uris are increasingly common on the web (as embedded 
media in html docs and css for instance), and will be even more common 
as the File* specs from web-apps/html5 become more common.

>> Regardless of this though, definitely need fragments in the URIs, 
>> encoded or not.
> 
> It's just syntactically messy. I'd need to make up some
> other way of encoding # than %hex.

agree, remind me why does it need encoded?

Best,

Nathan

Received on Friday, 5 November 2010 11:12:43 UTC