daniel added a comment.
This RFC was discussed in a public meeting on IRC on March 28th. Full log: https://tools.wmflabs.org/meetbot/wikimedia-office/2017/wikimedia-office.2017-03-29-21.01.log.html
The outcome was that @daniel will revise the RFC based on the discussion, and then put it on last
daniel added a comment.
@MZMcBride It's not about the URLs bein "pretty" URLs as much as it's about the URLs being stable. That is much easier to achieve if the URL is "clean": it should not expose technical details about the underlying web application or access mechanism. Clean URLs provide a
MZMcBride added a comment.
From the current task description:
Problem:
There is currently no canonical URI/URL for referring to and retrieving these data sets.
Can someone please elaborate on this? This task has a whole lot of text about potential solutions and it's not clear to me why a "nice"
daniel added a comment.
/wiki/{title} is the user interface URL. I think it makes sense to have a separate URL for the data. This will also make it much easier to introduce a URL that supports content negotiation via 303 redirects.TASK DETAILhttps://phabricator.wikimedia.org/T161527EMAIL
Smalyshev added a comment.
/wiki/{title} assumes HTML representation. If we could make it content-negotiate to another representation (JSON, CSV or whatever is appropriate for map data - geoJSON?) it'd be fine. But if it's hard to do, we'd better use URI that makes it easier.TASK
GWicke added a comment.
I think the URL most users would consider canonical is /wiki/{title}. Wouldn't this already provide a reasonable URL for the concept of the page?TASK DETAILhttps://phabricator.wikimedia.org/T161527EMAIL
daniel added a comment.
@GWicke yes, indeed. This ticket is not about concept URIs, but about URIs for page content. Page content may be a description of a real world concept, or be otherwise related to such concepts. In order to express such a relation ship, both (the concept and the description)
GWicke added a comment.
In T161527#3135095, @Smalyshev wrote:
I think we have several concepts there that needs to be refined.
Canonical object URI - this is the URI that uniquely identifies an object in Wikimedia world, and, by extension, in the whole world of linked data.
I think there is
daniel added a comment.
This RFC is scheduled for discussion on IRC tonight, at 21:00 UTC (2pm PDT, 23:00 CEST), on freenode, in the channel #wikimedia-office.TASK DETAILhttps://phabricator.wikimedia.org/T161527EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To:
daniel added a comment.
@Smalyshev Oh, I was just trying to clarify the semantics of the URI. I wasn't trying to argue against your point. In fact, I agree with everything you wrote above :)TASK DETAILhttps://phabricator.wikimedia.org/T161527EMAIL
Smalyshev added a comment.
. In Wikidata, each entity has two URIs associated with it: the concept URI (.../data/Q12345) for the actual thing and the data URI (.../wiki/Special:EntityData/Q12345)
ITYM .../entity/Q12345.
Yes, the first one is the canonical entity URI and the second is data access
daniel added a comment.
In T161527#3135290, @Smalyshev wrote:
Well, if we plan to refer to it in RDF, we need some URI. RDF does not make distinction between real concept URIs and "just" URIs which don't mean anything special, and we could kind of pretend that this is "just" URI. But why do it if
Smalyshev added a comment.
for commons data, we may not need a canonical object (concept) URI.
Well, if we plan to refer to it in RDF, we need some URI. RDF does not make distinction between real concept URIs and "just" URIs which don't mean anything special, and we could kind of pretend that
daniel added a comment.
@GWicke:
I'd rather not use a REST URL as the URI. A good REST API exposes version, api method, etc. It's as explicit as possible. A good URI is minimal. It's purpose is to identify a resource on an abstract level, not (in general) a particular version or serialization,
Smalyshev added a comment.
I think we have several concepts there that needs to be refined.
Canonical object URI - this is the URI that uniquely identifies an object in Wikimedia world, and, by extension, in the whole world of linked data. Note that in theory that URI does not have to produce
GWicke added a comment.
However, URIs by nature should not include interface version information, because they identify the resource independently of representation.
The REST API versioning policy explicitly describes how representation concerns are hadled through content negotiation, and not by
daniel added a comment.
@GWicke REST URLs and canonical URIs are quite different conceptually, though it's nice when they coincide. However, URIs by nature should not include interface version information, because they identify the resource independently of representation.
What URI structure
GWicke added a comment.
The description of the requirements seems to fit the REST API:
API versioning & content negotiation.
REST URL structure.
Integration with CDN layer.
Machine and user readable API specs & documentation.
The REST URL hierarchy makes it quite easy to route specific end
18 matches
Mail list logo
