Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

schema:nameの属性 #423

Open
tankarup opened this issue Apr 24, 2021 · 10 comments
Open

schema:nameの属性 #423

tankarup opened this issue Apr 24, 2021 · 10 comments

Comments

@tankarup
Copy link
Contributor

schema:nameに付けられている属性ですが、ユニットの場合はrdf:datatypeが使われています。
例:<schema:name rdf:datatype="http://www.w3.org/2001/XMLSchema#string">灼熱少女</schema:name>
一方、アイドルの場合はxml:langが使われています。
例:<schema:name xml:lang="ja">櫻木真乃</schema:name>

どちらの属性を使うのか、基準を教えていただけませんでしょうか。

デフォルトはrdf:datatypeで、多国語化した場合にxml:langに変更するのでしょうか?

(ユニット「プリンセススターズ」に"Princess Stars"を追加することを想定しています。)

@foooomio
Copy link
Member

#250 と一緒にやっていくのがいいんじゃないかと思います。

@crssnky
Copy link
Member

crssnky commented Apr 27, 2021

如月千早は明らかな日本語だということは分かります(実は中国語かもしれないけど、それはないはず...)

一方ユニット名は、造語も多くあります。
L'Anticaって何語なんでしょう...
そういったことを考えたくない + ユニットのリソースで統一したい = 全部stringにしよう
といった経緯があります。

とはいえ、 #250 をやっていった後であれば、schema:nameは様々な言語が入り混じっても良いかもしれませんね

@tankarup
Copy link
Contributor Author

みなさま、ありがとうございます。

いただいたご意見を合わせて考えますと、

・基本はrdf:datatypeでよい
・多言語化する場合はxml:langを使用する。
・言語不明の場合はrdf:datatypeを使う。
schema:nameが複数存在する場合は、rdfs:labelを追加する。

という指針でよろしいでしょうか。

いくつか事例を考えてみました。xml:langを使う場合は、公式媒体の表記を尊重することが重要であるように感じました。

例:プリンセススターズ

<rdfs:label rdf:datatype="http://www.w3.org/2001/XMLSchema#string">プリンセススターズ</rdfs:label>
<schema:name xml:lang="ja">プリンセススターズ</schema:name>
<schema:name xml:lang="en">Princess Stars</schema:name> <!--CDなどで英語表記あり-->
<imas:nameKana xml:lang="ja">ぷりんせすすたーず</imas:nameKana>

例:アスタリスク

<rdfs:label rdf:datatype="http://www.w3.org/2001/XMLSchema#string">*(Asterisk)</rdfs:label>
<schema:name rdf:datatype="http://www.w3.org/2001/XMLSchema#string">*</schema:name>
<schema:name xml:lang="en">Asterisk</schema:name>
<!-- <schema:name xml:lang="ja">アスタリスク</schema:name> かな表記している公式媒体はありましたっけ…? -->
<imas:nameKana xml:lang="ja">あすたりすく</imas:nameKana>

例:TIntMe!

<rdfs:label rdf:datatype="http://www.w3.org/2001/XMLSchema#string">TIntMe!</rdfs:label>
<schema:name rdf:datatype="http://www.w3.org/2001/XMLSchema#string">TIntMe!</schema:name>
<!-- <schema:name xml:lang="en">TIntMe!</schema:name> 英語とは言えない-->
<!-- <schema:name xml:lang="ja">ティントミー!</schema:name> 日本語表記はしないとおもう -->
<imas:nameKana xml:lang="ja">てぃんとみー</imas:nameKana> <!-- 読み方として表記するのはあり -->

事例に違和感がありましたらコメントいただければと思います。

@tankarup
Copy link
Contributor Author

また作業を進めることになった場合、
(a) 現在のschema:nameをrdfs:labelに一括変換したあとに、個別でschema:name, imas:nameKanaの追加をおこなう
(b) 現在のschema:nameをrdfs:labelとして一括追加したあとに、個別でschema:name, imas:nameKanaの追加・修正をおこなう
(c) 個別でrdfs:label, schema:name, imas:nameKanaの追加・修正をおこなう
のいずれが適切でしょうか?

(c)であれば私個人でもちまちまと作業できますが、(a)(b)の場合は影響が大きそうなので私では手を出しづらいです。

@foooomio
Copy link
Member

良くないです。

同じ述語に複数の rdf:datatype を混ぜると SPARQL で問い合わせるのが難しくなります。 rdfs:label には xsd:stringschema:name には rdf:langString のようにそれぞれ統一したほうが良いです。

それと rdf:datatypexml:lang を同列に扱われているように聞こえるのですが、これは概念が別です。同列になるのは xsd:stringrdf:langString であって、それぞれ rdf:datatype の一種です。 xml:lang を付与すると自動的に rdf:datatyperdf:langString に解釈されます。

説明が難しいですが、 @crssnky さんのこの記事がわかりやすかったので一度ご覧になってください(参考資料をググってたら偶然出てきた)。

RDFまたはSPARQLの問題点・疑問に関するポエム - crssnkyの。

