(Imported from GitHub issues)

addshore:
Reported on telegram.

An initial poke was made in https://github.com/wbstack/cradle/pull/1 which fixed 1 thing, but left some parts still not working.

https://twitter.com/MagnusManske/status/1375375390135439362

OAuth permission error it seems:
The authorization headers in your request are not valid: No approved grant was found for that authorization token. See https://addshore-alpha.wiki.opencura.com/w/api.php for API usage."

So api.php reads in the same config as the JS frontend, but that is config.js, so I fiddle with the JS code in PHP to make a “pure” JSON file. All that window.location.protocol stuff in your config.js breaks that.

addshore:
So it looks like a hack will also be needed in https://github.com/wbstack/cradle/blob/main/public_html/api.php#L8-L15

addshore:
I took an initial look at this, but still more to do.
Tools like this would be easier to work with if their auth was not split out over widar and the tool itself.
Right now all that might be needed is WbstackMagnusOauth::setOauthDetails in api.php, but this api lives in cradle, but the other authed stuff is currently in widar...

GreenReaper:
I debugged through this and after a while I figured out what was necessary to get it to work, and some ways it might be improved.

The error message above occurs if you aren't logged in via the tool; but even when you are, there's a problem: valid shapes specified without EXTRA or with whitespace - including your shape <something> { wdt:P12 [wd:Q1] } - or non-wdt: prefixes aren't loaded.

After some poking (vue.js loads shex as a dynamic component, harder to debug) I found this regex was failing to find any elements:

<([^/<>]+)>(?: EXTRA .*?)?\w*\{(.+?)\}

As Lucas notes "the regex currently treats EXTRA as a mandatory part of a shape, should be optional". In fact, an attempt was made to make the EXTRA into an optional non-capturing group; regardless, it does not actually work without it in many cases because \s is not included in \w and therefore any whitespace between > and { will break the match.

As I understand it, the EXTRA portion indicates that it is OK to have additional use of predicates not mentioned as part of the shape. For example, I believe this means that humans may be an _instance of_ (P31) items other than a human.

&lt;human&gt; EXTRA wdt:P31 {

wdt:P31 [wd:Q5];

... }

I had a shape with <convention> { that was not detected.
When I changed it to <convention> EXTRA wfdt:P1 { it proceeded through that particular issue.

The regex <([^/<>]+)>(?:\s+EXTRA\s+.*?)?\s*\w*\s*\{(.+?)\} seems to work for both the CLOSED case, one or more EXTRA wdt:, or none and may resolve this issue. (There may however be a simpler alternative; and I cannot guarantee it works in all cases.)

However, I then ran into the fact that I _wasn't_ using wdt: but rather wfdt: to refer to direct local properties. I did this in part because these are mentioned as being "internal to Wikidata" and may be confused with Wikidata, especially when working with multiple wikibases or performing a federated query.

Unfortunately Cradle is hardcoded to match via part.match(/^wdt:(P\d+)\s*(.*)$/) ; and so failed to find the direct props.

My schema contained PREFIX wfdt: <http://furry.wiki.opencura.com/prop/direct/> and it worked in the ShEx2 validator. Ideally Cradle might have looked for a prefix declaration with a path matching the value of d.query.general.server + '/prop/direct/' saved during its custom API step. (The same place where self.page_path is incorrectly set, as mentioned below.)

Once I had modified my shape to use wdt/wd, Cradle loaded the shape successfully. However, the component 'typeahead-search' has hardcoded references to https://www.wikidata.org/w/api.php?callback=? and therefore returns Wikidata items when typing. Once 'Q1' is entered for "instance of", the correct item is shown in the suggestion menu.

{F41825891}

With all fields filled out, the item can be successfully created - a 200 was returned. However, when I did this, the 'working' circle to the right of 'Help' kept spinning (but this cleared when I edited one of the fields). If it intended to tell me it had succeeded, it did not.

---

As a secondary matter - I don't know if it matters at all, or where, but it seems incorrect:
In wikidata.js, function WikiData () , this.set_custom_api there is a line

self.page_path = 'https:' + d.query.general.server + d.query.general.articlepath ;

However d.query.general.server = "https://furry.wiki.opencura.com"
...so this means self.page_path = "https:https://furry.wiki.opencura.com/wiki/$1" which seems incorrect.
It might have helped if using d.query.general.servername (= "furry.wiki.opencura.com"), but then it'd need 'https://'

GreenReaper
I know this sounds hacky, but if it was searching for t:(P\d+) (after all, the 'wd' is 'wikidata', right?) then the direct props would have been detected in this case, and probably for others making up their own prefixes using the pattern started by Wikidata.

Wikibooks suggests the only other _built-in_ t: prefix is hint: which may not be used in ShEx - or it could be specifically excluded. Bigdata's QueryHints wiki page also suggests it is only "hint:Prior" with t:P - the P isn't followed by a number, so wouldn't match. The same applies to wot:PubKey, and while [inet:](https://www.w3.org/2001/02pd/rfc65) is suggested as a potential prefix I think it just has :rfc, :title and :date.

GreenReaper:
Unfortunately I think such abbreviations will not work with the new version of federated props, that proposes to use the Concept URI as the property identifier. Instead it may have to accept everything that can be a URL - or, more practically, everything up to a terminator.

Making Cradle work with federated props would be beneficial because entering long URIs is liable to error and not a productive use of time.

Vesihiisi

However, the component 'typeahead-search' has hardcoded references to https://www.wikidata.org/w/api.php?callback=? and therefore returns Wikidata items when typing. Once 'Q1' is entered for "instance of", the correct item is shown in the suggestion menu.

I just encountered this issue when working on https://metabase.wikibase.cloud/tools/cradle/?#/shex/E2 -- the suggestions all come from Wikidata.

{F41825901}

lokal-profil:
Seems to be https://github.com/wbstack/magnustools/blob/2c2e4128132ac7f943934fa909fa9da7b07e0138/public_html/resources/vue/typeahead-search.html#L118 and L135 causing that issue

Mentioned here https://github.com/wbstack/magnustools/pull/6