Identifiers with m
- they should be moved to Freebase ID (P646) --Pasleim (talk) 21:08, 15 October 2016 (UTC)
Allowed values regexp seems incorrect
The specified allowed values (
\/g\/[0-9a-zA-Z]+) would not produce a valid KG URL given the Formatter URL of (https://g.co/kg$1). To produce a valid KG URL allowed values should be (
s\/[0-9a-zA-Z]+). Looking at the first example I found with the P2671 property, i.e. Q34627, it does indeed have the value to produce a correct URL
s\/GDiHEp, however according to P2671 this is not an allowed value. – The preceding unsigned comment was added by Neilireson (talk • contribs) at 12:21, 30 June 2017 (UTC).
- The links starting with s just seem to short URLs generated dynamically when you click the 'share' button on a card in Google Search, which incidentally use the same https://g.co/kg$1 format but are not really the permanent IDs used in the Knowledge Graph (the short URLs change every time you refresh the page). The proper IDs start with either /m in which case it seems Freebase ID (P646) should be used or /g in which case this property should be used, the only distinction being that the former IDs were also used in the (now deprecated) Freebase API.
- I think the current regular expression therefore is correct, and that the constraint violations should be solved either by copying the value to Freebase ID (P646) if it starts with /m or by obtaining the permanent ID (appears in the expanded URL as kgmid) and inserting it into the correct property. Victor LP (talk) 12:37, 8 July 2017 (UTC)
Conflict constraint with Freebase ID (P646)?
Considering my comment above, a conflict constraint between Google Knowledge Graph ID (P2671) and Freebase ID (P646) might be useful to add. I could only find a few items that currently have both, so it seems not a common occurrence, and for most cases there seems to be one incorrect/deprecated ID, or the IDs refer to a slightly different version of the item (think multiple editions of a book).
I think the conflict constraint is actually equivalent to the unique value constraint that already exists on both properties, since the only distinction between them seems to be a historical one by now (whether the ID was present in the Freebase database). Of course exceptions to the constraint would be allowed, but adding it formalizes the uniqueness of the ID and makes it easier to track errors across both properties. Victor LP (talk) 07:33, 17 July 2017 (UTC)
- As mentioned on my talk page: " Interesting idea indeed. Maybe something to discuss on the property talk page. It seems odd that some have both. Maybe eventually most will end up having a /g/ and Freebase will remain mostly as historic. To some extent it captures the same as the format constraint (and the description displayed when users add it). Not sure if people who don't get that will get this and not remove the few exceptions." (please excused that I quote myself).
- I noticed that Freebase ID (P646)'s description includes the format, but this lacks it. Maybe this would be sufficient.
- Other than the items that should have both, are there any cases where we actually have both and it can't be solved by merely moving /m to the other property? If not, I think we should actually encourage people to add both.
--- Jura 12:27, 18 July 2017 (UTC)