[Wikidata-bugs] [Maniphest] [Commented On] T161527: Canonical data URLs for machine readable page content
daniel added a comment. This RFC was discussed in a public RFC meeting on the wikimedia-office channel on April 12. It was agreed that the RDF be put on Last Call: if no new pertinent concerns are raised by April 26th, the RFC will be approved for implementation. Meeting log: https://tools.wmflabs.org/meetbot/wikimedia-office/2017/wikimedia-office.2017-04-12-21.07.htmlTASK DETAILhttps://phabricator.wikimedia.org/T161527EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: danielCc: Scott_WUaS, bmansurov, WMDE-leszek, MZMcBride, Rybesh, GWicke, tstarling, Aklapper, Jonas, Smalyshev, mkroetzsch, Lydia_Pintscher, daniel, QZanden, Izno, suriyaa, Eevans, mobrovac, Hardikj, Wikidata-bugs, aude, jayvdb, Southparkfan, fbstj, RobLa-WMF, santhosh, Mbch331, Jay8g, Ltrlg, Glaisher, bd808, Krenair, Legoktm___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T161527: Canonical data URLs for machine readable page content
bmansurov added a comment. I'm late to the party, but I'd like to make a couple of points below. Would it make sense to separate .map and .tab urls into something like https://commons.wikimedia.org/map/Avignon_City_Wall and https://commons.wikimedia.org/data/Dolmens_of_the_Preseli_Hills respectively? This would allow us to have both map and data using the same name without an extension. This also helps avoid confusion that .map and .tab are specific representations of some canonical thing. We'd be able to redirect to, say, an HTML representation by appending .html or XML representation by appending .xml. Having read the comments above, I'm in favor of making URLs pretty, simply because our use case in the future may include users directly sharing these endpoints rather than only machines reading these URLs. If we can create pretty URLs at no extra cost, why not do it. Could someone explain the downside of removing the "Data:" namespace from the description: That would mean this URL pattern cannot be used as a general mechanism to refer to page content. It would be specific to the Data namespace on Commons. An example would help clarify the situation. Also, is the above quote still true given the first point? Regarding page renames: The porposed schemes are not stable against page renames. We could use page IDs instead of the title. That makes the URLs a lot less intuitive, and requires database access in order to construct them. Is the idea behind using IDs to prevent future uses of an ID? If that's the case, can we find a middle ground where the date the page is created or moved is also included in the URL? Something like https://commons.wikimedia.org/map/01-01-2017/Avignon_City_Wall? If some other piece of data wants to use the title 'Avignon_City_Wall' at a later date, then the URL would look something like: https://commons.wikimedia.org/map/04-11-2017/Avignon_City_Wall.TASK DETAILhttps://phabricator.wikimedia.org/T161527EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: bmansurovCc: bmansurov, WMDE-leszek, MZMcBride, Rybesh, Dzahn, GWicke, tstarling, Aklapper, Jonas, Smalyshev, mkroetzsch, Lydia_Pintscher, daniel, QZanden, Salgo60, Izno, suriyaa, Eevans, mobrovac, Hardikj, Wikidata-bugs, aude, jayvdb, Southparkfan, fbstj, RobLa-WMF, santhosh, Mbch331, Jay8g, Ltrlg, Glaisher, bd808, Krenair, Legoktm___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T161527: Canonical data URLs for machine readable page content
Smalyshev added a comment. I'm also leading to using the dash. data would be equivalent to main-data I like the idea of no dash meaning the same as main-. Good defaults rule :)TASK DETAILhttps://phabricator.wikimedia.org/T161527EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: SmalyshevCc: WMDE-leszek, MZMcBride, Rybesh, Dzahn, GWicke, tstarling, Aklapper, Jonas, Smalyshev, mkroetzsch, Lydia_Pintscher, daniel, QZanden, Salgo60, Izno, suriyaa, Eevans, mobrovac, Hardikj, Wikidata-bugs, aude, jayvdb, Southparkfan, fbstj, RobLa-WMF, santhosh, Mbch331, Jay8g, Ltrlg, Glaisher, bd808, Krenair, Legoktm___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T161527: Canonical data URLs for machine readable page content
daniel added a comment. In T161527#3152755, @Smalyshev wrote: Perhaps https://commons.wikimedia.org/data-mediainfo/File:Foo.jpg So what would be the content of https://commons.wikimedia.org/data/File:Foo.jpg then? I'm still not clear on why would we need several data slots on the same page. The main slot data URL would refer to what action="" currently gives you: the wikitext of the file description page (not the structured meta-data): https://commons.wikimedia.org/w/index.php?title=File:Foo.jpg=""> Special:EntityData doesn't look good for me as canonical URL. As internal implementation, sure, why not, but we need something cleaner for the external canonical URL. Is what we currently use in the canonical data URLs for Wikidata. Yes, I don't like it either. http://www.wikidata.org/data/Q12345 would be much nicer. Dash may not be that bad, it's frequently used to connect similar elements as part of the name. I'm also leading to using the dash. data would be equivalent to main-data; We can then also have mediainfo-data, etc.TASK DETAILhttps://phabricator.wikimedia.org/T161527EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: danielCc: MZMcBride, Rybesh, Dzahn, GWicke, tstarling, Aklapper, Jonas, Smalyshev, mkroetzsch, Lydia_Pintscher, daniel, QZanden, Salgo60, D3r1ck01, Izno, suriyaa, Eevans, mobrovac, Hardikj, Wikidata-bugs, aude, jayvdb, Southparkfan, fbstj, RobLa-WMF, santhosh, Mbch331, Jay8g, Ltrlg, Glaisher, bd808, Krenair, Legoktm___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T161527: Canonical data URLs for machine readable page content
Smalyshev added a comment. Perhaps https://commons.wikimedia.org/data-mediainfo/File:Foo.jpg So what would be the content of https://commons.wikimedia.org/data/File:Foo.jpg then? I'm still not clear on why would we need several data slots on the same page. Special:EntityData doesn't look good for me as canonical URL. As internal implementation, sure, why not, but we need something cleaner for the external canonical URL. Dash may not be that bad, it's frequently used to connect similar elements as part of the name.TASK DETAILhttps://phabricator.wikimedia.org/T161527EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: SmalyshevCc: MZMcBride, Rybesh, Dzahn, GWicke, tstarling, Aklapper, Jonas, Smalyshev, mkroetzsch, Lydia_Pintscher, daniel, QZanden, Salgo60, D3r1ck01, Izno, suriyaa, Eevans, mobrovac, Hardikj, Wikidata-bugs, aude, jayvdb, Southparkfan, fbstj, RobLa-WMF, santhosh, Mbch331, Jay8g, Ltrlg, Glaisher, bd808, Krenair, Legoktm___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T161527: Canonical data URLs for machine readable page content
daniel added a comment. @Smalyshev the problem is that page titles can contain slashes. If we don't always provide the slot name, how do we handle https://en.wikipedia.org/data/AC/DC? Is "AC" a slot name, or part of the title? What if it is both? One option is to not use another slash, but something like https://commons.wikimedia.org/data-main/Avignon_City_Wall.map. One example where we may need slot-specific data URLs is MediaInfo. What URL/URI should we use for the machine readable description of Foo.jpg? Perhaps https://commons.wikimedia.org/data-mediainfo/File:Foo.jpg? On the other hand, for Wikibase entities, we can always use something like https://commons.wikimedia.org/wiki/Special:EntitiyData/M26743276. But I'd really like to get rid if the Special:EntitiyData stuff in URIs...TASK DETAILhttps://phabricator.wikimedia.org/T161527EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: danielCc: MZMcBride, Rybesh, Dzahn, GWicke, tstarling, Aklapper, Jonas, Smalyshev, mkroetzsch, Lydia_Pintscher, daniel, QZanden, Salgo60, D3r1ck01, Izno, suriyaa, Eevans, mobrovac, Hardikj, Wikidata-bugs, aude, jayvdb, Southparkfan, fbstj, RobLa-WMF, santhosh, Mbch331, Jay8g, Ltrlg, Glaisher, bd808, Krenair, Legoktm___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T161527: Canonical data URLs for machine readable page content
Smalyshev added a comment. Possible solution: https://commons.wikimedia.org/data/main/Avignon_City_Wall.map. We don't need it for main slots, as it should be the default. We may want it if we ever need to have URLs for non-main slots. I'm not sure yet if we even have to have it- usually only the main data set has addressable URLs, and the parts of it - such as individual values or substructures - do not.TASK DETAILhttps://phabricator.wikimedia.org/T161527EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: SmalyshevCc: MZMcBride, Rybesh, Dzahn, GWicke, tstarling, Aklapper, Jonas, Smalyshev, mkroetzsch, Lydia_Pintscher, daniel, QZanden, Salgo60, D3r1ck01, Izno, suriyaa, Eevans, mobrovac, Hardikj, Wikidata-bugs, aude, jayvdb, Southparkfan, fbstj, RobLa-WMF, santhosh, Mbch331, Jay8g, Ltrlg, Glaisher, bd808, Krenair, Legoktm___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T161527: Canonical data URLs for machine readable page content
daniel added a comment. @MZMcBride good point about MCR slots. When designing a scheme like this, we should account for this. I of all people should know. I suppose I need to amend my proposal. With respect to /w/index.php, /w/api.php: we are not treating them as stable identifier prefixes. They are entry points. Tim asked me to not use the term URI, since they are the same as URLs in this context. But perhaps it's a useful distinction after all: not everything that is a decent URL is an acceptable URI. URI should be really stable, not for 10 years but for 100. It should be easy and straight forward to make them work with a completely different technology. Having ".php" anywhere in there is a no-go.TASK DETAILhttps://phabricator.wikimedia.org/T161527EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: danielCc: MZMcBride, Rybesh, Dzahn, GWicke, tstarling, Aklapper, Jonas, Smalyshev, mkroetzsch, Lydia_Pintscher, daniel, QZanden, Salgo60, D3r1ck01, Izno, suriyaa, Eevans, mobrovac, Hardikj, Wikidata-bugs, aude, jayvdb, Southparkfan, fbstj, RobLa-WMF, santhosh, Mbch331, Jay8g, Ltrlg, Glaisher, bd808, Krenair, Legoktm___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
