URIs for media types

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

URIs for media types

Erik Wilde-3
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:[hidden email]  -  tel:+1-510-6432253 |
            | UC Berkeley  -  School of Information (ISchool) |
            | http://dret.net/netdret http://twitter.com/dret |

Reply | Threaded
Open this post in threaded view
|

Re: URIs for media types

Bjoern Hoehrmann
* 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:[hidden email] · 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/ 

Reply | Threaded
Open this post in threaded view
|

Re: URIs for media types

John Cowan-3
In reply to this post by Erik Wilde-3
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.              [hidden email]
                --Abdullah al-Hazred, Al-`Azif      http://www.ccil.org/~cowan

Reply | Threaded
Open this post in threaded view
|

Re: URIs for media types

Erik Wilde-3
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:[hidden email]  -  tel:+1-510-6432253 |
            | UC Berkeley  -  School of Information (ISchool) |
            | http://dret.net/netdret http://twitter.com/dret |

Reply | Threaded
Open this post in threaded view
|

Re: URIs for media types

Martin J. Dürst
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
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.)

Regards,   Martin.

--
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: URIs for media types

Erik Wilde-3
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,

erik wilde | mailto:[hidden email]  -  tel:+1-510-6432253 |
            | UC Berkeley  -  School of Information (ISchool) |
            | http://dret.net/netdret http://twitter.com/dret |

Reply | Threaded
Open this post in threaded view
|

Re: URIs for media types

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

I think Martin might be overstating the case.  Yes, W3C has sometimes
had challenges hosting pages whose URIs are used by software (especially
before our sysadmins started using HAProxy), but that doesn't mean we
don't want to do it.    Sometimes it's worth it; these days the decision
has to be made on a case-by-case basis.   I suspect we'd be happy to
host media-type URIs, especially if there was some plan for what content
would be usefully served.

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

    -- Sandro



Reply | Threaded
Open this post in threaded view
|

Re: URIs for media types

Erik Wilde-3
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:[hidden email]  -  tel:+1-510-6432253 |
            | UC Berkeley  -  School of Information (ISchool) |
            | http://dret.net/netdret http://twitter.com/dret |

Reply | Threaded
Open this post in threaded view
|

Re: URIs for media types

Mark Baker
In reply to this post by John Cowan-3
On Tue, Mar 8, 2011 at 7:33 PM, John Cowan <[hidden email]> 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.