Re: Media Type Sub-Sub-types?

On 5 Apr 2010, at 23:55, Larry Masinter wrote:

> An "Internet Media Type" is more than a definition of syntax --

Well yes, as I understand it, and I still need to read your paper, 
a mime type specifies a syntax - and of course it's associated 
semantics. There is no point having a syntax without semantics, or
sending documents that are just defined syntactically.

But in RDF the semantics is pretty much fully defined, and one can express
everything with it.

In one way, what the mime type is specifying is the language, in the sense
defined by David Lewis in Lanugage and Languages: namely a mapping from syntax
into meaning.

> it's is an indication of intent, by the sender, for how the sender
> wishes the receiver to interpret the content being sent.

Only insofar as it hints to the syntax/semantics combo of the document.

I would not call that "an indication of intent", because I don't think
one should tie meaning to intention. It is better to keep these separate.

There is something that one may very well want to add concerning "indication of meaning",
and that would be the equivalent of speech acts - perhaps we should call that 
document acts . IE: is the document serious, a joke, is it binding, a caricature,
an insinuation....

Notice that in natural languages when makes a joke, he is not speaking
a different language. He is speaking the same language, but his attitude
to the proposition is different.

I'll have to read the articles below, sorry for intervening before reading...

Henry

> 
> While it's desirable, alas it is not supported:
> The space of "Internet Media Types" does not provide sufficient
> granularity for many applications that want to use the accept:
> header to control negotiation. 
> 
> But the types available do not partition the space of 
> syntax and semantics. 
> 
> One of the sources of analysis for thinking about file types
> and file formats is the archival community.
> 
> http://hul.harvard.edu/ois/digpres/guidance.html
> 
> In addition, there is the IETF work on "media features":
> http://tools.ietf.org/html/rfc2912
> http://tools.ietf.org/html/rfc2506
> http://tools.ietf.org/html/rfc2938 
> 
> which was intended to provide additional information about
> the file format other than the Internet Media Type.
> 
> I think part of the advice I'd like to include are things
> that Internet Media Types (MIME types) *aren't* good for,
> even though people have tried or might think it is desirable.
> 
> http://en.wikipedia.org/wiki/Internet_media_type
> 
> 
> RTP and SIP have extended MIME types in ways that don't
> exactly match MIME for email, but so has the web.
> 
> Larry
> 
> 
> -----Original Message-----
> From: Xiaoshu Wang [mailto:xiao@renci.org] 
> Sent: Monday, April 05, 2010 2:09 PM
> To: Story Henry
> Cc: nathan@webr3.org; Larry Masinter; www-tag@w3.org
> Subject: Re: Media Type Sub-Sub-types?
> 
> On 4/5/10 2:44 PM, Story Henry wrote:
>> On 5 Apr 2010, at 01:07, Nathan wrote:
>> 
>> 
>>> For instance, if the need for an ****+rdf media type scenario came
>>> about, then the specification / media type could determine a fixed
>>> serialization, as in only n3 not rdf/xml or other.
>>> 
>> 
>> This is really the wrong way to do things. Media types should not determine
>> what the content of what you are going to get back is about, only
>> what the syntax is.
>> 
> This is not true. A document should have two types -- one is syntax and 
> the other semantic. (Syntax is also deal with semantic as everything 
> else in the world but it deals with the structural semantics as opposed 
> to domain semantics).
> 
> I work in the life science domain. And often there are more than one 
> markup languages of the same syntax, e.g., in XML. The same data thus 
> can be expressed in more than one way. And since the domain semantics of 
> these markup languages are overlapping but subsuming each other, we face 
> a dilemma of how to serve them. To give each ML a URI faces the question 
> of how to linked them together. Even with the same markup languages, we 
> faced the problem how to serve different version of data under the same 
> URI. Using content negotiation helps solve these problem. But without a 
> document-type definition, it does work as well. Also, giving the type 
> definition a URI makes it further linked. I have discussed the issue at 
> http://wot.renci.org/tr/doc_uri.
> 
> I used to define the document type as an extension to the current type. 
> Similar to Jan's proposal of using profile but using a different token. 
> However, I find it that I can not use that convention to serve with 
> straight-forward Apache's var file. The convention that I used is
> 
> mime/type/semantic-type.
> 
> Thus, in Jan's case, it would be as follows:
> 
> application/http://xmlns.com/foaf/0.1/
> 
> 
>> The way the atom people are working on creating a mime type for every
>> application is crazy. There are an infinite number of things one can speak about. Should we have an infinite number of mime types? Clearly not.
>> 
>> The better way to do things is to have do it through links. So when you have
>> 
>> :joe foaf:knows :jack .
>> 
>> The the document in which :jack is defined is clearly going to be some form of personal profile document.... At least you should find more info about jack.
>> 
> Well, I don't think that is good enough. If I am a JavaScript engine, 
> what should I get once I got to foaf:knows? I don't read RDF, only JSON. 
> Even if I can read JSON, that does not mean that I know how to 
> meaningfully processes all JSON's constructs that are out there, right?
> 
> Xiaoshu
> 
> 
>

Received on Monday, 5 April 2010 23:24:11 UTC