Re: Media Type Sub-Sub-types?

On 4/5/10 6:55 PM, Larry Masinter wrote:
> An "Internet Media Type" is more than a definition of syntax --
> it's is an indication of intent, by the sender, for how the sender
> wishes the receiver to interpret the content being sent.
>    
Exactly. The document type is exactly to define a intent. To convey a 
specific topic of message (document type) in a specific syntax (or 
language if we will).

I am not aware all the other documents that you mentioned. I will find 
time to read it up.

Best,

Xiaoshu
> 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 Tuesday, 6 April 2010 00:29:30 UTC