Graham Klyne | 1 Jul 16:47 2009

Re: URI for abstract concepts (domain, host, origin, site, etc.)

Dan Brickley wrote:
> This is an interesting design! I need to think about it a bit more. I 
> expect it would cause some pressure for shorter media-type names. Hmm 
> from http://www.iana.org/assignments/media-types/ ... "model", hadn't 
> noticed that... http://www.iana.org/assignments/media-types/model/ maybe 
> #(model/rdf)blahblah is worth thinking about too. Not sure this is great 
> from an I18N perspective, if it forces people to put English script into 
> IRIs that might otherwise be all in another script...

As I recall, model/... is specifically intended for descriptions of 
3-dimensional physical structures (virtual reality data, etc.).  Cf. 
http://www.rfc-editor.org/rfc/rfc2077.txt

#g

Erik Wilde | 2 Jul 02:00 2009
Picon

Re: URI for abstract concepts (domain, host, origin, site, etc.)

hello.

Xiaoshu Wang wrote:
> In other words, the URN is an HTTP-URL sans "http:"
> There are several advantages of this.  Although an HTTP-URL can be taken 
> as a URN as well as a URI.  But this dual mode makes people very 
> uncomfortable.  This scheme-less URN helps easy the issue.

i am nor sure i understand this. URNs were intended to denote things 
that have no clearly defined way of retrieval, but the notion that 
locators and names are two entirely different things never was really 
true, which is probably the reason why the whole URN thing did not 
happen. but by using domain names in what you call "URNs", you put quite 
a bit of internet-specificity into what should be an abstract naming 
scheme. how would you, for example, in that approach map ISBN numbers to 
your proposed URN structure?

cheers,

dret.

Xiaoshu Wang | 2 Jul 02:54 2009

Re: URI for abstract concepts (domain, host, origin, site, etc.)

Erik Wilde wrote:
> hello.
>
> Xiaoshu Wang wrote:
>   
>> In other words, the URN is an HTTP-URL sans "http:"
>> There are several advantages of this.  Although an HTTP-URL can be taken 
>> as a URN as well as a URI.  But this dual mode makes people very 
>> uncomfortable.  This scheme-less URN helps easy the issue.
>>     
>
> i am nor sure i understand this. URNs were intended to denote things 
> that have no clearly defined way of retrieval, but the notion that 
> locators and names are two entirely different things never was really 
> true, which is probably the reason why the whole URN thing did not 
> happen. but by using domain names in what you call "URNs", you put quite 
> a bit of internet-specificity into what should be an abstract naming 
> scheme. how would you, for example, in that approach map ISBN numbers to 
> your proposed URN structure?
>   
First, I think that an absolute sense of URN is of no use.  People must 
associate a name with some kind of access-protocol,  walking, running, 
driving, seeing etc. to interact with the desired referent in order to 
know the referent.  My URN is in the sense of it is independent of a 
protocol, but does not mean that there is no protocol to support it.

Second, the relation between a name and its transportation protocol must 
be maintained/defined somewhere, otherwise a name is useless.  What I am 
suggesting is that to store the relationship between a URN and its URL 
in humans as opposed to be defined as a technical specification.  
(Continue reading)

David Booth | 1 Jul 16:07 2009

RE: URI for abstract concepts (domain, host, origin, site, etc.)

Larry,

On Sun, 2009-06-28 at 10:53 -0700, Larry Masinter wrote:
> I'm thinking about revising
>  http://larry.masinter.net/duri.html
> 
> to:
> (1) to get rid of "duri" and just stick with "tdb"
>   (because there isn't much use for duri at all)
> (2) make it a URI scheme rather than a URN namespace
> (3) make the date optional, for cases where the time of
>   binding resource to representation (and of interpretation
>   of that representation to an 'abstract concept')
> 
> So the simplest form would be
> 
> tdb:http://larry.masinter.net

That makes it remarkably similar to
http://t-d-b.org?http://larry.masinter.net

but the t-d-b.org URI has the advantage that it doesn't require a new
URI scheme, and it *might* be dereferenceable by a browser.  In fact, at
the moment it *is* dereferenceable. 

> 
> which would neatly allow using descriptions of
> abstract concepts to identify the abstract concept.

That sounds like what the "http://t-d-b.org?" prefix does.
(Continue reading)

Eran Hammer-Lahav | 2 Jul 18:49 2009

RE: URI for abstract concepts (domain, host, origin, site, etc.)

But this approach means a parser cannot figure out the meaning of a URI without a GET. How would a parser know
that a document about such a URI is really about something else (the subject of the URI) and not the resource
the URI itself is identifying?

For this to work, I need to hardcode http://t-d-b.org into every parser to have a specialized meaning.

EHL

> -----Original Message-----
> From: David Booth [mailto:david <at> dbooth.org]
> Sent: Wednesday, July 01, 2009 7:08 AM
> To: Larry Masinter
> Cc: 'Jonathan Rees'; ashok.malhotra <at> oracle.com; Eran Hammer-Lahav;
> apps-discuss <at> ietf.org; www-tag <at> w3.org; 'URI'
> Subject: RE: URI for abstract concepts (domain, host, origin, site,
> etc.)
> 
> Larry,
> 
> On Sun, 2009-06-28 at 10:53 -0700, Larry Masinter wrote:
> > I'm thinking about revising
> >  http://larry.masinter.net/duri.html
> >
> > to:
> > (1) to get rid of "duri" and just stick with "tdb"
> >   (because there isn't much use for duri at all)
> > (2) make it a URI scheme rather than a URN namespace
> > (3) make the date optional, for cases where the time of
> >   binding resource to representation (and of interpretation
> >   of that representation to an 'abstract concept')
(Continue reading)

Pat Hayes | 3 Jul 00:06 2009
Picon

Re: URI for abstract concepts (domain, host, origin, site, etc.)


On Jul 2, 2009, at 11:49 AM, Eran Hammer-Lahav wrote:

> But this approach means a parser cannot figure out the meaning of a  
> URI without a GET. How would a parser know that a document about  
> such a URI is really about something else (the subject of the URI)  
> and not the resource the URI itself is identifying?
>

Why would a *parser* need to know such a thing? A reasoner could know  
this by having access to some sentences that told it what the URI  
refers to. I don't know of any other general way that any entity,  
including a human being, could know what a URI was intended to denote.

> For this to work, I need to hardcode http://t-d-b.org into every  
> parser to have a specialized meaning.

No, you just have to know that it indicates that the URI refers to  
*something*. Since URIs can (be used to) refer to anything, it isnt  
possible to have a "specialized" meaning.

Pat

>
> EHL
>
>> -----Original Message-----
>> From: David Booth [mailto:david <at> dbooth.org]
>> Sent: Wednesday, July 01, 2009 7:08 AM
>> To: Larry Masinter
(Continue reading)

Erik Wilde | 3 Jul 02:22 2009
Picon

Re: URI for abstract concepts (domain, host, origin, site, etc.)

On Jul 2, 2009, at 15:06, Pat Hayes <phayes <at> ihmc.us> wrote:
Why would a *parser* need to know such a thing? A reasoner could know this by having access to some sentences that told it what the URI refers to. I don't know of any other general way that any entity, including a human being, could know what a URI was intended to denote.

that's the semantic web world view, where URIs are completely opaque, always supposed to be http:, and to learn anything about them, a description must be found and used. on the plain web, URI schemes carry semantics, so that a client needs no additional information about tel: to be able to use these URIs. of course, the semantic web methods of describing something are far richer, but that should not imply that all URI semantics are or should be deferred to semantic web technologies.

cheers,

dret.
_______________________________________________
Apps-Discuss mailing list
Apps-Discuss <at> ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss
David Booth | 6 Jul 05:08 2009

RE: URI for abstract concepts (domain, host, origin, site, etc.)

On Thu, 2009-07-02 at 09:49 -0700, Eran Hammer-Lahav wrote:
> But this approach means a parser cannot figure out the meaning of a
> URI without a GET. 

No, the GET can be optimized away if the parser is aware of this
convention, as described here:
http://thing-described-by.org/#optimizing
This is comparable to a parser being aware of the "tdb:" scheme.

> How would a parser know that a document about such a URI is really
> about something else (the subject of the URI) and not the resource the
> URI itself is identifying?
> 
> For this to work, I need to hardcode http://t-d-b.org into every
> parser to have a specialized meaning.

No, parsers that do not know about this "http://t-d-b.org?" prefix can
dereference the URI if they wish, whereupon they will be 303-redirected
to the descriptive document, in accordance with:
http://www.w3.org/TR/cooluris/
http://lists.w3.org/Archives/Public/www-tag/2005Jun/0039

On the other hand, parsers that *do* know about this prefix can skip the
initial HTTP request and go directly to the descriptive document.  In
comparison with a "tdb:" URI, the result would be the same for parsers
that know about the special "tdb:" or "http://t-d-b.org?" prefix.  But
parsers that do not know about the "tdb:" would be out of luck, whereas
parsers that do not know about the "http://t-d-b.org?" prefix may still
be able to find the descriptive document by dereferencing the URI.

David Booth

> 
> EHL
> 
> > -----Original Message-----
> > From: David Booth [mailto:david <at> dbooth.org]
> > Sent: Wednesday, July 01, 2009 7:08 AM
> > To: Larry Masinter
> > Cc: 'Jonathan Rees'; ashok.malhotra <at> oracle.com; Eran Hammer-Lahav;
> > apps-discuss <at> ietf.org; www-tag <at> w3.org; 'URI'
> > Subject: RE: URI for abstract concepts (domain, host, origin, site,
> > etc.)
> > 
> > Larry,
> > 
> > On Sun, 2009-06-28 at 10:53 -0700, Larry Masinter wrote:
> > > I'm thinking about revising
> > >  http://larry.masinter.net/duri.html
> > >
> > > to:
> > > (1) to get rid of "duri" and just stick with "tdb"
> > >   (because there isn't much use for duri at all)
> > > (2) make it a URI scheme rather than a URN namespace
> > > (3) make the date optional, for cases where the time of
> > >   binding resource to representation (and of interpretation
> > >   of that representation to an 'abstract concept')
> > >
> > > So the simplest form would be
> > >
> > > tdb:http://larry.masinter.net
> > 
> > That makes it remarkably similar to
> > http://t-d-b.org?http://larry.masinter.net
> > 
> > but the t-d-b.org URI has the advantage that it doesn't require a new
> > URI scheme, and it *might* be dereferenceable by a browser.  In fact,
> > at
> > the moment it *is* dereferenceable.
> > 
> > >
> > > which would neatly allow using descriptions of
> > > abstract concepts to identify the abstract concept.
> > 
> > That sounds like what the "http://t-d-b.org?" prefix does.
> > 
> > > (Syntactically, the date can be left out without
> > > ambiguity.)
> > >
> > > Would this be helpful, at least for illustrative purposes?
> > 
> > I think the goal is reasonable, but as explained in
> > http://dbooth.org/2006/urn2http/
> > I don't think a new URI scheme is necessary to achieve it.  Similar
> > things can be done with http URIs, with greater benefit.
> > 
> > >
> > > I think there are other means for distinguishing
> > > between the representation of a  description and
> > > the thing described, but this would at least
> > > add a well-known method that isn't tied to
> > > any particular protocol, linking method, resolution
> > > method, etc.
> > 
> > Right, but "http:" URIs do not necessarily need to be resolved using
> > HTTP, nor do they necessarily need to be resolved at all.  At worst
> > they
> > can be treated as opaque strings, but at best they *might* be
> > dereferenceable to useful information.  A URI prefix like
> > "http://t-d-b.org?" can become "well known" just as "tdb:" can.  This
> > is
> > a social issue, independent of whether a new scheme is defined.
> > 
> > 
> > --
> > David Booth, Ph.D.
> > Cleveland Clinic (contractor)
> > 
> > Opinions expressed herein are those of the author and do not
> > necessarily
> > reflect those of Cleveland Clinic.
> 
> 
> 
> 
--

-- 
David Booth, Ph.D.
Cleveland Clinic (contractor)

Opinions expressed herein are those of the author and do not necessarily
reflect those of Cleveland Clinic.

Larry Masinter | 13 Jul 17:59 2009
Picon

FW: New Version Notification for draft-masinter-dated-uri-06

After a long hiatus on "tdb", I updated the document
based on some feedback.

Changed from URN scheme to URI, got rid of "duri"
and just left "tdb".



-----Original Message-----
From: IETF I-D Submission Tool [mailto:idsubmission <at> ietf.org] 
Sent: Sunday, July 12, 2009 10:43 PM
To: lmm <at> acm.org
Cc: LMM <at> acm.org
Subject: New Version Notification for draft-masinter-dated-uri-06


A new version of I-D, draft-masinter-dated-uri-06.txt has been successfuly submitted by Larry Masinter
and posted to the IETF repository.

Filename:	 draft-masinter-dated-uri
Revision:	 06
Title:		 The "tdb" URI scheme: denoting described resources
Creation_date:	 2009-07-12
WG ID:		 Independent Submission
Number_of_pages: 13

Abstract:
This document defines a URI scheme, "tdb" ( standing for "Thing
Described By").  It provides a semantic hook for allowing anyone at
any time to mint a URI for anything that they can describe.  Such
URIs may include a timestamp to fix the description at a given date
or time.

This URI scheme may reduce the need to define define new URN
namespaces merely for the purpose of creating stable identifiers.  In
addition, they provide a ready means for identifying "non-information
resources" by semantic indirection -- a way of creating a URI for
anything.

Note

This document is not a product of any working group.  Many of the
ideas here have been discussed since 2001.  This document has been
discussed on the mailing list <uri <at> w3.org>.  Previous versions have
couched "tdb" as a URN namespace, and included a "duri" scheme for
fixing date without indirection, which seems unnecessary.  It was
originally written as a thought experiment as a way of resolving the
use/mention problem in semantic web applications, but may have other
uses.
                                                                                  


The IETF Secretariat.


Larry Masinter | 13 Jul 22:45 2009
Picon

FW: New Version Notification for draft-duerst-iri-bis-06

This version attempts to integrate the "web address"
concept (called Hypertext Reference or HREF) into the
main IRI specification.  The text has gone through sufficient
transformations that I don't have confidence in its
accuracy, but at least it indicates to me that the
many specs are mergable.

I wound up making relatively minor changes to the 
introductory text as well.

Comments/discussion =>    public-iri <at> w3.org

(other mailing lists bcc'd)


-----Original Message-----
From: IETF I-D Submission Tool [mailto:idsubmission <at> ietf.org] 
Sent: Monday, July 13, 2009 8:13 AM
To: Larry Masinter
Cc: duerst <at> it.aoyama.ac.jp; michel <at> unicode.org
Subject: New Version Notification for draft-duerst-iri-bis-06 


A new version of I-D, draft-duerst-iri-bis-06.txt has been successfuly submitted by Larry Masinter and
posted to the IETF repository.

Filename:	 draft-duerst-iri-bis
Revision:	 06
Title:		 Internationalized Resource Identifiers (IRIs)
Creation_date:	 2009-07-12
WG ID:		 Independent Submission
Number_of_pages: 53

Abstract:
This document defines a new protocol element, the Internationalized
Resource Identifier (IRI), as an extension of the Uniform Resource
Identifier (URI).  An IRI is a sequence of characters from the
Universal Character Set (Unicode/ISO 10646).  A mapping from IRIs to
URIs is defined, which provides a means for IRIs to be used instead
of URIs, where appropriate, to identify resources.

To accomodate widespread current practice, additional derivative
protocol elements are defined, and current practice for resolving
IRI-based hypertext references in HTML are outlined.

The approach of defining new protocol elements, rather than updating
or extending the definition of URI, was chosen to allow independent
orderly transitions as appropriate: other protocols and languages
that use URIs and their processing may explicitly choose to allow
IRIs or derivative forms.

Guidelines are provided for the use and deployment of IRIs and
related protocol elements when revising protocols, formats, and
software components that currently deal only with URIs.

[RFC Editor: Please remove this paragraph before publication.]  This
is a draft to update RFC 3987 and move towards IETF Draft Standard.
For an issues list/change log and additional information (including
mailing list information), please see
http://www.w3.org/International/iri-edit.  For discussion and
comments on this draft, please use the public-iri <at> w3.org mailing
list.
                                                                                  


The IETF Secretariat.



Gmane