Property talk:P2671

From Wikidata
Jump to navigation Jump to search

Documentation

Google Knowledge Graph ID
identifier for Google Knowledge Graph API (starting with "/g/")
Data typeExternal identifier
Allowed values\/g\/1[0-9a-np-z][0-9a-np-z_]{6,8}
ExampleAlphabet Inc. (Q20800404)/g/11bwcf511s (RDF)
Sourcehttps://developers.google.com/knowledge-graph/
Formatter URLhttps://g.co/kg$1
Tracking: usageno label (Q44291954)
See alsoFreebase ID (P646)
Lists
Proposal discussionProperty proposal/Archive/47#P2671
Current uses13,864
Search for values
[create] Create a translatable help page (preferably in English) for this property to be included here
Distinct values: this property likely contains a value that is different from all other items. (Help)
List of this constraint violations: Database reports/Constraint violations/P2671#Unique value, hourly updated report, SPARQL (every item), SPARQL (by value), SPARQL (new)
Single value: this property generally contains a single value. (Help)
Exceptions are possible as rare values may exist.
List of this constraint violations: Database reports/Constraint violations/P2671#Single value, SPARQL, SPARQL (new)
Format “\/g\/1[0-9a-np-z][0-9a-np-z_]{6,8}”: value must be formatted using this pattern (PCRE syntax). (Help)
List of this constraint violations: Database reports/Constraint violations/P2671#Format, hourly updated report, SPARQL, SPARQL (new)
Scope is as main value (Q54828448), as references (Q54828450): the property must be used by specified way only (Help)
List of this constraint violations: Database reports/Constraint violations/P2671#scope, hourly updated report, SPARQL (new)
Pattern ^(/m/0[0-9a-zA-Z_]{2,7})$ will be automatically replaced to \1 and moved to Freebase ID (P646) property.
Testing: TODO list

This property is being used by:

Please notify projects that use this property before big changes (renaming, deletion, merge with another property, etc.)

Identifiers with m[edit]

shall they be deleted? Queryzo (talk) 21:06, 15 October 2016 (UTC)

they should be moved to Freebase ID (P646) --Pasleim (talk) 21:08, 15 October 2016 (UTC)
so I can delete it here: Waldorf Astoria Berlin (Q220141)? Queryzo (talk) 22:22, 15 October 2016 (UTC)

Allowed values regexp seems incorrect[edit]

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)?[edit]

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)