[Wikidata-bugs] [Maniphest] [Commented On] T73991: RDF output should contain license info about the concrete rendering, not only the abstract description document.
Nevalicori added a comment. Hi @Lucas_Werkmeister_WMDE , Not quite an assumption per se; HTTP is stateless, so it doesn't really matter what kind of redirect you used to arrive at /Q1.ttl; if that ends up being the Request-URI, then that's the URL which needs to appear in the document for an automated processor to be able to interpret licensing statements properly. With respect to which HTTP status code is actually correct… that's a slightly different issue; and it's a little tricky because there are very few LOD clients out there against which to baseline behaviour. However, in the past where I've implemented them, whether a redirect is a 301/302 or a 303 does necessarily influence behaviour to an extent: you request : a) if the response is 301/302, the redirect target is interpreted as an alias for (i.e., you're potentially redirecting the concept, and so the target should be added to the list of candidate URIs to look for in the document you eventually retrieve) b) if the response is 303, the redirect target is the URL of a document containing data about In the Wikidata case, (b) happens in the redirect from /entity/Q1 to /Special:EntityData/Q1; the complicating factor is that Wikidata is then redirecting a second time, after content negotiation. In principle, I'd be inclined to agree that 302 Found with Vary: Accept would be the correct response here (because /Q1 is, conditional upon the value of the Accept header, an alias for /Q1.ttl). However, I have no idea how processors would behave in that scenario. It's probably fine, though :)TASK DETAILhttps://phabricator.wikimedia.org/T73991EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: NevalicoriCc: Addshore, Lucas_Werkmeister_WMDE, Smalyshev, Nevalicori, Wikidata-bugs, Lydia_Pintscher, daniel, Dinadineke, Nandana, tabish.shaikh91, Lahi, Gq86, GoranSMilovanovic, Soteriaspace, Jayprakash12345, JakeTheDeveloper, QZanden, merbst, LawExplorer, _jensen, aude, TheDJ, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T73991: RDF output should contain license info about the concrete rendering, not only the abstract description document.
Nevalicori added a comment. @daniel: do you mean 'this concrete serialisation', 'this abstract document', or 'a specific version of this abstract document'? (Realistically, you need a URI pattern that handles all three) At the moment, there are definitely two //canonical// versions of those: `/wiki/Special:EntityData/Q1.ttl` - the concrete serialisation of the current version of the document `/wiki/Special:EntityData/Q1` (or `data:Q1`)- the current version of the abstract document which can be serialised in a number of formats (When dereferenced, the latter always redirects to the former - of course, it could in the future not redirect, but instead just serve the equivalent content to the former and ideally send an appropriate `Content-Location` instead). Versioning can be handled through a million ways, and I'm guessing some of the wikidata stack does that already through query-parameters, so let's leave that for the moment. I might be being dim and missing the point, but I //think// what you're driving at is... For //not-necessarily-canonical copies// (for example, a copy that's been saved to disk and may have a `file:///` URI), you can express triples with a subject of `` as the concrete serialisation and express a relationship between that and the canonical URI for the document, `data:Q1` (and it's up to you whether you attempt to express any kind of relationship between `` and, say, `/wiki/Special:EntityData/Q1.ttl`; if the two are actually the same URI, you risk stating that a subject is derived from itself, if you're not careful!) Is that what you meant? Is that the answer? TASK DETAIL https://phabricator.wikimedia.org/T73991 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign username. EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Nevalicori Cc: Smalyshev, Nevalicori, Wikidata-bugs, Lydia_Pintscher, daniel, aude ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T73991: RDF output should contain license info about the concrete rendering, not only the abstract description document.
Nevalicori added a comment. Thanks for clarifying the priority issue. While it might be repetitious, it's not unusual to license different serialisations differently (WIkidata doesn't, but other sites do: the HTML representation may well be under a more restrictive license than the RDF, for example). From a processor's point of view (at least, one that actually cares about licensing and isn't a human being), it needs to be able to understand that this resource that I retrieved is under X licence (which is really the point of licensing predicates). As the resource URI really is `/wiki/Special:EntityData/Q1.ttl`, that's the resource which needs to have licensing data expressed about it. You //could// say “all serialisations of this document are licensed under these terms”, but you'd have to relate each serialisation to the abstract document URI //and// be fairly confident that consumers would adopt it as a practice. We could update our processor to follow a `concrete-uri dct:isVersionOf abstract-uri` to look for licensing data, although I don't know if anybody else would go to the trouble (it's hard enough to get licensing data included in the first place!) An alternative approach would be to send it as a `Link` header (with `rel=license`) (which is what some others do), at which point the RDF itself becomes slightly moot. TASK DETAIL https://phabricator.wikimedia.org/T73991 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign username. EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Nevalicori Cc: Smalyshev, Nevalicori, Wikidata-bugs, Lydia_Pintscher, daniel, aude ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T73991: RDF output should contain license info about the concrete rendering, not only the abstract description document.
Nevalicori added a comment. Hold on, you're not sure you understand but you've lowered the priority anyway? The problem is that the **current** licensing triple is redundant, because it's useless: there is currently no triple in the concrete serialisation which actually describes the licensing of that document. Noting that HTTP is stateless, the request you make for the Turtle is a GET for /wiki/Special:EntityData/Q1.ttl. That document contains triples which relate it to /wiki/Q1. There is //also// a licensing triple whose subject is /wiki/Special:EntityData/Q1, but there is no information relating that subject to the other two. You could invent some data (e.g., by using dct:hasVersion), except that I'm sceptical that any consuming application would be able to jump through those hoops without being given special knowledge of Wikidata (which defeats the purpose of linked open data). In short, you're generating machine-readable licensing data that only a human being can actually interpret. The simplest change is to change the current subject of the document description triples from the abstract document to the concrete serialisation. That is, change the triples whose subject is /wiki/Special:EntityData/Q1 to /wiki/Special:EntityData/Q1.ttl (et al). TASK DETAIL https://phabricator.wikimedia.org/T73991 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign username. EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Nevalicori Cc: Smalyshev, Nevalicori, Wikidata-bugs, Lydia_Pintscher, daniel, aude ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
