Wikidata:Property proposal/Schema.org ID

Schema.org ID edit

Originally proposed at Wikidata:Property proposal/Authority control

Not done

Description	identifier for a concept, at Schema.org
Data type	External identifier
Domain	all!
Allowed values	[A-Za-z\d]+
Example	police station (Q861951) → PoliceStation address (Q319608) → PostalAddress medical specialty (Q930752) → MedicalSpecialty tourist attraction (Q570116) → TouristAttraction
Source	http://schema.org/
Formatter URL	http://schema.org/$1

Motivation

First mooted by User:The Anome in April 2014(!), and increasingly relevant in the light of Schema.org's proposal to encourage the use of Wikidata as a common entity base for the target of the sameAs relation. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:10, 5 May 2017 (UTC)[reply]

@Pigsonthewing: that proposal is for using WD entities in RDF **instances** (individuals) that conform to schema classes and properties. Fictitious example: <my hammer> rdf:type schema:Offering; schema:additionalType wd:hammer (Q25294). But it has nothing to do with correspondence of schema classes and properties to WD. --Vladimir Alexiev (talk) 02:44, 6 July 2017 (UTC)[reply]
- Quote from Wikidata:Requests for comment/Schema.org identifier?: "I've noticed that some Wikidata entities correspond to schema.org entities. For example... http://schema.org/PoliceStation corresponds to Q861951 "police station"... Would it be a good idea to have a "schema.org identifier" property we can add to Wikidata to make these mappings explicit?". Note that as well as police station, The Anome used the other three examples used in my original proposal. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:23, 6 July 2017 (UTC)[reply]

Note: some items, e.g. actor (Q33999), are using exact match (P2888) to achieve this. I think a more specific property would be better. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:03, 5 May 2017 (UTC)[reply]

P.S. Some commenters have asked what advantages a unique property offers. They include:

Constraints can be applied, and thus errors more easily detected and fixed
Standard tool like "current uses", "count", etc., will be available (for examples, see the talk page of any existing external ID)
Tools like Resolver can be used - see for example, https://tools.wmflabs.org/wikidata-todo/resolver.php?prop=P496&value=0000-0003-4402-5296

-- Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:34, 16 May 2017 (UTC)[reply]

Note: Comments and examples which are not mine have been added to the proposal. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:53, 28 May 2017 (UTC)[reply]

Moved to a section below, for clarity. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:27, 6 July 2017 (UTC)[reply]

Discussion

I actually don't see why a specific property would be an improvement on exact match (P2888) here - it seems to me this is precisely what "exact match" is intended for. I also looked into the wikidata/schema.org relationship some time ago wondering essentially the same thing, why we didn't have a specific property for it, but it seemed like effort was being put into matching in the other direction which is great. ArthurPSmith (talk) 13:09, 5 May 2017 (UTC)[reply]

We can have this identifier property via authority control in Wikidata, but Schema.org isn't in a sense an authority control figurehead. "exact match" allows concepts to interchange fluidly, much more than an auth identifier. It also allows easier processing by external machine learning programs that already use "exact match" for following equivalence concept checking. DBPedia does some of this as well. So in the end, we will certainly not move from emptying values on "exact match" but would rather them heavily populated with other Linked Data sets. I myself have committed already to maintaining the mapping within Wikidata. There are parsers already that strip the base "http://schema.org/" from the concept, in the wild, so there's not much extra value with this proposed property. But I'm not against the effort to add it. I and others see more value with "exact match" since it brings alignment with other Linked Data sets. Thadguidry (talk) 13:40, 5 May 2017 (UTC)[reply]

