headers
Erik Wilde | 9 Mar 2011 00:39
Picon
Favicon
Gravatar

URIs for media types

hello.

this may be the wrong list to ask, but i cannot think of a better one. 
if anybody happens to know a more appropriate list, please let me know!

it seems that in various places, people tried to have URIs for IANA 
media types and since there are none, and the registry's HTML does not 
provide individual web pages for each type, they either give up, or 
create proxies (such as http://purl.org/NET/mediatypes) with 
questionable authority and unknown update procedures. i think there 
would be quite some value to associate every IANA registered media type 
with an IANA-hosted URI, which might be as simple as containing the link 
to the registration request (in the same way as the current lists). i'd 
be willing to write an RFC for that, but it only would make sense if the 
IANA then would actually change the current registry to server useful 
documents at these URIs. does anybody have any idea how something like 
this could be accomplished?

thanks a lot and kind regards,

erik wilde | mailto:dret <at> berkeley.edu  -  tel:+1-510-6432253 |
            | UC Berkeley  -  School of Information (ISchool) |
            | http://dret.net/netdret http://twitter.com/dret |
Permalink | Reply | 8 comments |
headers
Bjoern Hoehrmann | 9 Mar 2011 01:14
Picon

Re: URIs for media types

* Erik Wilde wrote:
>it seems that in various places, people tried to have URIs for IANA 
>media types and since there are none, and the registry's HTML does not 
>provide individual web pages for each type, they either give up, or 
>create proxies (such as http://purl.org/NET/mediatypes) with 
>questionable authority and unknown update procedures. i think there 
>would be quite some value to associate every IANA registered media type 
>with an IANA-hosted URI, which might be as simple as containing the link 
>to the registration request (in the same way as the current lists). i'd 
>be willing to write an RFC for that, but it only would make sense if the 
>IANA then would actually change the current registry to server useful 
>documents at these URIs. does anybody have any idea how something like 
>this could be accomplished?

You should http://www.w3.org/2001/tag/issues.html#uriMediaType-9 have a
look at previous efforts in this area. If you ask, I think the registry
should go back to have all the entries in one document and then you can
easily use #example/example fragment identifiers for your purposes. As
for useful information, who would be creating those useful documents?
--

-- 
Björn Höhrmann · mailto:bjoern <at> hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Permalink | Reply | 0 comments |
headers
John Cowan | 9 Mar 2011 01:33

Re: URIs for media types

Erik Wilde scripsit:

> it seems that in various places, people tried to have URIs for IANA  
> media types and since there are none, and the registry's HTML does not  
> provide individual web pages for each type, they either give up, or  
> create proxies (such as http://purl.org/NET/mediatypes) with  
> questionable authority and unknown update procedures. i think there  
> would be quite some value to associate every IANA registered media type  
> with an IANA-hosted URI, which might be as simple as containing the link  
> to the registration request (in the same way as the current lists). i'd  
> be willing to write an RFC for that, but it only would make sense if the  
> IANA then would actually change the current registry to server useful  
> documents at these URIs. does anybody have any idea how something like  
> this could be accomplished?

Well, it's already the case that many such documents are served at
http://www.iana.org/assignments/media-types/TYPE/SUBTYPE.  For example,
http://www.iana.org/assignments/media-types/application/msword
already retrieves a document describing Microsoft Word files, and
http://www.iana.org/assignments/media-types/image/png works too, though
http://www.iana.org/assignments/media-types/application/octet-stream
does not.

So I'd go with URIs of that form, and just live with the fact that not
all of them resolve to descriptive documents, as XML folks live with
the fact that not all namespace URIs do.

--

-- 
La mayyitan ma qadirun yatabaqqa sarmadi                            John Cowan
Fa idha yaji' al-shudhdhadh fa-l-maut qad yantahi.              cowan <at> ccil.org
(Continue reading)

Permalink | Reply | 6 comments |
headers
Erik Wilde | 9 Mar 2011 01:40
Picon
Favicon
Gravatar

Re: URIs for media types

hello john.

> So I'd go with URIs of that form, and just live with the fact that not
> all of them resolve to descriptive documents, as XML folks live with
> the fact that not all namespace URIs do.

reading some of the old discussions of the TAG i want to stress that i 
was not suggesting that the IANA should promise to always have a web 
server running that serves RDF or some other machine-readable format. 
what i am suggesting is merely to have a little add-on to the media type 
registration process that makes it safe to assume that if two parties 
use URIs to identify media types (for example because they want to mix 
IANA's media type vocabulary with another one and want to mix them in a 
safe way), then there is one well-defined way how to identify an IANA 
media type by URI. it may be as simple as saying, as you propose: "go 
ahead everybody and use 
http://www.iana.org/assignments/media-types/TYPE/SUBTYPE, and we will do 
our best to even have a web server there serving 
[HTML|XML|JSON|RDF|SKOS]." i think there's quite a bit of value in 
officially declaring this, and the effort required seems fairly low.

cheers,

dret.

--

-- 
erik wilde | mailto:dret <at> berkeley.edu  -  tel:+1-510-6432253 |
            | UC Berkeley  -  School of Information (ISchool) |
            | http://dret.net/netdret http://twitter.com/dret |
(Continue reading)

Permalink | Reply | 4 comments |
headers
Martin J. Dürst | 9 Mar 2011 08:58
Picon
Gravatar

Re: URIs for media types

Hello Erik,

On 2011/03/09 9:40, Erik Wilde wrote:
> hello john.
>
>> So I'd go with URIs of that form, and just live with the fact that not
>> all of them resolve to descriptive documents, as XML folks live with
>> the fact that not all namespace URIs do.
>
> reading some of the old discussions of the TAG i want to stress that i
> was not suggesting that the IANA should promise to always have a web
> server running that serves RDF or some other machine-readable format.
> what i am suggesting is merely to have a little add-on to the media type
> registration process that makes it safe to assume that if two parties
> use URIs to identify media types (for example because they want to mix
> IANA's media type vocabulary with another one and want to mix them in a
> safe way), then there is one well-defined way how to identify an IANA
> media type by URI. it may be as simple as saying, as you propose: "go
> ahead everybody and use
> http://www.iana.org/assignments/media-types/TYPE/SUBTYPE, and we will do
> our best to even have a web server there serving
> [HTML|XML|JSON|RDF|SKOS]." i think there's quite a bit of value in
> officially declaring this, and the effort required seems fairly low.

I agree that for areas such as the Semantic Web, it's worthwhile. I also 
agree that the effort required may be rather low (for us) if you 
volunteer to do it.

I would note that there is currently somewhat less enthusiasm for having 
such URIs at (potentially) servable/served locations, because of the
(Continue reading)

Permalink | Reply | 3 comments |
headers
Erik Wilde | 9 Mar 2011 21:11
Picon
Favicon
Gravatar

Re: URIs for media types

hello.

On 2011-03-08 23:58, "Martin J. Dürst" wrote:
> I agree that for areas such as the Semantic Web, it's worthwhile. I also
> agree that the effort required may be rather low (for us) if you
> volunteer to do it.

i don't think it's in any way specific to the semantic web. in fact, 
that would be the application area requiring most constraints, because 
there you would probably want the URIs to resolve (working HTTP URIs), 
and you'd like to get some RDF, maybe based on SKOS. URI-based 
identification is relevant for any web-targeted design, and using URIs 
is just more scalable and robust than creating a separate namespace with 
its own syntax.

> I would note that there is currently somewhat less enthusiasm for having
> such URIs at (potentially) servable/served locations, because of the
> recurring tough experiences that W3C has had with unintended but
> clueless DOS attacks on their HTML DTDs. (See e.g.
> http://www.w3.org/blog/systeam/2008/02/08/w3c_s_excessive_dtd_traffic.)

very good point, and a very good link to illustrate the problem. i'd be 
perfectly fine to establish non-HTTP URIs to avoid that problem, and the 
info: URI scheme or others could be chosen to do this. the proposed URIs 
would not serve the purpose of actionable links (it simply might be 
helpful if you could paste them into the address bar and actually GET 
something), they would just be well-defined identifiers in the web's 
namespace: the URI space.

thanks and cheers,
(Continue reading)

Permalink | Reply | 2 comments |
headers
Sandro Hawke | 9 Mar 2011 21:34
Picon
Favicon
Gravatar

Re: URIs for media types

On Wed, 2011-03-09 at 12:11 -0800, Erik Wilde wrote:
> hello.
> 
> On 2011-03-08 23:58, "Martin J. Dürst" wrote:
> > I agree that for areas such as the Semantic Web, it's worthwhile. I also
> > agree that the effort required may be rather low (for us) if you
> > volunteer to do it.
> 
> i don't think it's in any way specific to the semantic web. in fact, 
> that would be the application area requiring most constraints, because 
> there you would probably want the URIs to resolve (working HTTP URIs), 
> and you'd like to get some RDF, maybe based on SKOS. URI-based 
> identification is relevant for any web-targeted design, and using URIs 
> is just more scalable and robust than creating a separate namespace with 
> its own syntax.
> 
> > I would note that there is currently somewhat less enthusiasm for having
> > such URIs at (potentially) servable/served locations, because of the
> > recurring tough experiences that W3C has had with unintended but
> > clueless DOS attacks on their HTML DTDs. (See e.g.
> > http://www.w3.org/blog/systeam/2008/02/08/w3c_s_excessive_dtd_traffic.)
> 
> very good point, and a very good link to illustrate the problem. i'd be 
> perfectly fine to establish non-HTTP URIs to avoid that problem, and the 
> info: URI scheme or others could be chosen to do this. the proposed URIs 
> would not serve the purpose of actionable links (it simply might be 
> helpful if you could paste them into the address bar and actually GET 
> something), they would just be well-defined identifiers in the web's 
> namespace: the URI space.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Erik Wilde | 9 Mar 2011 22:05
Picon
Favicon
Gravatar

Re: URIs for media types

hello.

On 2011-03-09 12:34, Sandro Hawke wrote:
> (From what I hear elsewhere in this discussion, it looks like there's no
> need for W3C to do this, but I wanted to clear up the impression that
> hosting this kind of stuff is too dangerous.)

thanks for your clarification, sandro. and yes, i think the URIs should 
be iana.org URIs and not w3.org URIs (if HTTP URIs are chosen), and i 
have no idea whether IANA did have similar issues with their server 
infrastructure so far. i am sure all of this can be done in a way that 
works. since the URIs would be intended as identifiers and not really as 
links to interact with, the server load would be an unintended byproduct 
anyway. but it's good to know that it can be handled without an 
excessive amount of effort.

thanks and kind regards,

dret.

--
erik wilde | mailto:dret <at> berkeley.edu  -  tel:+1-510-6432253 |
            | UC Berkeley  -  School of Information (ISchool) |
            | http://dret.net/netdret http://twitter.com/dret |
Permalink | Reply | 0 comments |
headers
Mark Baker | 10 Mar 2011 02:34
Picon
Favicon
Gravatar

Re: URIs for media types

On Tue, Mar 8, 2011 at 7:33 PM, John Cowan <cowan <at> mercury.ccil.org> wrote:
> Well, it's already the case that many such documents are served at
> http://www.iana.org/assignments/media-types/TYPE/SUBTYPE.  For example,
> http://www.iana.org/assignments/media-types/application/msword
> already retrieves a document describing Microsoft Word files, and
> http://www.iana.org/assignments/media-types/image/png works too, though
> http://www.iana.org/assignments/media-types/application/octet-stream
> does not.
>
> So I'd go with URIs of that form, and just live with the fact that not
> all of them resolve to descriptive documents, as XML folks live with
> the fact that not all namespace URIs do.

Whether the URIs resolve or not isn't as big an issue as whether IANA
has reserved them, i.e. committed to not assigning them alternate
meanings in the future.

Mark.
Permalink | Reply | 0 comments |
headers
Evain, Jean-Pierre | 10 Mar 2011 14:34
Picon
Favicon

RE: [urn] fragment identifiers

Hello there,

One of the most recent activity in this domain is http://www.w3.org/2008/WebVideo/Fragments/ 

Cheers, Jean-Pierre

-----Original Message-----
From: uri-request <at> w3.org [mailto:uri-request <at> w3.org] On Behalf Of Juha Hakala
Sent: jeudi, 10. mars 2011 13:29
To: "Martin J. Dürst"
Cc: Peter Saint-Andre; uri <at> w3.org; urn <at> ietf.org
Subject: Re: [urn] fragment identifiers

Hello Martin; all,

A few comments below.

Martin J. Dürst wrote:
> Hello Peter,
> 
> I have cross-posted to the URI list, because I think it's important to 
> get input from more experts. People on the URI list, this is about what 
> to do (or not to do) about fragment identifiers in URNs, raised in the 
> context of an update of RFC 2141.

For the URN community this issue is important because there are 
initiatives which are eager to use fragment identifiers. I have heard 
rumours that some are already using them. A typical use case would be a 
very complex data such as structured research data set within which many 
kinds of data should be separately described, identified and retrieved.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane