On 15/08/13 21:38, Dan Brickley wrote: ...
FWIW there's also RDF/XML if you use a *.rdf suffix. This btw is of great interest to us over in the schema.org <http://schema.org> project; earlier today I was showing http://www.wikidata.org/wiki/Special:EntityData/Q199154.rdf <http://www.wikidata.org/wiki/Special:EntityData/Q199154.rdf> to colleagues there... this is a Wikidata description of a particular sport. In schema.org <http://schema.org> we have a few places that hardcode a short list of well known sports, and we're interested in mechanisms that allow us to hand off to Wikidata for the "long tail". So http://schema.org/SportsActivityLocation has 9 hand-designed subtypes; we have been discussing the idea of something like http://schema.org/SportsActivityLocation?sport=Q199154 <http://www.wikidata.org/wiki/Special:EntityData/Q199154.rdf> to integrate Wikidata into the story for other sports. Similar issues arise with religions and places of worship (http://schema.org/PlaceOfWorship). Any thoughts on this from a Wikidata perspective would be great.
This is definitely something that we would like to encourage. Wikidata ids are fairly stable (not based on labels or languages) and fairly well grounded (described and named in many languages + linked to many Wikipedia pages, authority files, and external databases). So they should make suitable identifiers. No identifier will ever be reused, but it can happen that a Wikidata item is deleted, in which case it is no longer a suitable identifier. In theory, it can also happen that the data of an item changes so completely that the meaning of the item is different, but this is quite unlikely. One can access historic data fairly easily as long as the item is not deleted completely (not sure if a "historic RDF export" [by revision number] is planned, but it would not be hard to implement). And of course one would want the identifiers to be somewhat dynamic to capture changes of ideas over time (sports change all the time, e.g., if official rules are modified, but probably one does not want new IDs for every version of "football").
I am not sure if one needs to use http://schema.org/SportsActivityLocation?sport=Q199154 instead of using http://http://www.wikidata.org/entity/www.wikidata.org/Q199154 directly. Would these two have different meanings somehow? I guess they could, but there should not be a problem with long-term sustainability of the Wikidata URIs (just in case this is the main reason for creating new URIs here).
Is there any prospect of inline RDFa within the main Wikidata per-entity pages? It would be great to have http://schema.org/sameAs in those pages linking to dbpedia, wikipedia,freebase etc too...
This is not currently planned. One interesting starting point could be to identify the Wikidata properties that express "same as". For example, many properties link to other data collections by giving IDs (which often correspond to URIs, only that URL datavalues are not quite implemented yet). However, the granularity of other databases is often not the same, and it might not be true that these IDs unambiguously define the identity of the subject. For example, we had on this list a question recently whether Norman Cook should have individual entities for his various synonyms or not; MusicBrainz has several IDs for him based on synonyms, but Wikipedia has only one article about the person. In such cases, links to other datasets should probably not be interpreted as sameAs.
We currently use schema.org's "about" for linking Wikipedia pages to Wikidata ids. It seems wrong to say that an abstract URI (about a Wikidata entity) is "the same" as the URL of a Webpage that covers that topic. (This comment is about the links to Wikipedia you mentioned, not about cases with dedicated URIs that are not the web page URLs; the URIs for Wikipedia articles are in a strong sense the Wikidata URIs that we already start from ;-)
Btw, it is planned (vaguely) that property pages can hold more information, which could be used to declare "identifier properties" in the system at some point. But this will still take a while to implement.
Markus _______________________________________________ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