I’ve seen equivalent class (P1709) used for this purpose (e.g. television series season (Q3464665) equivalent class (P1709) http://schema.org/TVSeries. However I’d support a more specific property, if nothing else for the fact that we could not include the http://schema.org/ prefix (instead adding that in the formatter), which would allow us to link to https://schema.org/ (https version of webpage), or some other future reference should some other website supersede schema.org in future. Frankieroberto (talk) 19:37, 5 May 2017 (UTC)[reply]

I support the creation of a new property if and only if it makes a mapping between Wikidata and schema.org easier to complete/make comprehensive. Nemo 15:12, 6 May 2017 (UTC)[reply]

Restriction: SchemaOrg use many compositions, as Personal name (Q1071027) that must be mapped to sh:Person+sh:name, not only sh:name, neither sh:Organization+sh:name... The SchemaOrg's Class+property semantics have no ID (!), it is a free combination (pair of IDs). Only very specific (SchemaOrg's subset of) classes and properties have some exact equivalence, so this new proposed SchemaOrg_ID is only for this restricted cases. --h[User:Krauss|Krauss]] (talk) 04:47, 15 May 2017 (UTC)[reply]

Conditional support: first create explicit rules or recommendations, to avoid duplications and misunderstandings... I invite all you to review Help:Statements/Guidelines for external relationships, that is waiting rules for the use of five properties (P1628, P1709, P2235, P2236, P2888). --Krauss (talk) 04:47, 15 May 2017 (UTC)[reply]
PS: at this time, without rules, there are a lot of doubts and duplications showed by this report of ~500 entries of Wikidata-SchemaOrg mapping.

