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

[Larry Masinter]

# They aren't being treated differently. The normal syntax for naming  
# something in RDF is a URI reference with a fragid attached. The use of  
# a fragID cancels any assumptions that the URIreference denotes  
something connected with the HTTP protocol.

How does it do that?

# This is how RDF manages to  
# refer to galaxies, chemical elements, people, etc..

Sounds like this is only in the context of RDF.

Larry
--
http://larry.masinter.net

[Dan Brickley-2]

On 26/6/09 18:54, Larry Masinter wrote:

> # They aren't being treated differently. The normal syntax for naming
> # something in RDF is a URI reference with a fragid attached. The use of
> # a fragID cancels any assumptions that the URIreference denotes
> something connected with the HTTP protocol.
>
> How does it do that?
>
> # This is how RDF manages to
> # refer to galaxies, chemical elements, people, etc..
>
> Sounds like this is only in the context of RDF.

Yes and no.


Here's the "Yes": the idea is that if content is served as
application/rdf+xml then the meaning of #foo is delegated to the
relevant spec (http://www.w3.org/2001/sw/RDFCore/mediatype-registration 
? humm that's expired). The RDF mediatype doc says

"""Section 4.1 of the URI specification [6] notes that the semantics
    of a fragment identifier (part of a URI after a "#") is a property of
    the data resulting from a retrieval action, and that the format and
    interpretation of fragment identifiers is dependent on the media type
    of the retrieval result.

    However, in RDF, the thing identified by a URI with fragment
    identifier does not bear any particular relationship to the thing
    identified by the URI alone.  This differs from some readings of the
    URI specification [6], so attention is recommended when creating new
    RDF terms which use fragment identifiers."""

Here the "No": A URI that points to an RDF document constructed in this
fashion, is (according to those persuaded this story works) supposed to
be a URI for whatever galaxy, chemical element, person etc. the RDF is
structured to represent.

In this way, http://danbri.org/foaf.rdf#danbri is a URI for me. Not just
for RDF applications, but for any applications that care about the idea
of URIs being URIs *for* things. The media-type registration that makes
this so RDF-specific (RDF/XML-specific even) but the URI is supposed to
be a URI for me, full stop, rather than "a URI for me, in RDF applications".

At this point people normally bring up the possibility of clashes across
content-negotiated representations served at the same URI. The usual
answer offered by return is "if that hurts, don't do it".

Dan

[Xiaoshu Wang]

Dan Brickley wrote:

> On 26/6/09 18:54, Larry Masinter wrote:
>  
>> # They aren't being treated differently. The normal syntax for naming
>> # something in RDF is a URI reference with a fragid attached. The use of
>> # a fragID cancels any assumptions that the URIreference denotes
>> something connected with the HTTP protocol.
>>
>> How does it do that?
>>
>> # This is how RDF manages to
>> # refer to galaxies, chemical elements, people, etc..
>>
>> Sounds like this is only in the context of RDF.
>>    
>
> Yes and no.
>
>
> Here's the "Yes": the idea is that if content is served as
> application/rdf+xml then the meaning of #foo is delegated to the
> relevant spec (http://www.w3.org/2001/sw/RDFCore/mediatype-registration 
> ? humm that's expired). The RDF mediatype doc says
>
> """Section 4.1 of the URI specification [6] notes that the semantics
>     of a fragment identifier (part of a URI after a "#") is a property of
>     the data resulting from a retrieval action, and that the format and
>     interpretation of fragment identifiers is dependent on the media type
>     of the retrieval result.
>
>     However, in RDF, the thing identified by a URI with fragment
>     identifier does not bear any particular relationship to the thing
>     identified by the URI alone.  This differs from some readings of the
>     URI specification [6], so attention is recommended when creating new
>     RDF terms which use fragment identifiers."""
>
> Here the "No": A URI that points to an RDF document constructed in this
> fashion, is (according to those persuaded this story works) supposed to
> be a URI for whatever galaxy, chemical element, person etc. the RDF is
> structured to represent.
>
> In this way, http://danbri.org/foaf.rdf#danbri is a URI for me. Not just
> for RDF applications, but for any applications that care about the idea
> of URIs being URIs *for* things. The media-type registration that makes
> this so RDF-specific (RDF/XML-specific even) but the URI is supposed to
> be a URI for me, full stop, rather than "a URI for me, in RDF applications".
>  

I don't think an RDF node is determined by the fragment identifier but
rather by the entire URI.  The case for other mime-types are different.

Hence, all RDF parsers have, in fact, not using the intended meaning of
a URI by a URI owner as it is defined because I do not think they can
manipulate a person.  What they can manipulate is an RDF node with that
person's name.  This is an ambiguity issue that has not been brought
into light because of the implicit context.  But once someone intends to
describe the inner working of an RDF parser, I think the issue is bound
to show up.
> At this point people normally bring up the possibility of clashes across
> content-negotiated representations served at the same URI. The usual
> answer offered by return is "if that hurts, don't do it".
>  
There should not be.  I have trying this many times.  A URI, fragmented
or not, denotes one thing and its returned representations another.  The
former is the content of the later.  The remedy is to define a URI
syntax for representation.

A syntax that I have proposed is to insert a (mime-type) after the # sign.

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

When a URI owner uses content negotiation, they should make the content
of each representation consistent.  Of course, there could be
inconsistencies if a user is not careful.  But it is no different from
the case when someonelse makes an inconsistent statement about
"http://danbri.org/foaf.rdf#danbri".  Inconsistent resources (whether it
is caused by the same root-URI owner or not) will simply not be used
(i.e., linked) by others, hence eventually die of isolation.

This is the same old story from the httpRange-14.  Once we straighten
that out, all other problems are very easy to answer.

Xiaoshu

[ray denenberg]

From: "Pat Hayes" <phayes@...>
>  The use of  
> a fragID cancels any assumptions that the URIreference denotes  
> something connected with the HTTP protocol.

What about:
http://www.w3.org/XML/#intro 

Is that not connected with the http protocol?

[Pat Hayes]

On Jun 26, 2009, at 11:54 AM, Larry Masinter wrote:

> # They aren't being treated differently. The normal syntax for naming
> # something in RDF is a URI reference with a fragid attached. The  
> use of
> # a fragID cancels any assumptions that the URIreference denotes
> something connected with the HTTP protocol.
>
> How does it do that?

http-range-14, as I understand it.

>
> # This is how RDF manages to
> # refer to galaxies, chemical elements, people, etc..
>
> Sounds like this is only in the context of RDF.

Well, true, fragids have a different meaning in HTML. But this rule  
seems to work smoothly throughout the SWeb formalisms, which are all  
the referential uses of URIrefs on the Web.

Pat

>
> Larry
> --
> http://larry.masinter.net
>
>
>
>
>

------------------------------------------------------------
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

[Pat Hayes]

On Jun 26, 2009, at 1:44 PM, Ray Denenberg, Library of Congress wrote:

> From: "Pat Hayes" <phayes@...>
>> The use of  a fragID cancels any assumptions that the URIreference  
>> denotes  something connected with the HTTP protocol.
>
> What about:
> http://www.w3.org/XML/#intro
> Is that not connected with the http protocol?

Sure, but I said *denotes*. Using the http URIref to do an HTTP GET is  
not using it to denote (name) anything.

Pat

>
>
>
>
>
>

------------------------------------------------------------
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

[John Cowan]

Pat Hayes scripsit:

> >What about:
> >http://www.w3.org/XML/#intro
> >Is that not connected with the http protocol?
>
> Sure, but I said *denotes*. Using the http URIref to do an HTTP GET is  
> not using it to denote (name) anything.

And (which is the point), fragids are not transmitted in the HTTP protocol.

--
                Si hoc legere scis, nimium eruditionis habes.

[Felix Sasaki-2]

2009/6/26 John Cowan <cowan@...>

Pat Hayes scripsit:

> >What about:
> >http://www.w3.org/XML/#intro
> >Is that not connected with the http protocol?
>
> Sure, but I said *denotes*. Using the http URIref to do an HTTP GET is
> not using it to denote (name) anything.

And (which is the point), fragids are not transmitted in the HTTP protocol.

though they might be transformed into something which actually is transported, e.g. a time range header, see
http://www.w3.org/TR/2009/WD-media-frags-reqs-20090430/#media-fragment-retrieving

Felix

 

--
               Si hoc legere scis, nimium eruditionis habes.

[Dan Brickley-2]

On 26/6/09 20:36, Xiaoshu Wang wrote:

> The remedy is to define a URI syntax
> for representation.
> A syntax that I have proposed is to insert a (mime-type) after the # sign.
>
> 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
>
> When a URI owner uses content negotiation, they should make the content
> of each representation consistent. Of course, there could be
> inconsistencies if a user is not careful. But it is no different from
> the case when someonelse makes an inconsistent statement about
> "http://danbri.org/foaf.rdf#danbri".

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...

Dan

[Erik Wilde-3]

hello.

Xiaoshu Wang wrote:

> There should not be.  I have trying this many times.  A URI, fragmented
> or not, denotes one thing and its returned representations another.  The
> former is the content of the later.  The remedy is to define a URI
> syntax for representation.
> A syntax that I have proposed is to insert a (mime-type) after the # sign.
> 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

interesting. would that be specific for http-identified resources? if
not, how would that be supposed to work with URI schemes that do not
share HTTP's capabilities for transferring content metadata, and
performing content negotiation? a simple example might be FTP, which is
similar in nature to HTTP (access to hierarchically organized resources)
but has no concept of media types.

another thing i am wondering about: aren't fragment identifiers as they
are currently defined client-side only and specific to the media type
anyway? that might indicate you are talking not about extending the URI
syntax, but that of HTTP URI fragment identifiers? there were other
approaches of doing this (with other goals), one of the issues was how
to create some framework for fragment identifiers that would be
uniformly applied to all fragment identifier syntaxes. that one never
got anywhere, and the window of opportunity is probably closed by now.
but there the idea was that instead of labeling fragments with the media
type to which they should be applied (which seems to be what you're
suggesting), they should follow some base syntax, and thus could be
designed to be less brittle across media types. HTTP's idea of content
negotiation (and thus dynamic media type assignment at access time) and
URI fragment identifiers and their media type specificity always was one
of the areas where web architecture certainly could need a bit of
improvment.

cheers,

erik wilde   tel:[phone] - fax:[phone]
        dret@...  -  http://dret.net/netdret
        UC Berkeley - School of Information (ISchool)

[Xiaoshu Wang]

Erik Wilde wrote:

> hello.
>
> Xiaoshu Wang wrote:
>  
>> There should not be.  I have trying this many times.  A URI, fragmented
>> or not, denotes one thing and its returned representations another.  The
>> former is the content of the later.  The remedy is to define a URI
>> syntax for representation.
>> A syntax that I have proposed is to insert a (mime-type) after the # sign.
>> 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
>>    
>
> interesting. would that be specific for http-identified resources? if
> not, how would that be supposed to work with URI schemes that do not
> share HTTP's capabilities for transferring content metadata, and
> performing content negotiation? a simple example might be FTP, which is
> similar in nature to HTTP (access to hierarchically organized resources)
> but has no concept of media types.
>  

I don't think a URI scheme has to do anything with transportation
protocol.  No matter what URI you use, after de-reference, you get a
*representation*, which is a different thing from the *resource* that
the URI denotes.  And a representation must have a content type,
regardless how you retrieved it.
> another thing i am wondering about: aren't fragment identifiers as they
> are currently defined client-side only and specific to the media type
> anyway? that might indicate you are talking not about extending the URI
> syntax, but that of HTTP URI fragment identifiers?
See the above answer.
> there were other
> approaches of doing this (with other goals), one of the issues was how
> to create some framework for fragment identifiers that would be
> uniformly applied to all fragment identifier syntaxes.
I am not sure what is the purpose for that -- a standard syntax for
fragment identifier?  It is just a name, right? What I am proposing is
to make a syntactic notation on URI syntax so that we will no longer be
pondered by the question of what a URI denote.

> that one never
> got anywhere, and the window of opportunity is probably closed by now.
> but there the idea was that instead of labeling fragments with the media
> type to which they should be applied (which seems to be what you're
> suggesting), they should follow some base syntax, and thus could be
> designed to be less brittle across media types. HTTP's idea of content
> negotiation (and thus dynamic media type assignment at access time) and
> URI fragment identifiers and their media type specificity always was one
> of the areas where web architecture certainly could need a bit of
> improvment.
>  

Content negotiation does not cause the problem.  It only makes the
problem obvious.  The Web is based on three fundamental entities: URI,
Resource, Representation.  But currently, the referential range of the
URI only covers resource but URI and Representation.  What I have
proposed in my manuscript to ISWC 2009 is as follows.

1. If a URI's root is ended with a "~", it denotes the URI sans the "~".
2. Insert (mime-type) after # to denote a particular type of
representation retrieved from a URI.
3. If a URI's root is ended with a "?", it denotes the list of all
mime-types supported by the root URI.

With #1, we can built a URI that is composed of any numbers of URI but
yet still maintain a level of curtness because the mapping can be
described in a representation and can be retrieved.  This will  solve
most, if not all, problems raised in XSD use cases.

The reason for #2 is for httpRange-14 that has hunted us for 7+ years.
As a side note to Dan, I think mime-type should be formulated in URI
just like any other resource.  I have detailed my reasoning from my
manuscript.  One of the use case is that I have one resource but there
are two available XML schema, which overlaps but neither one consumes
the other.  With the current media-type specification, it forces me to
choose one, which is not what the best for me and for my potential
clients.  Also, there are other advantages of extending mime-type to
URI.  For instance, in principle, a client can "follow the nose" to
retrieve something and parse a novel format.

The #3 is in essence a transparent content negotiation.  But modeling it
as a kind of resource allows all kind of formats be used to describe the
list.  Also, at the most fundamental level, a mime-type is  semantically
equivalent to a service, so the #3 can be considered to be a default
standard mechanism for service discovery. This thus essentially solves
all the so-called "uniform access to metadata" problem.

This  URI pattern (TIP, I called it a pattern for now since it is not a
in URI spec) + The And Pattern (TAP i.e., to supply a resource with one
mime-type And another And another via content negotiation), gives us
both diversity (in presentation) and uniformness (in organization and
therefore discovery).  Personally, I think that is all we need at the
most basic architectural level of the Web.

Xiaoshu

[Erik Wilde-3]

hello.

> I don't think a URI scheme has to do anything with transportation
> protocol.

the URI scheme specifies the protocol that has to be used the resource.
how can that have nothing to do with the protocol?

> No matter what URI you use, after de-reference, you get a
> *representation*, which is a different thing from the *resource* that
> the URI denotes.  And a representation must have a content type,
> regardless how you retrieved it.

that's HTTP and HTTPS, but probably not many other protocols. if you use
mailto: or tel: or fax: or sms:, then there are other modes of
interaction with the identified resource, and for those interactions
there is no concept of a media type. and even for ftp:, there is no
media type info; you can guess, but there is no protocol mechanism that
supports it. so it really seems to me you're focusing on HTTP URIs which
is fine; i just wanted to find out.

cheers,

erik wilde   tel:[phone] - fax:[phone]
        dret@...  -  http://dret.net/netdret
        UC Berkeley - School of Information (ISchool)

[Ashok Malhotra]

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
>
>
>
>  

[Xiaoshu Wang]

Erik Wilde wrote:

> hello.
>
>  
>> I don't think a URI scheme has to do anything with transportation
>> protocol.
>>    
>
> the URI scheme specifies the protocol that has to be used the resource.
> how can that have nothing to do with the protocol?
>  

Oh, I mean what a URI denotes has nothing to do with how you obtain the
representation.

Besides, I do believe that we need *one* URN.  My position is, however,
different from other URN proposal in that: I think we need *only one*
URN but *many* URL. And the syntax that I have in mind for this URN to
be schemeless.

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.

Second, it solves existing issue.  For instance, the identity of an HTTP
and an HTTPS URI is always hard to define with the current URI spec.  In
my proposal,

"//danbri.org/foaf.rdf#danbri" would denote Dan Brickley the person. But
"http://danbri.org/foaf.rdf#danbri" would denote an information path to  
Dan.  Obviously, what Dan is should be independent of how his
information is obtained.  This also explain the fragment identifier
semantics, it is just another information path (traversed after the
first path).

Third, with the schemeless URN defined, there will be no longer any
issue about if we need a new URI scheme.  The answer is changed to an
easy answer one, do we need a new URL. And this in fact will encourage
the development of new transportation protocol, which will make the Web
evolve gracefully with the stable set of URN.  Also, we can take the
concept of the Web to real life too.  For instance, it is thus possible
to "snailmail://danbri.org/foaf.rdf#danbri" a post-card, where snailmail
is a transportation protocol implemented by a postal office.

Of course, there is one important issue:  Given a URN, how can a user
know which protocol it should use?

My suggestion is to let them not be defined technically, but be run as a
common human knowledge. To use the Web, knowing HTTP is the most
popularly supported transportation protocol is like knowing the "ABC" in
order to use a language. Thus, when someone is given a URN, s/he should
know that (at the current time) s/e should try it with the "http"
protocol.  And, from resource provider's point of view, we can take the
"http" service as our bootstrap protocol., from which we can use content
negotiation to either redirect or inform some other kind of protocol
that it may support.  I think this scheme-URN + the completion of the
URI syntax would establish a very solid foundation for the Web.  At
least, it solves most of the architectural issues of the Web that I know of.
 

>> No matter what URI you use, after de-reference, you get a
>> *representation*, which is a different thing from the *resource* that
>> the URI denotes.  And a representation must have a content type,
>> regardless how you retrieved it.
>>    
>
> that's HTTP and HTTPS, but probably not many other protocols. if you use
> mailto: or tel: or fax: or sms:, then there are other modes of
> interaction with the identified resource, and for those interactions
> there is no concept of a media type. and even for ftp:, there is no
> media type info; you can guess, but there is no protocol mechanism that
> supports it. so it really seems to me you're focusing on HTTP URIs which
> is fine; i just wanted to find out.
>  

Of course, there isn't a name for these *reprentations* yet. But that
does not mean they are not typed.  Whatever kind of message that each of
these protocol they use, the structure of the message must be specified
somewhere, which in essence makes them a media type, right?

Xiaoshu
> cheers,
>
> erik wilde   tel:[phone] - fax:[phone]
>         dret@...  -  http://dret.net/netdret
>         UC Berkeley - School of Information (ISchool)
>  

["Martin J. Dürst"]

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.)

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.

Regards,   Martin.

> When a URI owner uses content negotiation, they should make the content
> of each representation consistent. Of course, there could be
> inconsistencies if a user is not careful. But it is no different from
> the case when someonelse makes an inconsistent statement about
> "http://danbri.org/foaf.rdf#danbri". Inconsistent resources (whether it
> is caused by the same root-URI owner or not) will simply not be used
> (i.e., linked) by others, hence eventually die of isolation.
> This is the same old story from the httpRange-14. Once we straighten
> that out, all other problems are very easy to answer.
>
> Xiaoshu
>
>
>
>

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

[Xiaoshu Wang]

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?
> 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?


Xiaoshu

> Regards,   Martin.
>
>
>  
>> When a URI owner uses content negotiation, they should make the content
>> of each representation consistent. Of course, there could be
>> inconsistencies if a user is not careful. But it is no different from
>> the case when someonelse makes an inconsistent statement about
>> "http://danbri.org/foaf.rdf#danbri". Inconsistent resources (whether it
>> is caused by the same root-URI owner or not) will simply not be used
>> (i.e., linked) by others, hence eventually die of isolation.
>> This is the same old story from the httpRange-14. Once we straighten
>> that out, all other problems are very easy to answer.
>>
>> Xiaoshu
>>
>>
>>
>>
>>    
>
>  

[Jonathan Rees-3]

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

This is why it's nice that Eran calls the description resource a
"description resource" instead of a "metadata resource". 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

[Ashok Malhotra]

See inline
All the best, Ashok


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
>  

[AM]  Picky, picky :-)
> This is why it's nice that Eran calls the description resource a
> "description resource" instead of a "metadata resource". 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.
>  
[AM] Yes, description resource is better,
> 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.
>  
[AM] I wrote the note mainly to make sure I understood Eran's usecase,
Your suggestion has merit.  Let's see what he says.
> -Jonathan
>
>  

[Larry Masinter]

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

which would neatly allow using descriptions of
abstract concepts to identify the abstract concept.
(Syntactically, the date can be left out without
ambiguity.)


Would this be helpful, at least for illustrative purposes?

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.

tdb:data:,the%20host%20larry.masinter.net

might be a simple inline way of talking about the
'host' named 'larry.masinter.net'.

Larry
--
http://larry.masinter.net
 

-----Original Message-----
From: www-tag-request@... [mailto:www-tag-request@...] On Behalf Of Jonathan Rees
Sent: Sunday, June 28, 2009 9:43 AM
To: ashok.malhotra@...
Cc: Eran Hammer-Lahav; apps-discuss@...; www-tag@...; URI
Subject: Re: URI for abstract concepts (domain, host, origin, site, etc.)

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

This is why it's nice that Eran calls the description resource a
"description resource" instead of a "metadata resource". 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

[Eran Hammer-Lahav]

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
> >
> >
> >
> >