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

[Xiaoshu Wang]

Jonathan Rees wrote:

> On Sat, Jun 27, 2009 at 9:07 PM, ashok
> malhotra<ashok.malhotra@...> wrote:
>  
>> Hi Eran:
>> Trying to understand your proposal.
>> By 'abstract' do you mean URIs for which a representation cannot be
>> retrieved?
>> So, perhaps, a chair?
>> My assumption was that for such resources you want to retrieve the metadata.
>>    
>
> Quibble: In the case of a chair, you can't get metadata, since a chair
> isn't data.
> http://www.google.com/search?q=define:metadata
>  

Then, what is data?  This is not intended for a child-play.  It is a
method of philosophical or scientific inquiry.  For instance, most of
the physics theory is, in fact, driven by a seemingly ridiculous
question: what is motion?  And more profoundly, what is space and time.
> This is why it's nice that Eran calls the description resource a
> "description resource" instead of a "metadata resource".
This is again a psychological trick that does not solve any real word
problem because then: what is "description resource"?  Find something
that is non-descriptive? "X" does not say anything about "Y" makes "X" a
descriptive resource of "Y", doesn't it?  Then, the fallacy of the
definition is obvious.  What word we use is in fact inconsequential,
whatever it is, it is just merely a label for the conceptualization,
which desires an unambiguous definition.

It is the same for the ambiguous concepts, such as "information" and
"metadata" etc.  If you cannot find a definition that can tell metadata
from non-metadata, you are not giving out a definition. Which is then
useless in practice.  I can assure you if you go on this direction,
whatever resolution it comes out will be another httpRange-14.

> LRDD is a
> compatible alternative to linked-data 303 nose-following, one that
> (like 303, as David Booth has pointed out) behaves uniformly without
> caring whether the resource is "data"-like or not - it means you don't
> have to ask or answer that question. I advocate using his terminology.
>
> Perhaps an alternative to a new URI scheme for hosts would be loop
> detection inside of LRDD? I think that's close to what you're saying.
>
> -Jonathan
>
>  

[Xiaoshu Wang]

Eran Hammer-Lahav wrote:

