Predicate Proposal - Glassdoor ID

Definition: The unique Glassdoor ID associated with this entity on Glassdoor. Glassdoor ID pages provide a profile of a company along with reviews of the company by current and former employees, reports on interviews with the company, and other data on the company.

A Glassdoor ID is the number that is prefaced with the string “-EI_IE” and appended with “.htm”

Entity IDs can be used as globally unique URIs following the pattern:<ID>.htm

Tooltip definition of the predicate: “The unique Glassdoor ID associated with this entity”

Type of value: String

For enums - all possible values: N/A

# of accepted values: One

Inverse Properties and Name: N/A

Examples of proper use:

  • Microsoft → ‘Glassdoor ID’ → ‘1651’ is correct, as it corresponds with: which is the the same entity (Microsoft) as the the subject of the triple.

Examples of improper use:

  • Sony’ → ‘Glassdoor ID’ → ‘19973’ is incorrect, as it corresponds with which is the Glassdoor ID for Sony Electronics, a division of Sony.

Usage in other schemas:

Citation Required?: No - the ID functions as its own citation as the URL for the Glassdoor page can be formed out of the Glassdoor ID. ie 1651 corresponds to

1 Like

This looks good to me!

@leeds Do you think we need to indicate somewhere in a predicate definition if the website has limits on page views before hitting a sign-in wall? I think I hit the sign-in after 5-10 pageviews on Glassdoor. It has implications for validation but not the predicate definition itself so wasn’t sure if that should be included…

This doesn’t feel like a concern to me? (As long as there’s at least some content that can be viewed publicly.) Particularly since some of these sites could potentially change what they show to different users at any given time…

Okay, got it, good point. I assumed not necessary since we did not include in the Crunchbase URL definition (and Crunchbase has similar issues of needing to go incognito after 5 page views) but just wanted to bring up just in case. Thank you.

Would agree its worth thinking about generally, but per Jed’s point this changes often and so probably not something we can specify in these proposals. We will need to have a later discussion about how to handle validation for URLs generally that don’t have a paywall - iframing the content of a URL would be one possible solution but gets into security concerns, requiring a screenshot of evidence has UX concerns, etc.

Add a bit more detail to the Definition to describe a Glassdoor profile page.

1 Like

Maybe I’ll add a little: 1. value in confirming the truth. Crunhbase must be seen from this perspective as a source of truth. Of course the source has access restrictions but can actually be validated by validators with access. Everything will be decided if validators can perform preliminary validation filters, for example, by language group, or only facebook or whitepaper checks. 2. the ability to supplement with an additional quote. For example, the organization’s address can be confirmed by a citation on Linkedin, the official website and other sources of information, if other sources of information become outdated or unavailable, then the predicate is confirmed by an additional second or third citation

[This predicate has been added to the protocol schema]

1 Like