Oppose @Pigsonthewing: you need to justify very well why we need such special prop for Schema but not for the 1000 ontologies out there, eg DC, DCT... Schema is important, but the value of LOD comes exactly from using URLs, so what's the benefit of having this special case for Schema? In fact it will smush the distinction between the specific links (equivalentClass, equivalentProperty etc), so I think it's worse
- @Frankieroberto: you don't need to worry that http://schema.org/ might some day change: it's used in 10B websites, so you can be certain it will live as long as the web itself. --Vladimir Alexiev (talk) 16:23, 16 May 2017 (UTC)[reply]
  - @Vladimir Alexiev: @ Pigsonthewing: http://schema.org/ may very well remain the prefix for the use in identifiers, but the actual webpage about the property/class can be viewed via https at https://schema.org. Right now, both https and non-http versions server the webpages, but in future the non-https version might redirect to the https version, and so it would be preferable to send users to the https version to avoid the extra http request (and to preserve their privacy), but we can only do this via having a specific formatterURL for that property. Frankieroberto (talk) 09:16, 24 May 2017 (UTC)[reply]
    - @Frankieroberto: you're missing an important fact: Schema says that its semantic URLs start with http, so in actual RDF data one must use http not https for Schema classes and properties. In the semantic web URLs are not simply for getting info about things, they **represent** things in certain precise ways. That's what I mean when I say that LOD (linked open data) is based on URLs not mere IDs --Vladimir Alexiev (talk) 02:44, 6 July 2017 (UTC)[reply]
      - @Vladimir Alexiev: I do understand how the Semantic Web works, and that URIs and URLs are different things (and the various debates about ways to distinguish the URI for the ID from the URI for the page about the ID, e.g. using a #resource suffice). However one reason for having a specific property for a schema.org ID is that it makes it easier to separate the two, e.g. an API user or RDF export can expand the ID to a URI by adding the http://schema.org/ prefix, whereas in constructing a link to the page about the ID (e.g. in the Wikidata editing interface using the formatter URL pattern) we can add the https prefix http://schema.org/ to preserve user privacy. Without the specific property, we can't easily do this. Frankieroberto (talk) 07:58, 6 July 2017 (UTC)[reply]
- @Vladimir Alexiev: Where do I say that we don't need properties for other ontologies? All our external-ID properties with a formatterURL can be expressed as URLs; we've already decided not to go down the URL-only road. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:31, 16 May 2017 (UTC)[reply]
  - LOD is based on URLs. Established ontologies like DC, DCT, Schema and many others have stable URLs. I don't see the value of creating specific props for each of these ontologies, which props further destroy the distinction between equivalentClass, equivalentProperty, subProperty, superProperty. --Vladimir Alexiev (talk) 10:49, 17 May 2017 (UTC)[reply]
    - This is a proposal to create a property for Schema.org, not the others you list. equivalentClass, equivalentProperty, subProperty, superProperty can be applied to such a property. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:08, 17 May 2017 (UTC)[reply]
      - @Pigsonthewing: didn't you imply above that we'd need properties for other ontologies as well? Or is this argument intended to sneak Schema ID in, and then proceed by sneaking other ontologies, perhaps using Schema as a precedent? --Vladimir Alexiev (talk) 02:44, 6 July 2017 (UTC)[reply]
        "intended to sneak " Outrageous. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:29, 6 July 2017 (UTC)[reply]
    - @Pigsonthewing: Can you give an example how this would work? Eg "airport (Q1248784) - schema.org id - Airport", and then what? --Vladimir Alexiev (talk) 08:43, 25 May 2017 (UTC)[reply]
  - @Pigsonthewing: the bullets you give above for "what advantages a unique property offers" are applicable to large datasets. They are not such important benefits for a few thousand items, which is the number of Schema classes and properties. Furthermore, ontology matching is rarely one-to-one. I may think that schema's Airport matches both airport (Q1248784) and aerodrome (Q62447), and you may disagree: deciding that "intellectual question" is a lot more important than knowing Airport is matched to 1 or 2, and knowing how many Schema terms are matched --Vladimir Alexiev (talk) 08:43, 25 May 2017 (UTC)[reply]
    - This issue exists whether or not we have a property, or whether we use a full URL as at present. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:50, 28 May 2017 (UTC)[reply]
Support ChristianKl (talk) 23:21, 26 June 2017 (UTC)[reply]
Support Frankieroberto (talk) 07:59, 6 July 2017 (UTC)[reply]
Oppose use instances of Wikidata property for ontology mapping (Q30249126) instead. -- JakobVoss (talk) 13:53, 31 October 2017 (UTC)[reply]
- @JakobVoss: Please can you give examples? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:12, 31 October 2017 (UTC)[reply]
  - @Pigsonthewing: See this SPARQL query to get the current mapping between Wikidata and Schema.org with 520 links using instances of Wikidata property for ontology mapping (Q30249126) -- JakobVoss (talk) 12:45, 1 November 2017 (UTC)[reply]
Oppose. I believe we should keep using exact match (P2888), equivalent property (P1628), external superproperty (P2235) and external subproperty (P2236) which are much more precise. I don't see the added value of having a property specific to schema.org Tpt (talk) 17:26, 1 January 2018 (UTC)[reply]

Support--ProtoplasmaKid (talk) 07:14, 21 March 2018 (UTC)[reply]

Commentary mistakenly added to the proposal edit

class-to-class, ID replacing exact match (P2888):
- emergency service (Q814610) → EmergencyService

class-to-property, ID replacing exact match (P2888):
- editor (Q1607826) → editor

property-to-property, ID replacing equivalent property (P1628):
- sponsor (P859) → sponsor

property-to-class, ID replacing equivalent property (P1628):
- field of work (P101) → Specialty

CAUTION:

full name (Q1071027) → Person + name
title (P1476) → CreativeWork + name
ISBN-13 (P212) has external superproperty (P2235) isbn
seat (Q2731419) has external subproperty (P2236) seatingType

... How to avoid mistakes? Replace properties by ID or add ID?
... We need for rules (!), before to create Schema.org_ID.
... Please edit/review Guidelines for external relationships.

-- – The preceding unsigned comment was added by Krauss (talk • contribs) at 22:38, 16 May 2017‎ (UTC).[reply]

Not done No consensus for the creation of this property. Micru (talk) 12:30, 24 March 2018 (UTC)[reply]