| daniel edited the task description. (Show Details) |
EDIT DETAILS
TBD
* 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.
* Use "raw" instead of "data", e.g. https://commons.wikimedia.org/raw/Data:Avignon_City_Wall.map
TBD
* "raw" is less descriptive, and may not be correct if content negotiation is applied.
* Use REST API URLS
TBD
* The REST API offers fairly clean URLs, but they still expose details about the web application and API version. Even the fact that they expose the fact that this is an API is too specific in a context where URLs are used as identifiers.
* Apply content negotiation to the established page URLs using the ```/wiki/``` path
TBD
* The ``/wiki/`` path really points to a UI for interacting with the page. Using it to refer to the page content can be confusing. On the other hand, such URLs are already in use for referring to Wikipedia pages in RDF.
* "URLs don't need to be pretty"
TBD * While URLs do not have to be pretty, they should be stable, especially when they are to be used as stable unique identifiers. Remocing all application specific information from the URL provides more stability by adding a layer of abstraction.
== Resources ==
...
* Do not include the namespace after /data/, e.g. https://commons.wikimedia.org/data/Avignon_City_Wall.mapTBD
* 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.
* Use "raw" instead of "data", e.g. https://commons.wikimedia.org/raw/Data:Avignon_City_Wall.map
TBD
* "raw" is less descriptive, and may not be correct if content negotiation is applied.
* Use REST API URLS
TBD
* The REST API offers fairly clean URLs, but they still expose details about the web application and API version. Even the fact that they expose the fact that this is an API is too specific in a context where URLs are used as identifiers.
* Apply content negotiation to the established page URLs using the ```/wiki/``` path
TBD
* The ``/wiki/`` path really points to a UI for interacting with the page. Using it to refer to the page content can be confusing. On the other hand, such URLs are already in use for referring to Wikipedia pages in RDF.
* "URLs don't need to be pretty"
TBD * While URLs do not have to be pretty, they should be stable, especially when they are to be used as stable unique identifiers. Remocing all application specific information from the URL provides more stability by adding a layer of abstraction.
== Resources ==
...
TASK DETAIL
EMAIL PREFERENCES
To: daniel
Cc: 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
Cc: 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 [email protected] https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
