[107] 本項で紹介するのは、 MIME型を更に細分化したものとしてのプロファイルを指定する 「profile」です。 Web Linking におけるリンク関係型として、 あるいは一部のMIME型の引数として使われています。

仕様書

意味

[90] プロファイルprofileは、資源の表現を処理するために使うことができる制約、 表記法convention、拡張、 その他元々の媒体型の意味semanticsを変えないような追加の意味です (変えてはなりません)。 >>86

[89] 例えば podcast 用のプロファイルの URL を profile リンクとして含めることで、クライアントはそのようなフィードを podcast のフィードとして普通とは違った形で処理できます。 >>86

[92] プロファイルは組み合わせて使うことができ、 その場合クライアントが対応しているプロファイルについてそれぞれの異なる処理規則に従い当該資源の表現を処理することができます。 >>86

[87] プロファイルは URI によって識別されます。これは名前空間URLのようにプロファイルを識別するものであり、 必ずしも参照を解ける資源でなくても構いません。クライアントはこれをリンクとしてではなく識別子として扱うべきです。 >>86

[93] Web Linking のリンク関係型として定義されているのに、リンクとして扱うなとはこれいかにwwww

[88] プロファイルの URL の参照を解くことによってプロファイルの人間可読または機械可読な説明の表現が得られるようになっていても構いません。 クライアントが未知のプロファイルの URL に遭遇するかもしれない状況では、 プロファイルの URL で有用な文書が得られるようにしておくべきです。 >>86

[123] JSON-LD では、プロファイル URLはdereference可能であるべきです >>120。

プロファイルと MIME 型

[94] 媒体型はその意味や表記を定義するものですが、しばしば拡張性を持っています。 プロファイルは媒体型の意味は変えずに追加の意味を定義するものです。 新しい媒体型とは違って、元の意味を全部変えてしまうわけではありません。 >>86

[95] 例えば XHTML は XML に対して新しい解釈を提供していて生 XML データを見せても意味が無いのでプロファイルではなく新しい媒体型です。 一方 hCard は HTML/XHTML の処理規則自体は変えずに追加の規則を定義しているので、 HTML/XHTML のプロファイルです。 >>86

[96] RFC 6906 自体も「媒体型とプロファイルの境界は必ずしも明確ではない」 >>86 と述べていますが、この例も必ずしも納得できるものではないように思えます。 hCard と同じ程度に XHTML も XML のプロファイルであると RFC 6906 の定義と何ら矛盾なく主張できそうです。

[91] プロファイルは複数の媒体型にまたがって定義されるものであっても構いません。 資源の複数の表現に共通してプロファイルを関連付けることもできます。 とはいえクライアントはプロファイルを資源の表現に関連付けられたものとして扱うべきです。 >>86

リンク関係型 profile (Web Linking)

[114] リンク関係型 profile は、対象資源がプロファイルであることを表します。

歴史

  • [76] draft-wilde-profile-link-01 - The \x27profile\x27 Link Relation Type ( ( 版)) http://tools.ietf.org/html/draft-wilde-profile-link-01

関連

[98] >>95, >>96 で RFC 6906 自体が示唆しているように、プロファイルの仕組みは XML MIME型に対する屋上屋のように思えます。 >>97 の提案は profile 引数そのものです。

  • [97] RFC 3023 - XML Media Types ( 版) http://tools.ietf.org/html/rfc3023#appendix-A.6
[99] XML MIME型というか構造化構文接尾辞も MIME型に対する屋上屋なので建て増しすぎwww

[140] また、提案されているように処理に大きく関わるものであるなら、 Link: の一種として定義するよりも、独自のヘッダーとして定義する方がより利用しやすく、 実装時の間違いも起こりにくいように思えます。実際に利用したい場面があって、 著者や実装者がどう利用するのか、どうすれば正しく利用されるのかを検討して設計したのではなく、 Web Linking の仕組みの中で理論上あれば良いと考えられる機能を定義してみた、 というような顛末なのではないかと疑いたくもなります。 (本当に需要があるのなら、 もっと反響も利用例・実装例もありそうなものです。)

profile 引数 (MIME 型)

文脈

[102] プロファイルが使えそうな媒体型を新しく定義する時は、 profile 引数を定義するべきです >>101。

[101] リンク型 profile のリンクは資源の表現に含まれるものなので、 その外側からは見えません。しかし profile 引数があれば、 Accept: ヘッダーによる内容折衝などで用いることができます。 >>100

[121] JSON-LD (application/ld+xml) はこの profile 引数を採用しています >>120。 この引数は省略可能です >>120。

[132] Collection+JSON (application/vnd.collection+json) もこの profile 引数を採用している模様です >>133。