@tankarup
Copy link
Contributor Author

分かりやすく解説いただきありがとうございます。@crssnky さんの記事も拝見させていただきました。勉強が必要だなぁと再認識いたしました。

同じ述語に複数の rdf:datatype を混ぜると SPARQL で問い合わせるのが難しくなります。

なるほど。検索時にどのような影響が出るのかといった知識がありませんでした。ありがとうございます。

rdf:datatype と xml:lang を同列に扱われているように聞こえるのですが、

ご指摘の通り同じ位置づけで認識しておりました。失礼しました。

あらためて、"プリンセススターズ"に英語名として"Princess Stars"を追加するケースを考えますと、

・全てのユニットデータに対し、<schema:name rdf:datatype=xsd:string><schema:name rdf:datatype=rdf:langString xml:lang=*>に変更することが必要
・ただし言語が特定できない造語名称(TIntMe!, *など)は<schema:name rdf:datatype=rdf:langString xml:lang=*>に入れることができない問題が残る。

との認識でよろしかったでしょうか。

その場合、schema:alternateNameにPrincess Starsを入れるのが問題が少ないのでしょうか。

@foooomio
Copy link
Member

はい、その認識で問題ございません。

schema:alternateName が現実的な解決策かもしれませんね。 @crssnky さんのおっしゃる通り、言語で分類できないユニット名もありますし、言語がわかったとしても "L'Antica"@it などとするのはちょっと違う気がします。

ちなみに、拙作の https://mltd.pikopikopla.net ではどうしていたかなと思って確認したら、 schema:alternateNamexsd:string を突っ込んでいました。

https://github.com/foooomio/pikopikoplanet/blob/bf6d9c4168f213941e8047d75f72ee199ed55dbb/dataset/unit.ttl#L663-L665

(話が脱線しますが、上記で RDF の記述に用いているのが Turtle です。RDF を記述する構文は複数あって、im@sparql では RDF/XML が使われていますが、Turtle は比較的コンパクトで読み書きしやすいフォーマットとして勧告されています。)

@banjun
Copy link
Member

banjun commented Apr 28, 2021

#250 との関連について,結局SPARQLでどうマッチさせられるかというのと組み合わせの課題な気はするので,既存クエリを気にしながら,時には破壊しながら,というのを考えなきゃいけないかもですね。

(b) 現在のschema:nameをrdfs:labelとして一括追加したあとに、個別でschema:name, imas:nameKanaの追加・修正をおこなう

これは比較的安全な印象もありますがどうでしょう。分解すると:

「schema:nameをrdfs:labelとして一括追加」 (imas:Unitを対象として)

  • ラベルを使う限り,言語タグを書かずに1個特定検索できるようになる (SPARQLで言語タグを書いてないからマッチしないんだっけ??という試行錯誤がないのがメリット)
  • ラベルとして「ユニークな名称」を付けるのに迷わないか?
    • 現状のschema:nameがその意図で1個だけ入っているはず(?)だから心配することはなくコピペでいけるともいえる?

(上の)あとに、個別でschema:name の追加・修正をおこなう

  • 既に話されているように,言語タグを付けると,タグ付けただけなのに,元のxsd:stringとはSPARQLのリテラルマッチで互換ではなくなるので,破壊的変更になりそう。もしやるとしたらそれまでにみんなラベルに移行できるか?
    • 破壊的とはいえ「schema:name には rdf:langString」と決まっているほうがクエリ書きやすいのはたしか
  • schema:alternateNameで入れていくのは比較的安全にできそう
    • 現状でもschema:alternateNameは,1個特定するためというより,検索でより広くマッチさせるために使われている気がする? つまりSPARQLでもリテラルマッチじゃなくて,変数にとってstr(),filter()される系なのでは・・・?という推測
  • このへんの,nameかalternateNameか,それぞれ言語タグありかなしか,に選択肢があるので決め手に欠ける...

(上の)あとに、個別でimas:nameKana の追加・修正をおこなう

  • ここは単なる述語と値の追加なので,いつやっても安全にみえる
  • nameKanaあったら欲しい(気持ち)
    • けど当初の「(ユニット「プリンセススターズ」に"Princess Stars"を追加することを想定しています。)」の話とは別か

@crssnky
Copy link
Member

crssnky commented Apr 29, 2021

banjunさん、分解ありがとうございます。 その方法が今の所ベストかと思います。

ここは単なる述語と値の追加なので,いつやっても安全にみえる

の通り、 「schema:nameをrdfs:labelとして一括追加」 (imas:Unitを対象として) の後にやっていくのが良いでしょう。
ユニットに関する別issueとして #421 があるのですが、それも↑の後が良さそうですね。
(リソース分割の際は、rdfs:labelの追加を忘れずに!)

@tankarup
Copy link
Contributor Author

皆さま、ありがとうございます。
imas:nameKanaの追加を検討していましたが、rdfs:labelの追加(およびリソースの分割も?)を待ってから実施したいと思います。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants