#1 - 2016-1-30 03:31
BinotaLIU (Vir', virino. Oni distingas ni en la du tipoj.)
目前维基人们对于一些如日期、数字之类的写法似乎未规范化,
想讨论一下:
1. 以后应该强制规范化吗?
2. 建议使用怎么样的格式呢?

3. 若维基人应该遵守相同的规范,那先前不符规范的条目如何处理呢?

目前我看到的几个未规范化的栏位:
1. 日期
 目前日期的部分动画似乎大部分采用「YYYY年MM月DD日」这样的格式,
 书籍从亚马逊抓取默认用的格式是「YYYY-MM-DD」,
 动画的 ep 其实系统的格式也是「YYYY-MM-DD」。

 另外人物条目看起来也没有统一的写法,
 有的是「M月D日」有的是「MM月DD日」。

 这个部分是否应该要有统一的标准?

2. ISBN 的写法
 日亚抽来的书都是用 10 位的 ISBN,不带空格与「-」,
 有些手工建立的条目是使用 13 位的,- 摆放的位置也未统一

3. 数字的小数点与分节符
 其实我觉得这个挺猎奇的 (bgm38)
 看范例,这五个例子描述的是相同的数字:
  Type 1: 123,456.789
  Type 2: 123 456.789
  Type 3: 123456.789
  Type 4: 123 456,789
  Type 5: 123456,789

4. 金额的货币单位标识
 由于 Bangumi 的收录范围是全宇宙世界的 ACGN 作品,
 难免会出现来自不同地区的货品,采用不同货币贩售。
 对于货币单位的写法是否应该规范?
 如「123¥CNY」或「123¥JPY」之类的?
 其实我不是很熟现有的对于货币的国际标准……

我是建议这几样应该规范化,
如日期应该要同亚马逊抽来的跟 ep 的写法一致,
ISBN 如果是日本书籍建议用 10 位,一律不加 - 与空格。
数字的话则不输入分节符,小数点用句号。
一旦规范化了之后,如果用户习惯使用的格式跟规范的不同,
Bangumi 的系统也能更好地帮他做转换。
至于货币单位我不知道该怎么写 (bgm38)

虽然我好像也没写过多少条目就是了
有任何意见都欢迎提出来讨论
#2 - 2016-1-30 03:33
(17年小结→bgm.tv/blog/278928)
1.无所谓
2.与亚马逊统一比较好
3.……这啥
4.无所谓
#2-1 - 2016-1-30 03:37
BinotaLIU
数字格式,请参考 @solairef 提到的这个条目中的价格写的是「29,99」

其实我问的还有两个问题啊(bgm38)「应该强制规范化吗?」
#2-2 - 2016-1-30 03:38
mizudiwood
BinotaLiu 说: 数字格式,请参考 @solairef 提到的这个条目中的价格写的是「29,99」

其实我问的还有两个问题啊「应该强制规范化吗?」
不应该因为太麻烦
#2-3 - 2016-1-30 09:36
Detao
BinotaLiu 说: 数字格式,请参考 @solairef 提到的这个条目中的价格写的是「29,99」

其实我问的还有两个问题啊「应该强制规范化吗?」
这是写错了吧(bgm38)
话说你找到的那几个范例都是在 Bangumi 上现有例子的吗?居然会这么乱(bgm38)
#3 - 2016-1-30 04:02
(电波不合半句多)
日期部分我是支持和放送日期一样统一成YYYY-MM-DD的,只是人物的生日有一个问题。
比如说今天1月30日,bgm.tv/mono页面能显示的“今日生日角色/人物”有以下几种情况:
①年份具体的YYYY-MM-DD,如巡音ルカ2009-01-30
②年份标为问号的YYYY-MM-DD,如水無灯里????-01-30
③YYYY年M/MM月D/DD日,如吉良吉影1966年1月30日
④无年份的M月D日,如愛宕絹惠1月30日

如果年份未知的生日写成MM-DD,这种情况是不会出现在“今日生日”里的,我发现这点之前一直都这么写……所以后来不知道年份的就尽量写成④了。
为什么不写成②?因为看着别扭啊!
#4 - 2016-1-30 04:32
(V1046-R MAHORO)
标准是应该有,至少给以后的条目定个指引

至于老的我觉得就没必要去手动一一改了,以后如果有一点(we can dream)开放API直接用机器人批量修改即可。

日期个人倾向于YYYY-MM-DD或者YYYY年M月D日,后者是感觉既然都写成中文模式了占位0没有什么意义也不规范。
#4-1 - 2016-1-30 16:32
BinotaLIU
如果你有編寫過維基百科的話,
維基百科是有一些 bot 在自動維護條目的,
針對一些問題 bot 會自動做修正
#4-2 - 2016-1-30 16:53
烈之斩
BinotaLiu 说: 如果你有編寫過維基百科的話,
維基百科是有一些 bot 在自動維護條目的,
針對一些問題 bot 會自動做修正
维基我当然知道,当年也玩过蛮久

不过现在再去用bot去批量修复其实也没太大必要,应该直接走类似Wikidata的路线才更适合bangumi这种数据网站。现有的资料可以参考Semantic wiki的方式增加后台的鲁棒性直接自动提取出数据(再统一格式显示)。

其实这种问题也算是当年建站之初采用所谓维基式的弊端吧,优点是添加内容灵活许多不局限于固定的输入框,缺点就在于输入的数据完全不规范了。

但是吊诡之处在于现在的后台模式其实完全没有利用到维基的优点:并没有灵活多少,无非是一个可以加行的infobox而已,连内链“[[]]”的功能其实都相当于没有,还需要手动用关联功能来添加……
#4-3 - 2016-1-30 17:03
林卯
烈之斩 说: 维基我当然知道,当年也玩过蛮久

不过现在再去用bot去批量修复其实也没太大必要,应该直接走类似Wikidata的路线才更适合bangumi这种数据网站。现有的资料可以参考Semantic wiki的...
真巧,我很久以前提过bgm更适合维基数据。

我感觉,维基其实并没有专门的infobox实现,我研究infobox发觉就是表格和模板的混合,不过是维基数据的垫脚石。有维基数据可以不必手动编辑infobox了。bgm只是浮于表面地抄infobox写法而已。
#5 - 2016-1-30 06:09
(抚君金错刀,怜君夺锦才)
部署个自然语言parser这些都不是事儿。(笑)
#6 - 2016-1-30 07:28
(困…)
ISBN 应该全用 13 位的,10 位的是旧标准。
#6-1 - 2016-1-30 16:34
BinotaLIU
然而目前日亞是用 10 位的
#6-2 - 2016-1-30 17:37
Detao
BinotaLiu 说: 然而目前日亞是用 10 位的
这是 Bangumi 抓取的锅吧,日亚两个都提供的。
话说本来就是可以转换的(bgm38)
#7 - 2016-1-30 07:47
这些不规范确实逼死强迫症,
日期是X/X/X还是X-X-X还是X年X月X日?
ISBN用哪个位的加不加-?
价格百位加不加(删不删)逗号分割?
售价人民币和日元都是¥是不是看到上千就自动理解为日元?
还有标签的大小写相同字母只跟随第一个建标签的出现的"ios"之流.
哦,对了,之前一直在"信息去重",也就是把相同字段的关联字段和文字字段统一,繁简不对(中日混写)或人名有空格或会社名日英一起用之类的的合并成关联字段,今天发现终于关联字段和文字字段大小写不一样也可以识别吻合了,去年提这个问题的时候对此都不敢期待,略欣慰.
真规范化也做不到规范化,毕竟维基人基本没有审核,即使有审核,在这建条目说实话和二次元的其他行为一个性质,全靠爱.有爱的多帮别人的懒惰补充下,把自己受不了的特别不规范的条目改改.
想指望管理层大改这些,不现实,也没必要.太麻烦了,每一个建条目改条目的人都觉得麻烦,并且提高不了多少条目的可读性,信息也还是那些信息.
只能说想想就好,这东西在网站运营初期没有建起来一个严厉的规则,发展起来后用户氛围上感觉不容易改变了.我很难想象Bangumi规范化日期写法会是个什么样子,但实际操作上也就是全站日期相关的字段正则表达式替换到确定下来的标准写法就是了.
虽然我看标签里的ios怎么看怎么别扭,但要是有人要我不是做什么商用文案的时候必须得iOS我也觉得蛋疼.小细节上的规范,目前不怎么适合Bangumi,以后再说吧,.
#7-1 - 2016-1-30 16:33
BinotaLIU
編輯條目時右邊提示個標準格式就好了啊
#7-2 - 2016-1-30 16:46
NX
BinotaLiu 说: 編輯條目時右邊提示個標準格式就好了啊
提示没用的,比格式规范更重要的内容规范都不那么规范.我同意#10的只能靠系统强制力.比如日期字段标准是 X-X-X 的话,自动把所有日期字段的 年月日和/转为-,这就是程序员的事了.
#7-3 - 2016-1-30 16:48
BinotaLIU
NeedXuyao(id: needxuyao) 说: 提示没用的,比格式规范更重要的内容规范都不那么规范.我同意#10的只能靠系统强制力.比如日期字段标准是 X-X-X 的话,自动把所有日期字段的 年月日和/转为-,这就是程序员的事了.
恩我的意思就是頁面上有提示 + 用 bot 修正
#7-4 - 2016-1-30 17:06
林卯
BinotaLiu 说: 恩我的意思就是頁面上有提示 + 用 bot 修正
但不能限制太死,比方说某个作品里描述角色的单位制都是虚构的,没法格式化。我说的就是刀语。还有繁多的角色性别…
#7-5 - 2016-1-30 17:11
BinotaLIU
林卯(id: laoism) 说: 但不能限制太死,比方说某个作品里描述角色的单位制都是虚构的,没法格式化。我说的就是刀语。还有繁多的角色性别…
主要是日期跟 ISBN 這類能完全修改成規範化的
#7-6 - 2016-1-30 17:20
林卯
BinotaLiu 说: 主要是日期跟 ISBN 這類能完全修改成規範化的
嗯,角色页面和人物页面的区别。
#8 - 2016-1-30 11:15
(この身はそなたの“剣”──そう誓ったはずだ。 ... . ...)
基本是老生常谈 楼主也不是不了解
想起两个事情
轨迹系列的角色生日 例如
http://bgm.tv/character/11779
http://bgm.tv/character/11785
这两个会被匹配到11月4日
日亚的东西是含税的 税率随时间推移而有所不同 所以不同时期抽出来的价格也会有不同
#9 - 2016-1-30 11:30
(✨️VIP 8✨️)
规范化是必须的,不是“无所谓”的,最低要求是能被机器读取。生日乱填导致不出现在今日生日里的不是没有。

题外话,我曾经在6年前提议过区别出人民币符号,4年前制作了我提议的符号:http://www.typeisbeautiful.com/2010/07/2795/
#10 - 2016-1-30 11:54
(✨️VIP 8✨️)
老生常谈了,系统不提供强制力没什么意义,谁闲得没事天天编辑战这些,楼上填的♂、♀我都当没看见。(bgm13)
#10-1 - 2016-1-30 16:34
BinotaLIU
我是想說用 bot 可以實現(
#10-2 - 2016-1-30 17:17
林卯
BinotaLiu 说: 我是想說用 bot 可以實現(
我现在做条目都在考虑为未来的维基数据(如果有)打基础,比如别名译源、p站ID、丰富性别这种bgm还没有的东西,有些是普通用户看不到的,比如你得点编辑才能看到我写的译源。

你愿意开发一个bot演示下吗。
#10-3 - 2016-1-30 17:29
若卡
BinotaLiu 说: 我是想說用 bot 可以實現(
只会变成bot大战的(
#11 - 2016-1-30 13:39
(其实世上本没有资源帝,伸手伸得多了,也便成了资源帝 ... ...)
(bgm38)已建条目的修改会麻烦到爆炸
#12 - 2016-1-30 13:57
(孤独的观测爷)
不知道类似日期的部分做成月日年分别填空的模式在技术上会不会很难?
#12-1 - 2016-1-30 16:35
BinotaLIU
似乎沒辦法,
畢竟 infobox 各字段沒有包含自己的型別
#13 - 2016-1-30 15:05
动画条目日期改为「YYYY-MM-DD」从统一规范的角度来说有必要,如果有脚本能够批量执行是最好,没有的话手动修改就太麻烦了
#14 - 2016-1-30 16:48
(Q, ∑, δ, q0, F)
参考ISO或者RFC如何?
#15 - 2016-2-1 01:35
(疯狂掉san)
日期墙裂支持统一格式…因为wiki的很多功能都与日期有关,比如按日期排列什么的
最终统一成什么格式,要看是怎么识别的了…
#15-1 - 2016-3-17 17:12
波菇
日期排列只有精确到日的才能按日期先后顺序,不过倒不限制格式都能识别。就是很多都是精确到月份的就排序不了
#16 - 2016-4-20 05:55
(讓一切都自動化!)
有沒有人想過

<input type="date" name="release date"/>

?(參考資料
#16-1 - 2016-4-20 18:23
林卯
有可有不可。比如可能某些角色的生日是用虚构的历法。但像放送日期之类应该可以。
#16-2 - 2016-4-20 19:51
BinotaLIU
林卯(id: laoism) 说: 有可有不可。比如可能某些角色的生日是用虚构的历法。但像放送日期之类应该可以。
date type 好像還沒有在大部分瀏覽器上實作吧?
#16-3 - 2016-4-20 20:11
林卯
BinotaLIU 说: date type 好像還沒有在大部分瀏覽器上實作吧?
这个我并不懂,但我想起多年前在某些站填写生日时不能自己填数字而必须从弹出日历里选,认为这可以实现。虽然不是层主这个方式。
#16-4 - 2016-4-21 05:40
Franklin Yu
林卯 说: 有可有不可。比如可能某些角色的生日是用虚构的历法。但像放送日期之类应该可以。
我說的僅限於「放送日期」、「遊戲發行日期」等等現實世界中的日期,並不包括設定中的日期。
#16-5 - 2016-4-21 05:40
Franklin Yu
BinotaLIU 说: date type 好像還沒有在大部分瀏覽器上實作吧?
IE(Edge)和 FF…… Chrome 和 Safari 都有了,你可以看右邊有寫
#17 - 2016-4-21 16:55
(誰說大學很易讀!)
還有既刊問題
如果數字行先,漫畫的冊數就會標記了那個數字的卷數,有可能有人會以為已經完結了。
#18 - 2018-8-3 02:33
挖一铲,关于前辈认为“ISBN如果是日本书籍建议用10位”这点,我有一些意见:

1. ISO在2007年1月正式采用了13位的ISBN新标准替代10位的旧标准,所以才有了ISBN-10和ISBN-13之分。2007年1月之后发行的图书在供应链中都应使用ISBN-13,而在2007年前发行并且此后也继续发行的图书也应该改用ISBN-13。参见:
https://zh.wikipedia.org/wiki/%E ... 6%E4%B9%A6%E5%8F%B7
https://www.iso.org/obp/ui/#iso:std:iso:2108:ed-5:v1

2. 第1条其实在6楼已经被提到,而且本身是明确的,现行标准就是ISBN-13。但是由于亚马逊等网络书店通常都将ISBN-10和ISBN-13并列,所以我确实对为什么2007年以后的书还有ISBN-10感到有些困惑。

这里我要承认一个错误,我有段时间想当然地认为是日本商品编号(JAN)还在沿用和ISBN-10一样的编码标准,所以日本亚马逊只是沿袭旧例(https://bgm.tv/group/topic/344469#post_1346352),但昨天我自己买书的时候发现,并不是只有日本亚马逊将ISBN-10和ISBN-13并列,据我所查,英国和美国亚马逊的图书也普遍这么做,甚至中国亚马逊也有部分图书存在这种情况(但也有不少只列出ISBN-13的)。

于是我简单查找了一下,发行确实搞错了,JAN书籍编码的前段13位早已改成了与ISBN-13一致(还有后段13位表示分类与价格信息),参见:
https://ja.wikipedia.org/wiki/%E ... 3%E3%83%BC%E3%83%89

3. 既然之前完全弄错了,所以又花了点时间调查了一下亚马逊的新书为什么还在用ISBN-10,尤其是我还发现亚马逊在介绍不同编码时也提到了现行标准就是ISBN-13(参见 https://www.amazon.com/gp/seller/asin-upc-isbn-info.htmlhttps://www.amazon.co.jp/gp/seller/asin-upc-isbn-info.html)。我现在觉得可能有两个原因:

一是2007年改标准时有2006年下半年作为过渡期,再加上当时自然有大量需要从ISBN-10改为ISBN-13的图书,所以许多图书查询或者网络书店的数据库里ISBN-10和ISBN-13这两项应当同时存在。由于同一本书ISBN-10和ISBN-13信息位相同,校验码算法是公开的,所以数据库软件应该可以自动实现这两项互相转换,于是2007年之后发行的图书可能也就一直保留了这两项。

二是亚马逊有一套自己的商品编码——亚马逊标准识别码(ASIN)。ASIN长度一直是10位,对于实体书来说ASIN采用的就是ISBN-10的标准。这次我确认了一下,在亚马逊提供的ASIN查询工具(http://www.amazon-asin.com/)中用ISBN-10搜索,可以准确找到某本书,但用ISBN-13却反而不行。根据这一点,我觉得可以认为亚马逊现在列出的ISBN-10其实就是ASIN。

4. 关于bangumi书籍条目中ISBN应该怎么填,我建议还是参照标准,2007年后的书籍在"ISBN"中就应当填写ISBN-13,而ISBN-10应该被看作某种采用了ISBN旧标准的其他编码。虽然ISBN-10不太合适被写在"ISBN"中,但如果编辑者新建一项"ASIN"并写入ISBN-10,我觉得没问题。bangumi收录的游戏、音乐和电子书,如果在亚马逊上出售,通常都会有对应的ASIN,我有时也会发现有编辑者将ASIN写进这些条目。

5. 第2条中提到了我对JAN的错误认识,实际上我已经在一些条目中进行了错误编辑(bgm57)(bgm38),十分抱歉,以后我会慢慢改正这些条目(bgm38)。而且由于我的错误也导致@拿月亮自刎 大大在亚马逊抓取脚本中进行了不必要的改动,再次表示对不起,不过还是麻烦如果下次改动脚本时能把这条改正(要么去掉ISBN-10或JAN,要么将这一项用ASIN代替,参见第2和第3条,这次还是有把握没搞错的(bgm38))。
#18-1 - 2018-8-3 03:32
烈之斩
想指出几点我感觉逻辑很混乱的地方(或者只是我单纯没看懂(bgm38)

首先,http://www.amazon-asin.com/ 并不是Amazon官方提供的工具,其能做到什么做不到什么不足为据。就算他是官方的好了,人家叫ASIN工具,不叫ISBN工具,当然只能搜ASIN不能搜ISBN呀。

>根据这一点,我觉得可以认为亚马逊现在列出的ISBN-10其实就是ASIN。

这句话没错……但是说法很奇怪。图书当然是先有书号(不管是10还是13,本来就是可以一一对应的没区别),“亚马逊现在列出的ISBN-10其实就是ASIN”这种说法因果倒置。
其实一句话就能概括了:Amazon现在图书的ASIN沿用的是ISBN-10,但是最多算是个历史遗留问题(Amazon出现的时候还没ISBN-13呢吧)。

----

说了这么多废话,总而言之我同意你的观点,不能仅仅因为ASIN(一个理论上毫无约束力的第三方,Amazon)是ISBN-10,就强行用旧标准,硬要说的话Amazon基本所有图书也都有列ISBN-13不是?

其实现在还讨论这个没啥意义,因为系统改良之前无非是编者靠自觉,能去填ISBN就已经很不容易了。

而如果哪一天系统真的会改进,到底10还是13的转换都是非常trivial的
#18-2 - 2018-8-3 05:15
卢乔
烈之斩 说: 想指出几点我感觉逻辑很混乱的地方(或者只是我单纯没看懂

首先,http://www.amazon-asin.com/ 并不是Amazon官方提供的工具,其能做到什么做不到什么不足为据。就算他是官方的...
想了想,这一段最大问题是由于没交代为什么会把ISBN-10和ASIN联系起来造成的,所以在这个ASIN查询工具上用ISBN-10和ISBN-13进行搜索显得很混乱。

总之,我先是在前面提到过的亚马逊介绍不同编码的页面上(https://www.amazon.com/gp/seller/asin-upc-isbn-info.html)看到了ASIN是10位码,以及书籍的ASIN和其ISBN相同。虽然算是官方解释,但我又觉得这两点肯定没讲清楚,因为ASIN既然是10位,那就不可能和新标准ISBN-13相同(而且我又发现有人反馈过“亚马逊何时才能用ISBN-13作为ASIN”的问题)。

所以接下来我才想到去这个“多合一ASIN查询工具”(http://www.amazon-asin.com/ )上确认书籍的ASIN和其ISBN是否有关。先是在亚马逊上随便找本书,用其页面上显示的ISBN-10搜索,发现能搜到;然后再用其ISBN-13搜索,发现找不到,后一步一是为了确认ASIN肯定不是ISBN-13,二是排除一下此查询工具或许也可以直接用ISBN进行查询的可能性,从而说明第一步中能搜索到确实是因为书籍的ASIN采用了和ISBN-10相同的编码规则。

结论,比较肯定的是书籍的ASIN编码规则与ISBN-10相同,另有一条猜测则是亚马逊之所以在书籍页面上将ISBN-10和ISBN-13并列,其实是将ASIN以ISBN-10的名义列出。

------------------

回到正题,确实技术上ISBN-10和ISBN-13的转换是个很简单的问题,不过我的初衷是觉得既然格式需要规范化,那规范化本身应该先有个准确的标准,将来需要实现转化功能的时候也有个前提或依据嘛。
#18-3 - 2018-8-3 09:06
烈之斩
卢乔 说: 想了想,这一段最大问题是由于没交代为什么会把ISBN-10和ASIN联系起来造成的,所以在这个ASIN查询工具上用ISBN-10和ISBN-13进行搜索显得很混乱。

总之,我先是在前面提到过的亚马逊...
关于那个为什么不用isbn13当asin,亚马逊不只是卖书嘛。所有商品都有asin,只有一小撮有isbn。为了这个去动他的系统(加几位看似简单,前端后端都要改还有向后兼容的问题)没有特别合理的理由他是不会的
#18-4 - 2018-8-3 21:38
拿月亮自刎
好了,已改为 ASIN。顺便把自动填表加上去了,不用每次都点一下“wiki 填表”。
#18-5 - 2018-8-4 06:11
卢乔
拿月亮自刎 说: 好了,已改为 ASIN。顺便把自动填表加上去了,不用每次都点一下“wiki 填表”。
多谢!