Do you foresee any changes to the context/vocabulary/ontology in the future (e.g. implementing processing features of JSON-LD 1.1)? How will context changes be versioned / published?

according to mailing list (Wikidata Digest, Vol 83, Issue 18), this now enabled on beta. Yet when one requests the link: https://wikidata.beta.wmflabs.org/wiki/Special:EntityData/Q64.jsonld, it does not work?

FYI: This is a known issue reported and discussed here https://phabricator.wikimedia.org/T90906#4525254

FYI: This is a known issue reported and discussed here https://phabricator.wikimedia.org/T90906#4525254

This was broken since May 26 with this commit:
https://github.com/phacility/phabricator/commit/2d79229083437a10bb16c4eb8bff393506f9c887#diff-1706b31ede02b2d136153ad54da8e348L9

I can add here that in fcrepo4, that with PR #1187 they have changed to not use RFC5785 for representing Skolemized bnodes. Instead, a new fragment URI convention has been implemented, so internally minted UUIDs are appended to the resource subject as a fragment (aka Hash URI identifier) rather than creating a new resource node. This convention actually makes more sense than RFC5785 for statements and references I suspect. Graph serializations then would "naturally" entail these identifier bnodes in a single resource/entity context, and this then facilitates round-tripping and other downstream from RDF operations, like JSON-LD framing.

The Conduit GUI is a component of Phabricator, not the Sprint extension.
This is an upstream issue entirely. Report your issue at
https://secure.phabricator.com/

There are multiple ways to "create a sprint". And both still work on the latest version of Phabricator (surprisingly to me, since I have not maintained this at all for many months) .

The fact remains that the claim without its entity relationship, represented in the GUID by the Q prefix, would be lost into a vacuum of nothing. And really, the concatenation of an entity ID with its statement UUID (with the expectation that a parser can understand the $ as a delimiter) is a rather questionable convention. I guess I am not clear on why the MW API should constrain RDF serialization. They are separate implementations. Is there a convenient "round trip" import from RDF mechanism available in the API? If not, who cares about what the MW API expects.

Statement IDs should definitely be represented as bnodes (internally) and skolem IRIs externally because they are uniquely defined within an entity node representation. They have no meaning outside of the entity.

A JSON-LD framing pipeline (like the one I have developed for Fedora Commons) is one use case. The JSON-LD library does not understand Skolem IRIs, so these type of identifier URIs would need to be converted into bnodes first. A Skolem IRI parsing function can be generic only if identifiers are recognizable in a standard namespace. Of course, one could hard code your namespaces into the parser as well, but this does not facilitate the interoperability of the data which is what is important and why there are recommendations like RFC5785.

This issue is caused by several poorly written upstream methods: primarily renderPolicyName. The error message is misleading and in fact you can see the real problem which is that there is a null policy creation or edit transaction object (which is why there is no PHID in the message) for one of your tasks.

Thanks for the heads-up about Gerrit and the tip for configuration. I must have missed the notification about the Gerrit deprecation/phase-out. Anyway, pushing directly with git ssh seems to work fine for me.

@Rbalik This is a patch file for the change. Just one file is touched and it seems to fix the immediate issue ...

@Aklapper I have the patch ready, but it seems that rights to the Sprint extension repo have been changed on Gerrit ... so I cannot even push it. Can you ask @mmodell or someone to fix this?

I looked at this briefly and made a patch.
https://github.com/wikimedia/phabricator-extensions-Sprint/commit/800a5e776027c974140daaf90383750e2e3b9bb6

Patch is here: https://github.com/wikimedia/phabricator-extensions-Sprint/commit/92223987987c10a6a406494acde20104dcc1e555

Patch here: https://github.com/wikimedia/phabricator-extensions-Sprint/commit/cecd542cdcc131418c92486111c82a1bb642640a

Check your Phabricator installation. This was patched months ago. See:

@fooishbar Thanks for the report. The reopened points never really worked properly, so I commented it out. The points remaining total incremented the reopened points twice, because a reopened task has multiple transactions for an "open" event in the time frame. I would have to make the logic to deduct reopened points from new task points on a per task basis to fix it (rather difficult to do with Phabricator's RDBMS madness). Rather than having a screwed up points remaining, it seems just easier to not aggregate reopened points at all. The sprint extension is not really a priority for me right now, so I am not sure that this fix will happen soon.

@Luke081515 Reporting seems a low upstream priority, so "soon", I doubt... See https://secure.phabricator.com/T4171 and https://secure.phabricator.com/T1562 I assume that eventually they will provide an interface for reporting that should include charts, etc.

The RDF standard that you reference explicitly supports my point.

The main issue is with string comparison of the percent encoded and unencoded forms of Unicode IRIs as resources.

See https://gerrit.wikimedia.org/r/#/c/282675/ for fix

The PRETTY_PRINT setting of the TurtleWriter is set to "true" by default. This causes the writer to only write the literal "label" without the datatype. This affects boolean, decimal, integer and double literals.

See https://phabricator.wikimedia.org/T130717 for explanation on how to
remove custom points field

I have worked around the counting problem. The experimental TPF Server is here:
http://orbeon-bb.wmflabs.org/

it seems that with a CONSTRUCT query, sending an Accept: text/turtle works.

the node.js version of the TPF server is actually why I created this issue.

Coincidentally, it seems that there are people who know a lot more about this than I do that have debated this issue at length in a long and very informative thread:
CRS specification (was: Re: ISA Core Location Vocabulary)

@Smalyshev so, by stating that geometry and CRS are different, you then concur with the main arguments referenced above that they should not be conflated in a simple literal. @daniel I agree with the idea of specifying the CRS as an additional component of the GlobeCoordinate data value separately from the geometry.

Please see geoSPARQL CRS design is debatable from the W3C Coordinate Reference System website.

@Smalyshev have you tried to read the updated WKT CRS specification http://docs.opengeospatial.org/is/12-063r5/12-063r5.html yet? From what I can interpret, they have now deprecated the 2012 "non-ISO compliant" concatenation of a URI form of CRS and geometry.

one could also simply set a point value to 1 for tasks in the project and get the same result as a "points count disable, task count on" feature.

Eh, http://schemas.opengis.net/geosparql/1.0/geosparql_vocab_all.rdf#wktLiteral is an RDFS Datatype so the semantics are defined by the RDF schema, right? But, I found this http://docs.opengeospatial.org/is/12-063r5/12-063r5.html that demonstrates that the WKT CRS extends far beyond RDF. I suspect that the implementation of wktLiteral is bound to RDFS, regardless of the "rich semantics" of WKT.

Thanks for the clarification. However, the Req 10 of the geoSPARQL specification seems to be at odds with the definition of a "literal value". (According to https://www.w3.org/TR/rdf11-concepts/#section-Graph-Literal). The way that I read this specification is that a literal is a string defined by a IRI datatype. Concatenating the geoGlobe IRI to the coordinate string is very weird, and I do not think that there are very many implementations who can declare that a IRI/string is actually a "literal".

Intentional or not., It is wrong. Why is it necessary? The problem is that it breaks parsing of geosparql literals. For example, if I ask for instance of volcanoes, I have to make exceptions for weird non-Earth coordinates.

Since this task is now almost 1 year old and not fixed, I am guessing that it should be closed as either "Declined" or "Irrelevant".

@Aklapper I consider the sprint extension to be "off my plate" so to speak. I do not consider the documentation to be finished, but I honestly do not have the time, interest, will or funding to do it. Thus, I must close this task as "Declined".

The need to maintain and synchronize with upstream has been greatly reduced with the removal of sprint boards and the addition of the global points field. Thus, I am closing this task as "Declined".

T89249 T100535 T91529

I may be wrong, but the headers that are returned from a request to the nginx server wdqs1002 say that varnish 1.1 is already being used there. And, for whatever reason, it misses, because repeating the same query gives the same response time. For example, this one returns in 25180>26966 ms.

I perceive the use of Varnish as not directly related to how an object broker could manage this use case (expensive querying of the wdqs nano sparql api), though it is probably related to any UI elements (i.e. the query editor or results renderer) that may generally be connected to the query service.

See https://gerrit.wikimedia.org/r/#/c/270791/.

@Smalyshev I completely agree with the concept of an intermediate service between the nanosparqlserver and the client. I think that this service should "broker" requests (based on an options configuration object), and eval whether a query is re-executed against the BG db or the results could be returned from the "cache", i.e. an "offline" "response only" db.

with the Projects v3 update, some clarity has finally been achieved regarding how upstream will implement the sprint extension functionality.

I suggest requesting this upstream. maniphest.points will replace custom story points going forward.