> Let me try explaining my use case again, this time without any overloaded terminology or proposed solutions.
>
> ---
>
> XRD is a document format for describing resources. It looks like this:
>
> <XRD>
> <Subject>http://example.com</Subject>
> <Type>http://example.org/type/blog</Type>
> <Link>
> <Rel>author</Rel>
> <URI>http://example.com/author</URI>
> </URI>
> </XRD>
>
> Without getting too much into XRD, this short descriptor describes the resource identified by 'http://example.com'. It includes one type indicator (a made up example meant to mean this resource is a blog), and one link to the author's page.
>
> ---
>
> I want to use this document format to describe rules that apply to all resources which belong to an HTTP host (as defined by 2616: a domain/address and port combination). The problem is, <Subject> requires a URI and currently there is no way to identify this set of resources (http://domain:port/*) as a valid URI.
>
> What I don't want to do is use an exception such as 'if the URI begins with X, treat it as a rule and not a valid URI'...
>
> EHL
>
>
>  
>> -----Original Message-----
>> From: ashok malhotra [mailto:ashok.malhotra@...]
>> Sent: Saturday, June 27, 2009 6:08 PM
>> To: Eran Hammer-Lahav
>> Cc: apps-discuss@...; www-tag@...; URI
>> Subject: Re: URI for abstract concepts (domain, host, origin, site,
>> etc.)
>>
>> Hi Eran:
>> Trying to understand your proposal.
>> By 'abstract' do you mean URIs for which a representation cannot be
>> retrieved?
>> So, perhaps, a chair?
>>
>> My assumption was that for such resources you want to retrieve the
>> metadata.
>> To do that you do a GET which returns a 'Not Found' as well as a Link
>> Header.
>>
>> Of course, if you know syntactically that the resource does not have a
>> representation
>> you can save one access and go directly for the metadata.
>>
>> Is that where you are going?
>>
>> All the best, Ashok
>>
>>
>> Eran Hammer-Lahav wrote:
>>    
>>> LRDD [1] defines a way to link a descriptor (metadata, information
>>>      
>> about, etc.) to a resource. It keeps the document format of the
>> descriptor out of scope, leaving it up to existing formats (XRDS, XRD,
>> POWDER, Metalink, etc.) and new format to address.
>>    
>>> Most of these descriptor formats include an element which indicates
>>>      
>> what the document is about - the subject of the descriptor. XRD
>> includes the <Subject> element for this purpose with xs:anyURI as its
>> type. I believe POWDER uses RDF's 'about' attribute in a similar way
>> IIRC.
>>    
>>> We have some use cases in which the subject of the descriptor does
>>>      
>> not have a URI available.
>>    
>>> LRDD uses a well-known-location document (/host-meta, soon to be
>>>      
>> replaced with /.well-known/host-meta) to store information about the
>> abstract host resource (the combination of domain name and port number,
>> potentially also including protocol). Over the past few years, ad-hoc
>> protocols have been abusing the root resource URI to mean something
>> beyond just the root resource of a domain - basically as a placeholder
>> for information about the entire domain or host.
>>    
>>> The lack of URI for such concepts is preventing descriptor formats
>>>      
>> from being used here because there is no valid URI available to insert
>> into the subject container. While no representation is expected for
>> such abstract concepts, within the context of descriptors, being able
>> to reference them is critical.
>>    
>>> The use case at hand is using XRD as the document format for host-
>>>      
>> meta. Host-meta describes attributes of the host which by itself does
>> not currently have a URI. We need to figure out what to put in the
>> host-meta document's <Subject> element which has direct impact on the
>> trust profile and signature (but is outside the scope of this
>> discussion).
>>    
>>> So far I could only come up with two options:
>>>
>>> 1. Make a special case exception that when the subject is
>>>      
>> http://______/.well-known/host-meta, it is treated differently than any
>> other URI in that it means the XRD is not about that URI (the host-meta
>> document itself), but about the abstract host resource located at
>> ______.
>>    
>>> 2. Define a new kind of URI that can be used for abstract entities
>>>      
>> such as "host" or "domain", but which is not an http URI because that
>> will bring us right back to #1.
>>    
>>> I would like to ask for feedback on the idea of proposing a new URI
>>>      
>> scheme or a new URN namespace for this purpose, something like
>> 'abstract'.
>>    
>>> It will look something like this (please focus on the idea, not the
>>>      
>> syntax of the examples):
>>    
>>> urn:abstract:domain:example.com
>>> urn:abstract:host:example.com:8080
>>> urn:abstract:origin:example.com:8080:http
>>>
>>> or
>>>
>>> abstract://example.com/domain
>>> abstract://example.com:8080/host
>>> abstract://example.com:8080:http/origin
>>>
>>> Any comments, feedback, or concerns would be greatly appreciated.
>>>
>>> EHL
>>>
>>> [1] http://tools.ietf.org/html/draft-hammer-discovery
>>>
>>>
>>>
>>>
>>>      
>
>  

(1) You develop your XSD document format, in whatever form you think is
the most suitable.  And you deploy that definition in the Web, say
http://xsd.type.com, which in essence makes it a media-type.
(2) Then, you client content-negotiate the XSD content with that URI
with the desired resource.

It is as easy as it gets.  All communication problem can (and I think
should be solved in this way).  I said can because, as Butler Lampson
has famously said: "All problems in computer science can be solved by
another level of indirection".  Content negotiation is just a level of
"indirection".  The problem is abstracted into a URI and then negotiated
over that URI.

Xiaoshu

[Eran Hammer-Lahav]

> -----Original Message-----
> From: Xiaoshu Wang [mailto:wangxiao@...]
> Sent: Sunday, June 28, 2009 7:34 PM

> (1) You develop your XSD document format, in whatever form you think is
> the most suitable.  And you deploy that definition in the Web, say
> http://xsd.type.com, which in essence makes it a media-type.
> (2) Then, you client content-negotiate the XSD content with that URI
> with the desired resource.
>
> It is as easy as it gets.  All communication problem can (and I think
> should be solved in this way).  I said can because, as Butler Lampson
> has famously said: "All problems in computer science can be solved by
> another level of indirection".  Content negotiation is just a level of
> "indirection".  The problem is abstracted into a URI and then
> negotiated
> over that URI.

I disagree [1], and have no interest in having this discussion with you *again* [2].

EHL

[1] http://www.hueniverse.com/hueniverse/2009/03/discovery-and-content-negotiation.html
[2] http://lists.w3.org/Archives/Public/www-tag/2009Mar/0034.html

["Martin J. Dürst"]

On 2009/06/29 0:02, Xiaoshu Wang wrote:

> Martin J. Dürst wrote:
>> On 2009/06/27 3:36, Xiaoshu Wang wrote:
>>
>>> Thus,
>>>
>>> "http://danbri.org/foaf.rdf#danbri" denotes a person.
>>> "http://danbri.org/foaf.rdf#(application/rdf+xml)danbri" denotes an RDF
>>> node.
>>> "http://danbri.org/foaf.rdf#(application/xhtml+xml)danbri" denotes an
>>> HTML element ided "danbri
>>
>> I don't understand this. Why wouldn't I just use
>> http://danbri.org/foo.html#danbri
>> or anything similar for HTML fragments? (I'm assuming that foaf.rdf
>> returns an application/rdf+xml documend, and foo.html returns an
>> application/xhtml+xml document; the extensions may be meaningless to
>> the protocol but help to keep things apart for humans and computers.)

> Well, then it just doesn't work for extending the referential range of
> URI to denote things beyond engineering entities. If you take a URI
> (fragment or not) to denote document (or its sub-structure), then the
> Web is not much useful to our daily use. If you take a URI to denote
> other things, like a human or person, then you cannot describe a
> document structure. And there is one URI, then you have to make a
> decision which one it denotes, right?

Yes, each URI better denotes only one thing. But that doesn't mean that
all URIs (with fragment identifiers) denote subdocuments, and it doesn't
mean that all URIs (with fragment identifiers) denote 'other things'. It
means that each individual URI denotes either one or the other, and that
you find out which one (if you need to) by getting more information
about it.

>> Also, I don't see much of a need to denote an RDF node per se. I'm
>> sure there are special applications one can come up with where
>> reasoning about RDF nodes per se is helpful/necessary/whatever, but
>> for such cases, there are other techniques available already. A single
>> special property and blank nodes would do the job.
> Sure, we can use special property and blank nodes, but don't we need to
> know a URI does first before applying a property to that right?

People who 'apply properties' to URIs (which I assume you mean to add
properties about an URI) will know an URI from other information or
because they created the URI and decided what they want to use it for.
People who see an URI for the first time have to find out what it stands
for either from context or from dereferencing (or probably from both).

Regards,   Martin.
--
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:duerst@...

[Phil Archer-3]

Eran Hammer-Lahav wrote:

> Let me try explaining my use case again, this time without any overloaded terminology or proposed solutions.
>
> ---
>
> XRD is a document format for describing resources. It looks like this:
>
> <XRD>
> <Subject>http://example.com</Subject>
> <Type>http://example.org/type/blog</Type>
> <Link>
> <Rel>author</Rel>
> <URI>http://example.com/author</URI>
> </URI>
> </XRD>
>
> Without getting too much into XRD, this short descriptor describes the resource identified by 'http://example.com'. It includes one type indicator (a made up example meant to mean this resource is a blog), and one link to the author's page.
>
> ---
>
> I want to use this document format to describe rules that apply to all resources which belong to an HTTP host (as defined by 2616: a domain/address and port combination). The problem is, <Subject> requires a URI and currently there is no way to identify this set of resources (http://domain:port/*) as a valid URI.

As I see it, the problem is that you require type to be a URI. Why? Why
not encode your rules instead? POWDER does this in a way that could, if
you so chose, be applied pretty well directly in XRD so that it would
look like:


<XRD>
        <Subject>
                <includeschemes>http</includeschemes>
                <includehosts>example.com</includehosts>
        </Subject>
        <Type>http://example.org/type/blog</Type>
        <Link>
                <Rel>author</Rel>
                <URI>http://example.com/author</URI>
        </URI>
</XRD>

The approach POWDER takes is to define constraints on URIs. In this
case, we've constrained the host and the scheme. Any resource on any
subdomain of example.com, on any port, is now in scope. You reduce the
scope by adding in further constraints.  You can also provide
alternatives in white space separated lists so that, for example, if you
wanted to allow http or https (but not other schemes) then you'd have:

<includeschemes>http https</includeschemes>

and so on.

Your example shows just how similar XRD and POWDER are. They have
different use cases and serve different audiences and I'm not, for a
moment, suggesting that one subsumes the other, but for the record, your
example could be written in POWDER as:

<powder>
   <attribution>
     <issuedby src="http://example.com/author" />
   </attribution>
   <dr>
     <iriset>
       <includeschemes>http</includeschemes>
       <includehosts>example.com</includehosts>
     </iriset>
     <descriptorset>
       <typeof src="http://example.org/type/blog" />
       <dcterms:creator src="http://example.com/author" />
     </descriptorset>
   <dr>
</powder>

This is a declaration by the author that s/he is the author of the blog
which comprises the entirety of example.com. As you can see, it's done
entirely in XML and can be processed as such. Semantic folk can also
process this and extract RDF triples about individual URIs on the
example.com host and if you run the transformation you can get an OWL
ontology out of this too - but that's all optional.

>
> What I don't want to do is use an exception such as 'if the URI begins with X, treat it as a rule and not a valid URI'...

Agreed, that would be awful.

Cheers

Phil.

>
>> -----Original Message-----
>> From: ashok malhotra [mailto:ashok.malhotra@...]
>> Sent: Saturday, June 27, 2009 6:08 PM
>> To: Eran Hammer-Lahav
>> Cc: apps-discuss@...; www-tag@...; URI
>> Subject: Re: URI for abstract concepts (domain, host, origin, site,
>> etc.)
>>
>> Hi Eran:
>> Trying to understand your proposal.
>> By 'abstract' do you mean URIs for which a representation cannot be
>> retrieved?
>> So, perhaps, a chair?
>>
>> My assumption was that for such resources you want to retrieve the
>> metadata.
>> To do that you do a GET which returns a 'Not Found' as well as a Link
>> Header.
>>
>> Of course, if you know syntactically that the resource does not have a
>> representation
>> you can save one access and go directly for the metadata.
>>
>> Is that where you are going?
>>
>> All the best, Ashok
>>
>>
>> Eran Hammer-Lahav wrote:
>>> LRDD [1] defines a way to link a descriptor (metadata, information
>> about, etc.) to a resource. It keeps the document format of the
>> descriptor out of scope, leaving it up to existing formats (XRDS, XRD,
>> POWDER, Metalink, etc.) and new format to address.
>>> Most of these descriptor formats include an element which indicates
>> what the document is about - the subject of the descriptor. XRD
>> includes the <Subject> element for this purpose with xs:anyURI as its
>> type. I believe POWDER uses RDF's 'about' attribute in a similar way
>> IIRC.
>>> We have some use cases in which the subject of the descriptor does
>> not have a URI available.
>>> LRDD uses a well-known-location document (/host-meta, soon to be
>> replaced with /.well-known/host-meta) to store information about the
>> abstract host resource (the combination of domain name and port number,
>> potentially also including protocol). Over the past few years, ad-hoc
>> protocols have been abusing the root resource URI to mean something
>> beyond just the root resource of a domain - basically as a placeholder
>> for information about the entire domain or host.
>>> The lack of URI for such concepts is preventing descriptor formats
>> from being used here because there is no valid URI available to insert
>> into the subject container. While no representation is expected for
>> such abstract concepts, within the context of descriptors, being able
>> to reference them is critical.
>>> The use case at hand is using XRD as the document format for host-
>> meta. Host-meta describes attributes of the host which by itself does
>> not currently have a URI. We need to figure out what to put in the
>> host-meta document's <Subject> element which has direct impact on the
>> trust profile and signature (but is outside the scope of this
>> discussion).
>>> So far I could only come up with two options:
>>>
>>> 1. Make a special case exception that when the subject is
>> http://______/.well-known/host-meta, it is treated differently than any
>> other URI in that it means the XRD is not about that URI (the host-meta
>> document itself), but about the abstract host resource located at
>> ______.
>>> 2. Define a new kind of URI that can be used for abstract entities
>> such as "host" or "domain", but which is not an http URI because that
>> will bring us right back to #1.
>>> I would like to ask for feedback on the idea of proposing a new URI
>> scheme or a new URN namespace for this purpose, something like
>> 'abstract'.
>>> It will look something like this (please focus on the idea, not the
>> syntax of the examples):
>>> urn:abstract:domain:example.com
>>> urn:abstract:host:example.com:8080
>>> urn:abstract:origin:example.com:8080:http
>>>
>>> or
>>>
>>> abstract://example.com/domain
>>> abstract://example.com:8080/host
>>> abstract://example.com:8080:http/origin
>>>
>>> Any comments, feedback, or concerns would be greatly appreciated.
>>>
>>> EHL
>>>
>>> [1] http://tools.ietf.org/html/draft-hammer-discovery
>>>
>>>
>>>
>>>
>
>

--

Phil Archer
http://philarcher.org/

i-sieve technologies                |      W3C Mobile Web Initiative
Beyond Impressions                  |      www.w3.org/Mobile

[Xiaoshu Wang]

Martin J. Dürst wrote:

> On 2009/06/29 0:02, Xiaoshu Wang wrote:
>  
>> Martin J. Dürst wrote:
>>    
>>> On 2009/06/27 3:36, Xiaoshu Wang wrote:
>>>
>>>      
>>>> Thus,
>>>>
>>>> "http://danbri.org/foaf.rdf#danbri" denotes a person.
>>>> "http://danbri.org/foaf.rdf#(application/rdf+xml)danbri" denotes an RDF
>>>> node.
>>>> "http://danbri.org/foaf.rdf#(application/xhtml+xml)danbri" denotes an
>>>> HTML element ided "danbri
>>>>        
>>> I don't understand this. Why wouldn't I just use
>>> http://danbri.org/foo.html#danbri
>>> or anything similar for HTML fragments? (I'm assuming that foaf.rdf
>>> returns an application/rdf+xml documend, and foo.html returns an
>>> application/xhtml+xml document; the extensions may be meaningless to
>>> the protocol but help to keep things apart for humans and computers.)
>>>      
>
>  
>> Well, then it just doesn't work for extending the referential range of
>> URI to denote things beyond engineering entities. If you take a URI
>> (fragment or not) to denote document (or its sub-structure), then the
>> Web is not much useful to our daily use. If you take a URI to denote
>> other things, like a human or person, then you cannot describe a
>> document structure. And there is one URI, then you have to make a
>> decision which one it denotes, right?
>>    
>
> Yes, each URI better denotes only one thing. But that doesn't mean that
> all URIs (with fragment identifiers) denote subdocuments, and it doesn't
> mean that all URIs (with fragment identifiers) denote 'other things'. It
> means that each individual URI denotes either one or the other, and that
> you find out which one (if you need to) by getting more information
> about it.
>  

Well, I don't know if we agree or disagree.   If you think that a URI
always denote a resource, and we can describe its representation with
additional property or b-node, then we completely agree.  But in this
case, if "http://danbri.org/foaf.rdf#danbri" is used to denote an HTML
element only because the URI's owner makes it so.  It does not denote an
HTML element just because you happened to receive an HTML document since
we can use non-HTML things, such as an RDF, to describe this HTML element.

But, on the other hand, if you think that a URI can be used to denote
both a resource and its representation, then, I don't know how it can
work.  For instance, if I deployed an HTML document (as a resource) at
"http://example.com/foo"and then you get a copy by dereference the URI.  
What does the URI denote? my copy or your copy? Of course, we can still
make this model work such as by defining some server-client vocabulary.  
But would it be important to standardize this "vocabulary" since it is
the built-in semantics of the Web architecture?

Xiaoshu

>>> Also, I don't see much of a need to denote an RDF node per se. I'm
>>> sure there are special applications one can come up with where
>>> reasoning about RDF nodes per se is helpful/necessary/whatever, but
>>> for such cases, there are other techniques available already. A single
>>> special property and blank nodes would do the job.
>>>      
>> Sure, we can use special property and blank nodes, but don't we need to
>> know a URI does first before applying a property to that right?
>>    
>
> People who 'apply properties' to URIs (which I assume you mean to add
> properties about an URI) will know an URI from other information or
> because they created the URI and decided what they want to use it for.
> People who see an URI for the first time have to find out what it stands
> for either from context or from dereferencing (or probably from both).
>
> Regards,   Martin.
>  

[David Booth-6]

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.

[Graham Klyne-4]

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

[Eran Hammer-Lahav]

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@...]
> Sent: Wednesday, July 01, 2009 7:08 AM
> To: Larry Masinter
> Cc: 'Jonathan Rees'; ashok.malhotra@...; Eran Hammer-Lahav;
> apps-discuss@...; www-tag@...; '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.

[Pat Hayes]

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@...]
>> Sent: Wednesday, July 01, 2009 7:08 AM
>> To: Larry Masinter
>> Cc: 'Jonathan Rees'; ashok.malhotra@...; Eran Hammer-Lahav;
>> apps-discuss@...; www-tag@...; '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.
>
>
>
>

------------------------------------------------------------
IHMC                                     [phone] or [phone]
40 South Alcaniz St.           [phone]   office
Pensacola                            [phone]   fax
FL 32502                              [phone]   mobile
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes

[Erik Wilde-3]

On Jul 2, 2009, at 15:06, Pat Hayes <phayes@...> 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.

[David Booth-6]

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@...]
> > Sent: Wednesday, July 01, 2009 7:08 AM
> > To: Larry Masinter
> > Cc: 'Jonathan Rees'; ashok.malhotra@...; Eran Hammer-Lahav;
> > apps-discuss@...; www-tag@...; '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.