構文

[104] profile 引数を定義する時は空白で区切ったプロファイルの URI のリストとするべきです。 >>100

[122] JSON-LD では、このリストは、空ではないものとされています >>120。

[105] >>104 の通りで細かい定義はありません。相対URLで良いのか、空白の種類は何かなどは決められていません。

関連

[103] profile 引数を使う表現であっても、 profile リンクは含めるべきです。これは、媒体型の引数は失われがちだからです。 >>100

プロファイル URL

[108] 実際のプロファイル URL は見つかっていません。

[109] RFC 6906 は hCard と Dublin Core の DC-HTML を紹介していますが、 どちらもリンク関係型 profile における意味のプロファイルを定義していないので、 現時点で使うことはできません (使い方がわかりません)。

[110] そもそも Web Linking を採用していない HTML でどのように使うのか不明です。 HTTP ヘッダーや HTML エントリーを含む Atom フィードで使うのでしょうか。

[111] RFC 6906 は iTunes の podcast の例も挙げていますが、 URL も含めすべてが例示に過ぎず、実際に使えるものではありません。

[112] 登録簿もなく好きな URL を使えるようですが、どこで誰が使っているのかわかりません。

[115] 2014年6月に発行された RFC 7284 は、 相互運用性のために有用である >>114 として、IANA登録簿 (>>127) を規定するものです。

[116] ただし適合性には言及していませんから、登録されていない URL を使うことが制限されているわけではありません。

[117] RFC 7284 は http://example.com/profiles/example を例示しています >>114 が、この URL 自体は IANA に登録されていません。 かわりになぜか urn:example:profile-uri を登録しています >>114。

[118] RFC 6906 で言及 (>>109) されていた DC-HTML の URL http://dublincore.org/documents/2008/08/04/dc-html/ が登録されています >>114。ただし DC-HTML は HTML の profile 属性の値を定義するもので、 Web Linking における用法は DC-HTML も RFC 7284 も規定していません。 しかも HTML の profile 属性は現行の HTML Standard では既に削除されていて、 DC-HTML はその後メンテナンスされていない、 既に実効性のない仕様です。このような値を登録したところで、 どのように使うつもりなのでしょうか (誰か使おうと思っている人はいるのでしょうか)。

[119] RFC 7284 は、更に、 JSON-LD >>120 を出典として3つの URL を登録しています >>114。

[131] Go About API — Go About 3.16.3 documentation ( 版) https://apidocs.goabout.com/ では、 http://profiles.goabout.com/ からはじまるプロファイル URL がいくつか定義されています。

[8] JSON-LD は、MIME型の引数の値として IRI を使えないため、 URI に変換する必要がある >>7 と述べています。普通プロファイル URL のように番地ではなく識別子として用いられる URL の場合、 不透明な文字列として扱うことになっています。 URI でない IRI だと意味が変わってしまう可能性が高いですが、なぜかそれには言及されていません。

歴史

profile 引数 (HTML、SMIL)

[23] XHTML の媒体型 application/xhtml+xml, SMIL の媒体型 application/smil+xml, application/smil で定義されている引数 profile は、名札付けされた実体が使用しているマーク付け言語のプロファイルを指定するものでした。

[42]

媒体型
application/xhtml+xml, application/smil+xml, application/smil
引数名
profile (profile (プロファイル) より)
引数値
URI
既定値
(プロファイル指定なし)
状態
IETF 情報提供 RFC

[41] 仕様書:

[43] この引数は、内容折衝で受信側の能力を示すために使う (例えば Accept: で使う) ことを想定しています。 特に、形式の変換を行う串が使うことを想定しています。 送信側が実体に名札付けするために使う (例えば Content-Type: で使う) ことは想定していません。 RFC 4536 5.

[45] profile 引数は、 CC/PP が使われるようになるまでのつなぎです。 RFC 4536 5.

[29] いくらつなぎ規格だからと言っても、提案している当の W3C の規格 (XHTML 1.0 とか 1.1 とか SMIL 2.0 とか SMIL Basic とか) の profile URI が規定されていないあたり、やる気がまったく感じられませぬ。

[46] CC/PP も失敗色が。。。

[80] WICD Full 1.0 ( ( 版)) http://www.w3.org/TR/WICDFull/#identification

[81] WICD Mobile 1.0 ( ( 版)) http://www.w3.org/TR/WICDMobile/#identification

[84] JSON-LD 1.0 ( ( 版)) http://www.w3.org/TR/json-ld/#application-ld-json

[85] draft-wilde-atom-profile-03 - Profile Support for the Atom Syndication Format ( ( 版)) http://tools.ietf.org/html/draft-wilde-atom-profile-03

  • [1] import new IANA considerations · 15eb97c · w3c/html ( 版) https://github.com/w3c/html/commit/15eb97cfc8b7fc97c2dcceaf92c748a2c1ae2e78

[2] >>1 で W3C HTML5 において application/xhtml+xml の profile 引数がなぜか非推奨ながら「復活」しています。

[3] しかし text/html の version や level は復活していませんし、なぜ profile だけが復活したのか謎です。[4] 現在の application/xhtml+xml の最新の定義と考えられる WHATWG HTML Standard には、 profile 引数は含まれていません。

例

[13] http://www.wapforum.org/xhtml : XHTML Mobile Profile (http://www.openmobilealliance.org/wapdocs/wap-277-xhtmlmp-20011029-a.pdf 7.2 参照)

[12] http://www.geocities.co.jp/Hollywood-Studio/8691/: http://math.oheya.to/dtd/geo/geo-html11.dtd の。

[44] 例 RFC 4536 5.

Accept: application/smil+xml;
   profile="http://www.w3.org/2001/SMIL20/HostLanguage"

JSON Schema

[139] JSON Schema は、 application/json とその subtype (+json のことか?) の profile 引数によってJSON SchemaのURLを指定するべきとしています >>138。

  • [138] JSON Schema: core definitions and terminology ( 版) http://json-schema.org/latest/json-schema-core.html#rfc.section.8.1

[134] JSON Reference は application/json; profile=http://json-schema.org/json-ref のような指定を使うべき >>135 と規定していましたが、 その後削除されています >>136。

[137] この profile 引数がどのように解釈されるのかはまったく説明されていませんでしたが、 同じ著者による >>139 とみられます。
  • [135] draft-pbryan-zyp-json-ref-02 - JSON Reference ( 版) http://tools.ietf.org/html/draft-pbryan-zyp-json-ref-02#section-6
  • [136] draft-pbryan-zyp-json-ref-03 - JSON Reference ( 版) http://tools.ietf.org/html/draft-pbryan-zyp-json-ref-03

関連

[106] MIME型に対する制約としてのプロファイルは、HTMLメタ情報プロファイルに関する head 要素の profile 属性と (一部の人達により半ば意図的に) 混用されました。一部の XHTML1 仕様書は、 head 要素の profile 属性を本項の意味に (曖昧に) 定義していまして、 application/xhtml+xml の profile 引数もそうなっています。 XHTML2 のリンク型 profile や Web Linking の一部として提案されていた Profile: ヘッダーも、そのような混用状態の延長線上にあるようです。

[141] codecs 特性とあわせて定義された profiles 特性とは、直接関係ありません。

メモ

[128] RFC-6906-Profiles - DCMI_MediaWiki ( ( 版)) http://wiki.dublincore.org/index.php/RFC-6906-Profiles

[129] The ‘profile’ Link Relation and You ( ( 版)) http://words.steveklabnik.com/the-profile-link-relation-and-you

[130] JSON API :: Extending ( ( 版)) http://jsonapi.org/extending/

[6] ALPS (application/alps+xml, application/alps+json) も同様な profile 引数を定義していますが、 RFC は参照していないようです。

[9] ALPS Mapping Guidelines for HTML ( 版) http://alps.io/spec/alps-to-html/

Responses can include the Link header[2] with the href value set to the URL of the ALPS profile document and the rel value set to "profile."

Link: http://alps.io/profiles/microblogging; rel="profile"

[10] Application-Level Profile Semantics (ALPS) ( 版) http://alps.io/spec/drafts/draft-01.html#rfc.section.4

profile

A whitespace-separated list of IRIs identifying specific constraints or conventions that apply to an ALPS document. A profile must not change the semantics of the resource representation when processed without profile knowledge, so that clients both with and without knowledge of a profiled resource can safely use the same representation. The profile parameter may also be used by clients to express their preferences in the content negotiation process. It is recommended that profile IRIs are dereferenceable and provide useful documentation at that IRI.

[14] TTML も同じような profile 引数を定義しています。 TTML 本体に ttp:profile なる概念があり、 それと同じと定義されています。値はやはり URL です。 (RFC は参照していません。) codecs 引数と用途が重なり、 可能な場合 codecs 引数を使うよう指示されています。

[16] 必須ではありません >>15。

[11] ( 版) https://zuuonline.com/

<link rel="profile" href="http://gmpg.org/xfn/11">

[17] TTML Media Type Definition and Profile Registry () https://www.w3.org/TR/2016/NOTE-ttml-profile-registry-20161006/

[18] TTML Media Type Definition and Profile Registry () https://www.w3.org/TR/2016/NOTE-ttml-profile-registry-20161009/

[19] () https://www.iana.org/assignments/media-types/application/gml+xml

"profile": If provided, this parameter indicates the GML profiles that the GML document conforms to. This is consistent with the semantics of a profile as laid out in RFC 6906.

The parameter can also be used to provide protocol-specific operations, such as profile-based content negotiation in HTTP.

A profile is identified by a URI.

As a GML document may conform to more than one GML profile, the parameter value is a whitespace-separated list of profile URIs.

Syntax:

profile = URI *( 1*WSP URI )

The element "URI" is defined by Section 3 of RFC 3986.

Profile URIs are assigned by the publisher of the GML profile. The URI should be in the "http" URI scheme and, if dereferenced, should return information about the GML profile.

For example, version 2.0 of the GML Simple Feature Level 0 profile specified by OGC is identified by the URI "http://www.opengis.net/def/profile/ogc/2.0/gml-sf0".

[20] Web Annotation Data Model () https://w3c.github.io/web-annotation/model/wd2/#h-serialization-of-the-model

The media type of this format is defined in Section 3 of the Annotation Protocol [annotation-protocol] as application/ld+json;profile="http://www.w3.org/ns/anno.jsonld".

[21] Web Annotation Protocol () https://w3c.github.io/web-annotation/protocol/wd/#h-annotation-retrieval

Servers must support the JSON-LD representation using the Web Annotation profile. These responses must have a Content-Type header with the application/ld+json media type, and it should have the Web Annotation profile IRI of http://www.w3.org/ns/anno.jsonld in the profile parameter.

[22] Web Annotation Protocol () https://w3c.github.io/web-annotation/protocol/wd/#h-annotation-retrieval

Servers may support different JSON-LD profiles. Content negotiation for different JSON-LD profiles is performed by adding a profile parameter to the JSON-LD media type in a space separated, quoted list as part of the Accept header.

[24] Embedding Web Annotations in HTML () https://w3c.github.io/web-annotation/serialization-html-note/#embed-json-ld

JSON-LD [json-ld] is the serialization format used in the Web Annotation Data Model [annotation-model]. HTML can accommodate this serialization format directly via the use of the HTML <script> element with its type attribute assigned the media type for a Web Annotation: application/ld+json;profile="http://www.w3.org/ns/anno.jsonld".

[25] Linked Data Notifications () https://linkedresearch.org/ldn/#test-sender-header-post-content-type-json-ld

the body of the POST request must contain the notification payload in JSON-LD with header Content-Type: application/ld+json. The Content-Type header may include a profile URI [RFC6906].

[26] Linked Data Notifications () https://linkedresearch.org/ldn/#notification-announce-annotation

Content-Type: application/ld+json;profile="https://www.w3.org/ns/activitystreams"

[27] Activity Streams 2.0 () https://w3c.github.io/activitystreams/core/#h-media-type

profile: The profile parameter for the application/activity+json media type allows one or more profile URIs to be specified. These profile URIs have the identifier semantics defined in [RFC6906]. The "profile" media type parameter must be quoted. It contains a non-empty list of space-separated URIs (the profile URIs).

profile-param = "profile=" profile-value

profile-value = <"> profile-URI 0*( 1*SP profile-URI ) <">

profile-URI = URI

The "URI" in the above grammar refers to the "URI" as defined in Section 3 of [RFC3986].

[28] Activity Streams 2.0 () https://w3c.github.io/activitystreams/core/#h-media-type

Because Activity Streams 2.0 can be considered a restricted profile of JSON-LD, Implementations should consider the `application/ld+json; profile="https://www.w3.org/ns/activitystreams"` media type as being equivalent to `application/activity+json`.

[30] Negotiating Profiles in HTTP () http://profilenegotiation.github.io/I-D-Accept--Schema/I-D-accept-schema

[31] Image API 2.1.1 — IIIF | International Image Interoperability Framework () http://iiif.io/api/image/2.1/#complete-response

The compliance level URI may also be given in the HTTP Link header (RFC5988) with the parameter rel="profile", and thus a complete header might look like:

Link: http://iiif.io/api/image/2/level1.json;rel="profile"

[32] ActivityPub () https://w3c.github.io/activitypub/#x6-client-to-server-interactions

MUST make an HTTP POST request to this URL with the Content-Type of application/ld+json; profile="https://www.w3.org/ns/activitystreams". Servers MAY interpret a Content-Type or Accept header of application/activity+json as equivalent to application/ld+json; profile="https://www.w3.org/ns/activitystreams" for client-to-server interactions.