Main Page: Difference between revisions

From geokb
No edit summary
No edit summary
Line 1: Line 1:
Welcome to the Geoscience Knowledgebase (GeoKB)
The Geoscience Knowledgebase is an experimental effort to encode all information and knowledge from the USGS scientific portfolio in earth systems science. It is a compelling idea to have domain-specific knowledge graphs sitting online and accessible to anyone that are "adjacent" to Wikidata but separate in that they are maintained by a group with vested interest in building them and using them in practice. As a government science institution, we have our own requirements on how we need to manage our information, and we likely don't want to have us government folks messing about directly in the "Global Knowledge Commons." Rather, our information is donated into the public domain for anyone else to do what they like. Read more about our motivation and background on the project in the [[About]] page.


= Project Intent =
Below, you will find a description of the main entities we are building here. Each section should have an example query that you can use to explore. This is all work in progress, so you'll see new things coming in as we get them worked out. You'll note some links to discussion pages where we are working through the specifics on how to model and encode our information into the graph.


The Geoscience Knowledgebase (GeoKB) is an experimental R&D effort in the U.S. Geological Survey, with this particular instance on the Wikibase Cloud our current skunkworks. We're ultimately trying to develop a new way of organizing and encoding all applicable knowledge that we develop through our institution about the earth system in a way that connects to the much broader global knowledgebase. As a government science institution, it's not really our role to muck about in the public commons knowledge-bank (e.g., Wikidata), but at the same time, it is our mandate to fully release (donate) what we know into the public domain for the public good.
= Entities =
Entities ("Q" identifiers or items) in the GeoKB are the primary object in the knowledgebase. They are the focus for our knowledge organization scheme. The majority of properties ("P" identifiers) have an item type classification meaning that the object they connect to a subject entity is another entity in the knowledgebase. The majority of our entities are not "native" to this knowledgebase; rather they are sourced from some other data or information system with the entity in the knowledgebase a basic representation of the "foreign-sourced" item.


What we're experimenting with here is how we can organize and project our data, information, and knowledge in a way that is more connected and more accessible for others to pick up and run with. By putting it all into the very granular structure that Wikibase is built on and leveraging pertinent aspects of the semantics in use in Wikidata and formal ontologies, our hope is that the curatorial pathway from "our knowledge" to "everyone's shared knowledge" is as frictionless as possible.
Entities are built iteratively over time with software codes used to introduce them to the knowledgebase. We may start an entity representation with only a couple of pieces of information, with the bare minimum being a label, description, and either an "[[Property:P1|instance of]]" or "[[Property:P2|subclass of]]" claim, depending on the purpose of the entity in the knowledgebase. We also describe source material as entities classified as "[[Item:Q26267|knowledgebase source]]." Claims (or statements) made about an entity should always have at least one reference that essentially cites the source for the statement. These will often point to a "knowledgebase source" item or may use "[[Property:P31|reference URL]]" when the reference source is simply a single linkable online resource. Over time, we may revisit the initial starter code that introduced an entity to the knowledgebase to change how it operates and bring in further claims. We may also change the nature of how an entity specifies its source by changing of adding to references.


We are also working on how this knowledgebase resource can be baked into our ongoing geoscientific research as a living tool - building it by using it in practice. Rather than being an afterthought, only contributed to by someone with enough interest at the end of a project, we are seeking to build it as a scientific instrument used directly in research and analysis. By working with this capability to solve important problems in information and knowledge management that are impeding our research practices today, this should result in a much more efficient pathway to usable knowledge projected out for others to take advantage of for their own purposes.
This page serves as iterative documentation of the entities in the knowledgebase with a focus toward how they can be retrieved and interacted with in use through SPARQL queries. It is organized into sections describing a few things about the major entity types. Each section may contain a link to an associated "item talk" page in this Wikibase instance that discusses the evolution of the entity. Each section will also contain a link to the associated ShExC schema for the entity type as those are developed iteratively. Schemas facilitate interactions with the knowledgebase such as ongoing multimodal introduction of new entity instances and claims.


Some of what we bring together in the GeoKB will be originated from our work in USGS, while much of it will come from the many other public data and information sources we consult in our research. We'll be working hard to get things right in terms of references and qualifiers on claims and careful provenance tracing through item and property history and annotation. We'll share the code we use in developing bots to handle as much of this work as possible, starting with [https://github.com/skybristol/geokb this project].
== Minerals Related Entities ==
USNS Mineral Resource Assessment work provides the seminal use cases for the GeoKB. We are using the knowledge graph model to transform and modernize a number of older databases, online tools, and information systems into a interconnected framework that can better scale into the future. The following section lays out the entity types in the GeoKB related to mineral resources and provides some example queries.


Wherever possible, we will pull directly from and build associations with Wikidata properties and classification items, though we are making judgment calls on where we agree/disagree with the specific semantics. While we may pull whole groups of items from Wikidata through bots, we are being selective in what claims we leverage from Wikidata, focusing on the parts that matter to our work and that we trust sufficiently to use. We'll dig a bit into what other groups are doing in this regard to follow useful conventions so we make our stuff as linkable as possible.
=== Mineral Commodity ===
The following query pulls items classified as mineral commodity and associated code values from the USGS Mineral Resources Data System and/or Mindat. Not all codes are in place for the items and Mindat codes will be changing to the long-form identifier resolvable at mindat.org.


= Claims, not facts =
<sparql tryit="1">
PREFIX wd: <https://geokb.wikibase.cloud/entity/>
PREFIX wdt: <https://geokb.wikibase.cloud/prop/direct/>
PREFIX p: <https://geokb.wikibase.cloud/prop/>
PREFIX pq: <https://geokb.wikibase.cloud/prop/qualifier/>


The Wikidata/Wikibase approach is particularly interesting in that it is built with a fundamentally simplistic model where an entity is nothing more than a label with alternates and a description along with a local identifier. Entities become something by having statements made about them that are also called claims within the architecture. This is what makes it a knowledge system. The claims are not facts; they are assertions made by their contributors. A user can choose to trust or not trust a particular claim based on whatever is recorded directly with the claim. Important factors in making a judgment about what to trust include:
SELECT ?item ?itemLabel ?mrds_code ?mindat_id
* how the property used to make the statement is defined through references and qualifiers (do you trust the source?)
WHERE {
* who made the assertion and how it was made - personal entry, actions of a bot backed by open and accessible software code, etc.
  ?item wdt:P1 wd:Q406 .
  ?item p:P1 ?instance_statement .
  OPTIONAL {
    ?instance_statement pq:P19 ?mrds_code .
  }
  OPTIONAL {
    ?instance_statement pq:P99 ?mindat_id .
  }
  SERVICE wikibase:label { bd:serviceParam wikibase:language "en" . }
}
</sparql>


Entities can also have multiple claims made about the same thing - multiple values for the same property. This can be a way of recording competing claims about the same phenomenon, which is a common reality in data integration work. Different sources of information about the same entities such as mining projects can have differing information about the entities. Together they may provide a more thorough picture of the whole, and/or one source can prove to be more trustworthy than another.
=== Mines ===
This query searches for the first 100 items representing mines with their names, identifiers, and point coordinates (which are a mappable WKT point that can be pulled into a mapping application).


The needs of the user or purpose of a query can also drive the selection of appropriate claims that are most fit for purpose. By surfacing as many claims as possible and assembling them into a common graph, we can give users the power to make judgment calls about what's most appropriate for their use. The SPARQL query that is executed encapsulates the logic, and users can explain their reasoning in whatever venue the query is shared (e.g., code notebook, research paper, etc.).
* [[Item_talk:Q3646|Mine discussion]]


Too often, these judgments are made in the background without a sufficient record describing the reasoning. We have thousands of examples of individual scientific datasets developed this way without granular enough information for the next scientist to make their own reasoned decisions upon. We're interested in how the knowledgebase approach helps us correct that dynamic in our work.
<sparql tryit="1">
PREFIX wd: <https://geokb.wikibase.cloud/entity/>
PREFIX wdt: <https://geokb.wikibase.cloud/prop/direct/>


= Knowledgebase Development =
SELECT ?mine ?mineLabel ?coordinate_location
WHERE {
  ?mine wdt:P1 wd:Q3646 .
  ?mine wdt:P6 ?coordinate_location .
  SERVICE wikibase:label { bd:serviceParam wikibase:language "en" . }
}
LIMIT 100
</sparql>


We are taking advantage of building the GeoKB within the Wikibase/Wikimedia tech platform to use other features available here for development. Notable are the discussion pages on items and properties where we can capture development work centered on those concepts. This is all very much a work in progress. While we have some formal ontologies and models to draw from, much of the content we are working to organize here is based in other types of discrete and not particularly well connected datasets or less structured forms.
==== Geospatial Search for Mines ====
The following query finds mines within a 10km radius of the specified point (This uses a built in functionality found in the GeoKB, specified in the [https://www.mediawiki.org/wiki/Wikidata_Query_Service/User_Manual/el#Geospatial_search| Mediawiki docs]).
<sparql tryit="1">
PREFIX wd: <https://geokb.wikibase.cloud/entity/>
PREFIX wdt: <https://geokb.wikibase.cloud/prop/direct/>


A central point of discussion and directory off to other parts of the framework where we are developing concepts and structure is found on the [[SPARQL examples|SPARQL examples]] page. Visit that page for a description of the major entity types, example queries associated with those entities, and links to deeper level details on the technical development.
SELECT ?item ?itemLabel ?location ?distance
WHERE {
  ?item wdt:P1 wd:Q3646 .
  SERVICE wikibase:around {
      ?item wdt:P6 ?location .  
      bd:serviceParam wikibase:center "POINT(-87.107680869 33.10434839)"^^geo:wktLiteral .
      bd:serviceParam wikibase:radius "10" .
      bd:serviceParam wikibase:distance ?distance.
  }
  SERVICE wikibase:label { bd:serviceParam wikibase:language "en" . }
}
ORDER BY ASC(?distance)
</sparql>


= Partnering =


In USGS, we are committed to the goals and ideals of open science and are working to improve our practices in line with those principles. We don't as yet have a formal route to collaborate on this particular project, but we're working to introduce it and bring it into the community for collaboration via the Earth Science Information Partners ([https://esipfed.org ESIP]). Look for a presentation on this work at the ESIP Summer Meeting in Burlington, VT in July, 2023.
=== Mining Facility ===
As we continue to evolve the model for how we organize information and knowledge about mining in the GeoKB, we are honing in on the need to have specific mining facilities classified and organized as top-level entities that can then be associated with a specific "mining project" as a higher level concept. We established [[Item:Q44143|mining facility]] as a subclass of a more general facility and then a set of more specific subclasses from the USMIN topographic mine symbol digitization project.


= A note about something called iSAID =
There is a class of mining facility for [[Item:Q36466|mine]], which is what we used to classify all of the mine feature classes we pulled from GNIS. We will either continue to use that as a specific type of mining facility and use "mining project," "mining prospect," or something else as the higher level container or else elevate and reclassify "mine" to mean something else.


An earlier effort in building a graph-based knowledgebase structure was something we called iSAID. This was a somewhat tongue-in-cheek name that stands for the Integrated Science Assessment Information Database. iSAID was motivated by the need to comprehensively look across the USGS at our entire scientific portfolio to characterize and understand our capacity to pursue new scientific objectives. The nodes in the iSAID graph include people, organizations, projects, publications, datasets, and models. iSAID is still a going concern, and we're now working on bringing the public aspect of iSAID (which is about 90% or more) into the Wikibase model here. We need all of those same entities represented in the knowledgebase for the other use cases we are pursuing.
* [[EntitySchema:E3|Mining Facility Schema]]
* [[Item_talk:Q44143|Mining Facility discussion page]]


= Disclaimer =
The following query returns the mining facility classification.


This is an experimental effort that will only deal with an organization and portrayal of already publicly available data, information, and knowledge. Everything we incorporate here, directly attributable to the USGS, is from officially released, peer reviewed material. Our pathway from institutional knowledge development processes to releasable data, software, and knowledge products is guided by policies in our [https://www.usgs.gov/office-of-science-quality-and-integrity/fundamental-science-practices Fundamental Science Practices]. How these policies are applied to what is a very different form in an integrated knowledgebase is part of our experimentation and development work.
<sparql tryit="1">
PREFIX wd: <https://geokb.wikibase.cloud/entity/>
PREFIX wdt: <https://geokb.wikibase.cloud/prop/direct/>
 
SELECT ?item ?itemLabel
WHERE {
  ?item wdt:P2* wd:Q44143 . # subclass of (transitive) mining facility
  SERVICE wikibase:label { bd:serviceParam wikibase:language "en" . }
}
</sparql>
 
=== Rock Classification ===
We've started the GeoKB understanding of rock classification via the Mindat system. We will likely augment this over time with other interpretations and classification systems, but since we are pulling minerals from Mindat and want to link to rock types included in those records, starting with Mindat made some sense. The following queries show a bit of how to work with the classification itself in addition to what we link to specific classes.
 
==== Igneous Rocks ====
The following query starts with igneous rock and pulls the full classification from that point (* on the end of the predicate). Because we pull identifiers in this, you can use something like the graph view in Wikibase to visualize and explore the items through their connections.
 
<sparql tryit="1">
PREFIX wd: <https://geokb.wikibase.cloud/entity/>
PREFIX wdt: <https://geokb.wikibase.cloud/prop/direct/>
 
SELECT ?rock ?rockLabel ?subclass_of
WHERE {
  ?rock wdt:P2* wd:Q41459 .
  ?rock wdt:P2 ?subclass_of .
  SERVICE wikibase:label { bd:serviceParam wikibase:language "en" . }
}
</sparql>
 
==== Items that are an instance of multiple things at the same time ====
 
One of the things we are experimenting with that is geared toward making the knowledge content in the GeoKB more transferrable to non-expert domains like the global knowledge commons is somewhat counter to how Mindat has handled the situation. Many of the things that we would give the same basic label are actually different things in different circumstances/contexts. We're experimenting with focusing on the label and then asserting that the entity can be an instance of multiple things. This probably violates some semantic modeling rules, so it may or may not stand the test of time. But it's a thought experiment in motion. The following query focuses in on commodities, pulling those that have more than one instance of claim.
 
<sparql tryit="1">
PREFIX wd: <https://geokb.wikibase.cloud/entity/>
PREFIX wdt: <https://geokb.wikibase.cloud/prop/direct/>
 
SELECT ?item ?itemLabel (COUNT(?instance_of) AS ?num_instance_of)
WHERE {
  ?item wdt:P1 wd:Q406 ;
          wdt:P1 ?instance_of .
  SERVICE wikibase:label { bd:serviceParam wikibase:language "en" . }
}
GROUP BY ?item ?itemLabel
HAVING (COUNT(?instance_of) > 1)
</sparql>
 
==== Mindat Identifiers ====
We are using Mindat as a key reference for a number of things (rocks, minerals, etc.). The Mindat identifier provides the linkage back to Mindat for gathering additional information on the subject items. Mindat IDs are incorporates as a qualifier on the instance of statements made for items sourced from the Mindat API. The following query is one example of how to return rock items with their Mindat IDs.
 
<sparql tryit="1">
PREFIX wd: <https://geokb.wikibase.cloud/entity/>
PREFIX wdt: <https://geokb.wikibase.cloud/prop/direct/>
PREFIX p: <https://geokb.wikibase.cloud/prop/>
PREFIX pq: <https://geokb.wikibase.cloud/prop/qualifier/>
 
SELECT ?item ?itemLabel ?mindat_id
WHERE {
  ?item wdt:P1 wd:Q41261 . # "instance of" "rock"
  OPTIONAL {
    ?item p:P1 ?statement . # Get the instance of statement to operate on
    OPTIONAL { ?statement pq:P99 ?mindat_id . } # Pull the Mindat ID qualifier as a value
  }
  SERVICE wikibase:label { bd:serviceParam wikibase:language "en" . }
}
LIMIT 10
</sparql>
 
=== Mineral-related Items Classified Multiple Ways ===
We've made a design decision in the GeoKB with items that we refer to in common usage to only declare or instantiate these entities with one, uniquely identified item that is then classified and characterized to indicate the different ways the concept can be used. An example of this are items that can be a mineral, a mineral commodity, and a chemical element. This is essentially dealing with the issue of the same word or phrase meaning different things in different contexts. The alternative would be to declare separate entities, each with their own specific classification and other characteristics, and then use relationships between the different items or disambiguation features in the knowledgebase to distinguish between them. We will have to determine exactly which approach makes the most sense in practical use over time.
 
The following query searches for items that are classified as chemical element, mineral, and mineral commodity in the same logical labeled entity.
 
<sparql tryit=1>
PREFIX wd: <https://geokb.wikibase.cloud/entity/>
PREFIX wdt: <https://geokb.wikibase.cloud/prop/direct/>
 
SELECT ?commodity ?commodityLabel ?instance_ofLabel
WHERE {
  ?commodity wdt:P1 wd:Q406;
            wdt:P1 wd:Q280;
            wdt:P1 wd:Q24 .
  ?commodity wdt:P1 ?instance_of .
  SERVICE wikibase:label { bd:serviceParam wikibase:language "en" . }
}
</sparql>
 
== Organizations ==
Entities representing organizations are important in the GeoKB in a couple of areas. We have information on entities such as publications and projects connected to USGS "sub-organizations" such as Science Centers and Labs. We also have information associated with external organizations such as mining companies used to retrieve and organize prospecting history for mineral resource assessments.
 
* [[EntitySchema:E2|Organization EntitySchema]]
 
The following query retrieves information on organization entities that are characterized as "part of" the [[Item:Q44210|U.S. Geological Survey]]. Because we often need to lookup an organization based on imperfect identifiers like name and url variations, this query may return multiple records for each entity with different URLs and aliases. This allows us to efficiently figure out if we already have a label or URL variant included for linking purposes. (This is still a work in progress as we have an incomplete record of USGS organizations of interest and are working to harmonize across several sources.)
 
<sparql tryit=1>
PREFIX wd: <https://geokb.wikibase.cloud/entity/>
PREFIX wdt: <https://geokb.wikibase.cloud/prop/direct/>
 
SELECT ?item ?itemLabel ?item_alt_label ?instance_ofLabel ?url
WHERE {
  ?org_types wdt:P2 wd:Q50862 . # Gets subclasses of USGS organization
  ?item wdt:P1 ?org_types . # Gets items in those classes
  ?item wdt:P1 ?instance_of . # Gets the individual instance of classification
  OPTIONAL {
    ?item skos:altLabel ?item_alt_label .
    FILTER (lang(?item_alt_label)='en')
  }
  OPTIONAL {
    ?item wdt:P31 ?url . # Get all reference URLs when available
  }
  SERVICE wikibase:label { bd:serviceParam wikibase:language "en" . }
}
</sparql>
 
== People ==
Items representing people associated with the USGS are another type of entity built out in the GeoKB. We use these as reference points and connections to the overall scientific record captured in this knowledge graph. Person records come from public sources such as our USGS Staff Profiles and are further discussed on the [[Item_talk:Q3|person classification talk page]].
 
* [[EntitySchema:E1|Person EntitySchema]]
 
=== People by employer ===
This query pulls all people along with their email address (already publicly visible) and reference URL (pointer to USGS staff profile).
 
<sparql tryit="1">
PREFIX wd: <https://geokb.wikibase.cloud/entity/>
PREFIX wdt: <https://geokb.wikibase.cloud/prop/direct/>
 
SELECT ?item ?itemLabel ?email ?profile_url ?orcid
WHERE {
  ?item wdt:P1 wd:Q3 .
  ?item wdt:P107 wd:Q44210 .
  OPTIONAL {
    ?item wdt:P109 ?email .
  }
  OPTIONAL {
    ?item wdt:P31 ?profile_url .
  }
  OPTIONAL {
    ?item wdt:P106 ?orcid .
  }
  SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". }
}
LIMIT 10000
</sparql>
 
== Places ==
The GeoKB includes references for many named places that are necessary links from many other items. The following are some examples for this part of the knowledgebase.
 
=== U.S. States and Territories ===
 
<sparql tryit="1">
PREFIX wdt: <https://geokb.wikibase.cloud/prop/direct/>
 
SELECT ?item ?itemLabel ?fips_alpha
WHERE {
  ?item wdt:P13 ?fips_alpha .  # Both states and territories in the U.S. have two-character FIPS codes
  SERVICE wikibase:label { bd:serviceParam wikibase:language "en" . }
}
</sparql>
 
=== U.S. Counties or Equivalent Subdivision ===
 
<sparql tryit="1">
PREFIX wd: <https://geokb.wikibase.cloud/entity/>
PREFIX wdt: <https://geokb.wikibase.cloud/prop/direct/>
 
SELECT ?item ?itemLabel ?fips_code ?coordinates
WHERE {
  ?item wdt:P1 wd:Q481 . # "instance of" "county or equivalent"
  ?item wdt:P34 wd:Q256 . # in the state of Colorado
  ?item wdt:P22 ?fips_code .
  ?item wdt:P6 ?coordinates .
  SERVICE wikibase:label { bd:serviceParam wikibase:language "en" . }
}
</sparql>
 
== Documents ==
Another fundamental entity type we are bringing together in the GeoKB are representations of documents of one kind or another. For right now, we put "document" right at the top of the classification as a foundational type of "entity." You can query for the classification structure for documents with the following transitive query from the document root.
 
<sparql tryit="1">
PREFIX wd: <https://geokb.wikibase.cloud/entity/>
PREFIX wdt: <https://geokb.wikibase.cloud/prop/direct/>
 
SELECT ?item ?itemLabel
WHERE {
  ?item wdt:P2* wd:Q5 . # subclass of, transitive "document"
  SERVICE wikibase:label { bd:serviceParam wikibase:language "en" . }
}
</sparql>
 
You'll see here that we've laid out things like the classification of USGS Report Series as we work to bring in a representation for all USGS reports as one suite of document assets we often need to reference and link to from other entities.
 
=== USGS Series Reports ===
 
The "USGS Numbered Reports Series" are an important reference source in the GeoKB for many other things we are working on. We are building a process to keep a representation of USGS reports in sync from the USGS Publications Warehouse source, starting with a smaller subset important to current use cases. The the different USGS numbered series are part of a classification of documents. The following query uses that classification to pull all USGS reports and specific claims.
 
* [[Item_talk:Q11|USGS Series Reports discussion]]
 
<sparql tryit="1">
PREFIX wd: <https://geokb.wikibase.cloud/entity/>
PREFIX wdt: <https://geokb.wikibase.cloud/prop/direct/>
 
SELECT ?item ?itemLabel ?itemAltLabel ?pub_year ?doi
?pw_index_id ?country ?countryLabel ?us_state ?us_stateLabel
?county ?countyLabel
WHERE {
  ?item wdt:P1/wdt:P2* wd:Q11 .
  OPTIONAL {
    ?item wdt:P7 ?pub_year .
  }
  OPTIONAL {
    ?item wdt:P74 ?doi .
  }
  OPTIONAL {
    ?item wdt:P114 ?pw_index_id .
  }
  OPTIONAL {
    ?item wdt:P33 ?country .
  }
  OPTIONAL {
    ?item wdt:P34 ?us_state .
  }
  OPTIONAL {
    ?item wdt:P35 ?county .
  }
  SERVICE wikibase:label { bd:serviceParam wikibase:language "en" . }
}
</sparql>
 
=== NI 43-101 Technical Reports ===
These are a special type of document that is part of an early use case for the GeoKB. We manage the metadata and stored document content for these reports in a Zotero collection as part of the GeoArchive, and create a representation of basic identification information in the GeoKB for knowledge graph purposes. The following query pulls 100 NI 43-101 Technical Report entities and a couple of pieces from their claims as an example.
 
<sparql tryit="1">
PREFIX wd: <https://geokb.wikibase.cloud/entity/>
PREFIX wdt: <https://geokb.wikibase.cloud/prop/direct/>
 
SELECT ?item ?itemLabel ?url ?addresses_place ?addresses_placeLabel
WHERE {
  ?item wdt:P1 wd:Q10 . # instance of NI 43-101 Technical Report
  ?item wdt:P31 ?url .
  OPTIONAL {
    ?item wdt:P95 ?addresses_place .
  }
  SERVICE wikibase:label { bd:serviceParam wikibase:language "en" . }
}
LIMIT 100
</sparql>
 
= Properties =
Properties in the Wikibase instance are what connects subjects (entities) and objects (other objects or different kinds of values). We sometimes have the need to query for properties themselves and can do that via SPARQL. You can also browse the list of [[Special:ListProperties|all properties]].
 
<sparql tryit="1">
SELECT ?property ?propertyLabel ?property_type WHERE {
  ?property a wikibase:Property .
  ?property wikibase:propertyType ?property_type .
  SERVICE wikibase:label { bd:serviceParam wikibase:language "en" . }
}
</sparql>
 
= Linkages =
The whole point of what we're doing here in the GeoKB is to develop organized knowledge about the complex earth system and its interconnections as it touches on the domains of science covered by the USGS and our partners. As such, the links we develop between this system and other systems are perhaps the most vital component. We are not attempting to rebuild data, information, and knowledge already organized elsewhere, though we may develop a recasting-in-context here within the GeoKB in order to make better sense of things we link to in other contexts. This section discusses the specific system to system linkages we are developing as we continue pursuing use cases and analytical needs.
 
== Mindat ==
 
An initial focus of the GeoKB is on use cases related to mineral resource assessment work in the USGS. While USGS is an authoritative source for certain types of geoscientific information related to our mission, there are better global authorities we can connect with to leverage the pieces of information we need to link with. [https://mindat.org Mindat] is our source for information on the following:
 
* [https://www.mindat.org/minerals.php minerals]
* [https://www.mindat.org/min-50468.html rock names/classification]
* commodities (mostly mineral related)
 
For the most part, we are only leveraging names (labels) and short descriptions along with the associated identifiers for these entities. We also incorporate relationships such as the classification of rocks. If we need additional details that Mindat provides, we can always go back to the source for more properties.
 
== xDD (aka GeoDeepDive) ==
The [https://geodeepdive.org xDD framework] from collaborators at the University of Wisconsin-Madison provides a platform where we are processing collections of documents that you will find represented in the GeoKB. This includes a long-standing partnership that continually feeds USGS Series Publications into processing pipelines as well as newer collections coming from our GeoArchive work (e.g., NI 43-101 Technical Reports). xDD processing develops additional claims from both relatively mundane search indexing as well as more advanced entity recognition and AI assisted processing. The GeoKB becomes the place where entity recognition becomes entity linking as we confirm recognized entities as viable and record them as claims/links on the entities representing the associated documents. The [[Property:P93|gddid property]] houses the persistent, resolvable identifier used in doc_id and other queries with the xDD APIs. We are working on documenting sources associated with xDD and will get those refined to be associated as references for claims.
 
This query returns 100 items that have a GDDID. The formatter URL for the GDDID as an external identifier points to the xDD API end point for the "article" - a basic rendering of the citation metadata.
 
<sparql tryit="1">
PREFIX wdt: <https://geokb.wikibase.cloud/prop/direct/>
 
SELECT ?item ?itemLabel ?gddid
WHERE {
  ?item wdt:P93 ?gddid .
  SERVICE wikibase:label { bd:serviceParam wikibase:language "en" . }
}
LIMIT 100
</sparql>
 
= GeoKB Logistics/Specifications =
 
== Prefixes/Namespaces ==
SPARQL queries and work with RDF in general requires uses the concept of a short prefix string representing a URI to resolve an identifier. Prefix declaration in a query lets us use the short strings in place of constantly putting in a fully qualified and resolvable path. The wikibase.cloud folks have taken the stance that prefixes should always be explicitly declared as opposed to being in the default configuration for queries, which is good practice but a bit of a pain. Here is a rundown of the full set of prefixes for this Wikibase instance. You'll see the applicable prefixes from this exhaustive list in the query examples.
 
<sparql>
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix wikibase: <http://wikiba.se/ontology#> .
@prefix skos: <http://www.w3.org/2004/02/skos/core#> .
@prefix schema: <http://schema.org/> .
@prefix cc: <http://creativecommons.org/ns#> .
@prefix geo: <http://www.opengis.net/ont/geosparql#> .
@prefix prov: <http://www.w3.org/ns/prov#> .
@prefix wd: <https://geokb.wikibase.cloud/entity/> .
@prefix data: <https://geokb.wikibase.cloud/wiki/Special:EntityData/> .
@prefix s: <https://geokb.wikibase.cloud/entity/statement/> .
@prefix ref: <https://geokb.wikibase.cloud/reference/> .
@prefix v: <https://geokb.wikibase.cloud/value/> .
@prefix wdt: <https://geokb.wikibase.cloud/prop/direct/> .
@prefix wdtn: <https://geokb.wikibase.cloud/prop/direct-normalized/> .
@prefix p: <https://geokb.wikibase.cloud/prop/> .
@prefix ps: <https://geokb.wikibase.cloud/prop/statement/> .
@prefix psv: <https://geokb.wikibase.cloud/prop/statement/value/> .
@prefix psn: <https://geokb.wikibase.cloud/prop/statement/value-normalized/> .
@prefix pq: <https://geokb.wikibase.cloud/prop/qualifier/> .
@prefix pqv: <https://geokb.wikibase.cloud/prop/qualifier/value/> .
@prefix pqn: <https://geokb.wikibase.cloud/prop/qualifier/value-normalized/> .
@prefix pr: <https://geokb.wikibase.cloud/prop/reference/> .
@prefix prv: <https://geokb.wikibase.cloud/prop/reference/value/> .
@prefix prn: <https://geokb.wikibase.cloud/prop/reference/value-normalized/> .
@prefix wdno: <https://geokb.wikibase.cloud/prop/novalue/> .
</sparql>

Revision as of 21:43, 28 July 2023

The Geoscience Knowledgebase is an experimental effort to encode all information and knowledge from the USGS scientific portfolio in earth systems science. It is a compelling idea to have domain-specific knowledge graphs sitting online and accessible to anyone that are "adjacent" to Wikidata but separate in that they are maintained by a group with vested interest in building them and using them in practice. As a government science institution, we have our own requirements on how we need to manage our information, and we likely don't want to have us government folks messing about directly in the "Global Knowledge Commons." Rather, our information is donated into the public domain for anyone else to do what they like. Read more about our motivation and background on the project in the About page.

Below, you will find a description of the main entities we are building here. Each section should have an example query that you can use to explore. This is all work in progress, so you'll see new things coming in as we get them worked out. You'll note some links to discussion pages where we are working through the specifics on how to model and encode our information into the graph.

Entities

Entities ("Q" identifiers or items) in the GeoKB are the primary object in the knowledgebase. They are the focus for our knowledge organization scheme. The majority of properties ("P" identifiers) have an item type classification meaning that the object they connect to a subject entity is another entity in the knowledgebase. The majority of our entities are not "native" to this knowledgebase; rather they are sourced from some other data or information system with the entity in the knowledgebase a basic representation of the "foreign-sourced" item.

Entities are built iteratively over time with software codes used to introduce them to the knowledgebase. We may start an entity representation with only a couple of pieces of information, with the bare minimum being a label, description, and either an "instance of" or "subclass of" claim, depending on the purpose of the entity in the knowledgebase. We also describe source material as entities classified as "knowledgebase source." Claims (or statements) made about an entity should always have at least one reference that essentially cites the source for the statement. These will often point to a "knowledgebase source" item or may use "reference URL" when the reference source is simply a single linkable online resource. Over time, we may revisit the initial starter code that introduced an entity to the knowledgebase to change how it operates and bring in further claims. We may also change the nature of how an entity specifies its source by changing of adding to references.

This page serves as iterative documentation of the entities in the knowledgebase with a focus toward how they can be retrieved and interacted with in use through SPARQL queries. It is organized into sections describing a few things about the major entity types. Each section may contain a link to an associated "item talk" page in this Wikibase instance that discusses the evolution of the entity. Each section will also contain a link to the associated ShExC schema for the entity type as those are developed iteratively. Schemas facilitate interactions with the knowledgebase such as ongoing multimodal introduction of new entity instances and claims.

Minerals Related Entities

USNS Mineral Resource Assessment work provides the seminal use cases for the GeoKB. We are using the knowledge graph model to transform and modernize a number of older databases, online tools, and information systems into a interconnected framework that can better scale into the future. The following section lays out the entity types in the GeoKB related to mineral resources and provides some example queries.

Mineral Commodity

The following query pulls items classified as mineral commodity and associated code values from the USGS Mineral Resources Data System and/or Mindat. Not all codes are in place for the items and Mindat codes will be changing to the long-form identifier resolvable at mindat.org.

PREFIX wd: <https://geokb.wikibase.cloud/entity/>
PREFIX wdt: <https://geokb.wikibase.cloud/prop/direct/>
PREFIX p: <https://geokb.wikibase.cloud/prop/>
PREFIX pq: <https://geokb.wikibase.cloud/prop/qualifier/>

SELECT ?item ?itemLabel ?mrds_code ?mindat_id
WHERE {
  ?item wdt:P1 wd:Q406 .
  ?item p:P1 ?instance_statement .
  OPTIONAL {
    ?instance_statement pq:P19 ?mrds_code .
  }
  OPTIONAL {
    ?instance_statement pq:P99 ?mindat_id .
  }
  SERVICE wikibase:label { bd:serviceParam wikibase:language "en" . }
}

Try it!


Mines

This query searches for the first 100 items representing mines with their names, identifiers, and point coordinates (which are a mappable WKT point that can be pulled into a mapping application).

PREFIX wd: <https://geokb.wikibase.cloud/entity/>
PREFIX wdt: <https://geokb.wikibase.cloud/prop/direct/>

SELECT ?mine ?mineLabel ?coordinate_location
WHERE {
  ?mine wdt:P1 wd:Q3646 .
  ?mine wdt:P6 ?coordinate_location .
  SERVICE wikibase:label { bd:serviceParam wikibase:language "en" . }
}
LIMIT 100

Try it!


Geospatial Search for Mines

The following query finds mines within a 10km radius of the specified point (This uses a built in functionality found in the GeoKB, specified in the Mediawiki docs).

PREFIX wd: <https://geokb.wikibase.cloud/entity/>
PREFIX wdt: <https://geokb.wikibase.cloud/prop/direct/>

SELECT ?item ?itemLabel ?location ?distance
WHERE {
  ?item wdt:P1 wd:Q3646 .
  SERVICE wikibase:around { 
      ?item wdt:P6 ?location . 
      bd:serviceParam wikibase:center "POINT(-87.107680869 33.10434839)"^^geo:wktLiteral . 
      bd:serviceParam wikibase:radius "10" . 
      bd:serviceParam wikibase:distance ?distance.
  }
  SERVICE wikibase:label { bd:serviceParam wikibase:language "en" . }
}
ORDER BY ASC(?distance)

Try it!


Mining Facility

As we continue to evolve the model for how we organize information and knowledge about mining in the GeoKB, we are honing in on the need to have specific mining facilities classified and organized as top-level entities that can then be associated with a specific "mining project" as a higher level concept. We established mining facility as a subclass of a more general facility and then a set of more specific subclasses from the USMIN topographic mine symbol digitization project.

There is a class of mining facility for mine, which is what we used to classify all of the mine feature classes we pulled from GNIS. We will either continue to use that as a specific type of mining facility and use "mining project," "mining prospect," or something else as the higher level container or else elevate and reclassify "mine" to mean something else.

The following query returns the mining facility classification.

PREFIX wd: <https://geokb.wikibase.cloud/entity/>
PREFIX wdt: <https://geokb.wikibase.cloud/prop/direct/>

SELECT ?item ?itemLabel
WHERE {
  ?item wdt:P2* wd:Q44143 . # subclass of (transitive) mining facility
  SERVICE wikibase:label { bd:serviceParam wikibase:language "en" . }
}

Try it!


Rock Classification

We've started the GeoKB understanding of rock classification via the Mindat system. We will likely augment this over time with other interpretations and classification systems, but since we are pulling minerals from Mindat and want to link to rock types included in those records, starting with Mindat made some sense. The following queries show a bit of how to work with the classification itself in addition to what we link to specific classes.

Igneous Rocks

The following query starts with igneous rock and pulls the full classification from that point (* on the end of the predicate). Because we pull identifiers in this, you can use something like the graph view in Wikibase to visualize and explore the items through their connections.

PREFIX wd: <https://geokb.wikibase.cloud/entity/>
PREFIX wdt: <https://geokb.wikibase.cloud/prop/direct/>

SELECT ?rock ?rockLabel ?subclass_of
WHERE {
  ?rock wdt:P2* wd:Q41459 .
  ?rock wdt:P2 ?subclass_of .
  SERVICE wikibase:label { bd:serviceParam wikibase:language "en" . }
}

Try it!


Items that are an instance of multiple things at the same time

One of the things we are experimenting with that is geared toward making the knowledge content in the GeoKB more transferrable to non-expert domains like the global knowledge commons is somewhat counter to how Mindat has handled the situation. Many of the things that we would give the same basic label are actually different things in different circumstances/contexts. We're experimenting with focusing on the label and then asserting that the entity can be an instance of multiple things. This probably violates some semantic modeling rules, so it may or may not stand the test of time. But it's a thought experiment in motion. The following query focuses in on commodities, pulling those that have more than one instance of claim.

PREFIX wd: <https://geokb.wikibase.cloud/entity/>
PREFIX wdt: <https://geokb.wikibase.cloud/prop/direct/>

SELECT ?item ?itemLabel (COUNT(?instance_of) AS ?num_instance_of)
WHERE {
  ?item wdt:P1 wd:Q406 ;
          wdt:P1 ?instance_of .
  SERVICE wikibase:label { bd:serviceParam wikibase:language "en" . }
}
GROUP BY ?item ?itemLabel
HAVING (COUNT(?instance_of) > 1)

Try it!


Mindat Identifiers

We are using Mindat as a key reference for a number of things (rocks, minerals, etc.). The Mindat identifier provides the linkage back to Mindat for gathering additional information on the subject items. Mindat IDs are incorporates as a qualifier on the instance of statements made for items sourced from the Mindat API. The following query is one example of how to return rock items with their Mindat IDs.

PREFIX wd: <https://geokb.wikibase.cloud/entity/>
PREFIX wdt: <https://geokb.wikibase.cloud/prop/direct/>
PREFIX p: <https://geokb.wikibase.cloud/prop/>
PREFIX pq: <https://geokb.wikibase.cloud/prop/qualifier/> 

SELECT ?item ?itemLabel ?mindat_id
WHERE {
  ?item wdt:P1 wd:Q41261 . # "instance of" "rock"
  OPTIONAL {
    ?item p:P1 ?statement . # Get the instance of statement to operate on
    OPTIONAL { ?statement pq:P99 ?mindat_id . } # Pull the Mindat ID qualifier as a value
  }
  SERVICE wikibase:label { bd:serviceParam wikibase:language "en" . }
}
LIMIT 10

Try it!


Mineral-related Items Classified Multiple Ways

We've made a design decision in the GeoKB with items that we refer to in common usage to only declare or instantiate these entities with one, uniquely identified item that is then classified and characterized to indicate the different ways the concept can be used. An example of this are items that can be a mineral, a mineral commodity, and a chemical element. This is essentially dealing with the issue of the same word or phrase meaning different things in different contexts. The alternative would be to declare separate entities, each with their own specific classification and other characteristics, and then use relationships between the different items or disambiguation features in the knowledgebase to distinguish between them. We will have to determine exactly which approach makes the most sense in practical use over time.

The following query searches for items that are classified as chemical element, mineral, and mineral commodity in the same logical labeled entity.

PREFIX wd: <https://geokb.wikibase.cloud/entity/>
PREFIX wdt: <https://geokb.wikibase.cloud/prop/direct/>

SELECT ?commodity ?commodityLabel ?instance_ofLabel
WHERE {
  ?commodity wdt:P1 wd:Q406;
             wdt:P1 wd:Q280;
             wdt:P1 wd:Q24 .
  ?commodity wdt:P1 ?instance_of .
  SERVICE wikibase:label { bd:serviceParam wikibase:language "en" . }
}

Try it!


Organizations

Entities representing organizations are important in the GeoKB in a couple of areas. We have information on entities such as publications and projects connected to USGS "sub-organizations" such as Science Centers and Labs. We also have information associated with external organizations such as mining companies used to retrieve and organize prospecting history for mineral resource assessments.

The following query retrieves information on organization entities that are characterized as "part of" the U.S. Geological Survey. Because we often need to lookup an organization based on imperfect identifiers like name and url variations, this query may return multiple records for each entity with different URLs and aliases. This allows us to efficiently figure out if we already have a label or URL variant included for linking purposes. (This is still a work in progress as we have an incomplete record of USGS organizations of interest and are working to harmonize across several sources.)

PREFIX wd: <https://geokb.wikibase.cloud/entity/>
PREFIX wdt: <https://geokb.wikibase.cloud/prop/direct/>

SELECT ?item ?itemLabel ?item_alt_label ?instance_ofLabel ?url
WHERE {
  ?org_types wdt:P2 wd:Q50862 . # Gets subclasses of USGS organization
  ?item wdt:P1 ?org_types . # Gets items in those classes
  ?item wdt:P1 ?instance_of . # Gets the individual instance of classification
  OPTIONAL {
    ?item skos:altLabel ?item_alt_label .
    FILTER (lang(?item_alt_label)='en')
  }
  OPTIONAL {
    ?item wdt:P31 ?url . # Get all reference URLs when available
  }
  SERVICE wikibase:label { bd:serviceParam wikibase:language "en" . }
}

Try it!


People

Items representing people associated with the USGS are another type of entity built out in the GeoKB. We use these as reference points and connections to the overall scientific record captured in this knowledge graph. Person records come from public sources such as our USGS Staff Profiles and are further discussed on the person classification talk page.

People by employer

This query pulls all people along with their email address (already publicly visible) and reference URL (pointer to USGS staff profile).

PREFIX wd: <https://geokb.wikibase.cloud/entity/>
PREFIX wdt: <https://geokb.wikibase.cloud/prop/direct/>

SELECT ?item ?itemLabel ?email ?profile_url ?orcid
WHERE {
  ?item wdt:P1 wd:Q3 .
  ?item wdt:P107 wd:Q44210 .
  OPTIONAL {
    ?item wdt:P109 ?email .
  }
  OPTIONAL {
    ?item wdt:P31 ?profile_url .
  }
  OPTIONAL {
    ?item wdt:P106 ?orcid .
  }
  SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". }
}
LIMIT 10000

Try it!


Places

The GeoKB includes references for many named places that are necessary links from many other items. The following are some examples for this part of the knowledgebase.

U.S. States and Territories

PREFIX wdt: <https://geokb.wikibase.cloud/prop/direct/>

SELECT ?item ?itemLabel ?fips_alpha
WHERE {
  ?item wdt:P13 ?fips_alpha .  # Both states and territories in the U.S. have two-character FIPS codes
  SERVICE wikibase:label { bd:serviceParam wikibase:language "en" . }
}

Try it!


U.S. Counties or Equivalent Subdivision

PREFIX wd: <https://geokb.wikibase.cloud/entity/>
PREFIX wdt: <https://geokb.wikibase.cloud/prop/direct/>

SELECT ?item ?itemLabel ?fips_code ?coordinates
WHERE {
  ?item wdt:P1 wd:Q481 . # "instance of" "county or equivalent"
  ?item wdt:P34 wd:Q256 . # in the state of Colorado
  ?item wdt:P22 ?fips_code .
  ?item wdt:P6 ?coordinates .
  SERVICE wikibase:label { bd:serviceParam wikibase:language "en" . }
}

Try it!


Documents

Another fundamental entity type we are bringing together in the GeoKB are representations of documents of one kind or another. For right now, we put "document" right at the top of the classification as a foundational type of "entity." You can query for the classification structure for documents with the following transitive query from the document root.

PREFIX wd: <https://geokb.wikibase.cloud/entity/>
PREFIX wdt: <https://geokb.wikibase.cloud/prop/direct/>

SELECT ?item ?itemLabel
WHERE {
  ?item wdt:P2* wd:Q5 . # subclass of, transitive "document"
  SERVICE wikibase:label { bd:serviceParam wikibase:language "en" . }
}

Try it!


You'll see here that we've laid out things like the classification of USGS Report Series as we work to bring in a representation for all USGS reports as one suite of document assets we often need to reference and link to from other entities.

USGS Series Reports

The "USGS Numbered Reports Series" are an important reference source in the GeoKB for many other things we are working on. We are building a process to keep a representation of USGS reports in sync from the USGS Publications Warehouse source, starting with a smaller subset important to current use cases. The the different USGS numbered series are part of a classification of documents. The following query uses that classification to pull all USGS reports and specific claims.

PREFIX wd: <https://geokb.wikibase.cloud/entity/>
PREFIX wdt: <https://geokb.wikibase.cloud/prop/direct/>

SELECT ?item ?itemLabel ?itemAltLabel ?pub_year ?doi 
?pw_index_id ?country ?countryLabel ?us_state ?us_stateLabel
?county ?countyLabel
WHERE {
  ?item wdt:P1/wdt:P2* wd:Q11 .
  OPTIONAL {
    ?item wdt:P7 ?pub_year .
  }
  OPTIONAL {
    ?item wdt:P74 ?doi .
  }
  OPTIONAL {
    ?item wdt:P114 ?pw_index_id .
  }
  OPTIONAL {
    ?item wdt:P33 ?country .
  }
  OPTIONAL {
    ?item wdt:P34 ?us_state .
  }
  OPTIONAL {
    ?item wdt:P35 ?county .
  }
  SERVICE wikibase:label { bd:serviceParam wikibase:language "en" . }
}

Try it!


NI 43-101 Technical Reports

These are a special type of document that is part of an early use case for the GeoKB. We manage the metadata and stored document content for these reports in a Zotero collection as part of the GeoArchive, and create a representation of basic identification information in the GeoKB for knowledge graph purposes. The following query pulls 100 NI 43-101 Technical Report entities and a couple of pieces from their claims as an example.

PREFIX wd: <https://geokb.wikibase.cloud/entity/>
PREFIX wdt: <https://geokb.wikibase.cloud/prop/direct/>

SELECT ?item ?itemLabel ?url ?addresses_place ?addresses_placeLabel
WHERE {
  ?item wdt:P1 wd:Q10 . # instance of NI 43-101 Technical Report
  ?item wdt:P31 ?url .
  OPTIONAL {
    ?item wdt:P95 ?addresses_place .
  }
  SERVICE wikibase:label { bd:serviceParam wikibase:language "en" . }
}
LIMIT 100

Try it!


Properties

Properties in the Wikibase instance are what connects subjects (entities) and objects (other objects or different kinds of values). We sometimes have the need to query for properties themselves and can do that via SPARQL. You can also browse the list of all properties.

SELECT ?property ?propertyLabel ?property_type WHERE {
  ?property a wikibase:Property .
  ?property wikibase:propertyType ?property_type .
  SERVICE wikibase:label { bd:serviceParam wikibase:language "en" . }
}

Try it!


Linkages

The whole point of what we're doing here in the GeoKB is to develop organized knowledge about the complex earth system and its interconnections as it touches on the domains of science covered by the USGS and our partners. As such, the links we develop between this system and other systems are perhaps the most vital component. We are not attempting to rebuild data, information, and knowledge already organized elsewhere, though we may develop a recasting-in-context here within the GeoKB in order to make better sense of things we link to in other contexts. This section discusses the specific system to system linkages we are developing as we continue pursuing use cases and analytical needs.

Mindat

An initial focus of the GeoKB is on use cases related to mineral resource assessment work in the USGS. While USGS is an authoritative source for certain types of geoscientific information related to our mission, there are better global authorities we can connect with to leverage the pieces of information we need to link with. Mindat is our source for information on the following:

For the most part, we are only leveraging names (labels) and short descriptions along with the associated identifiers for these entities. We also incorporate relationships such as the classification of rocks. If we need additional details that Mindat provides, we can always go back to the source for more properties.

xDD (aka GeoDeepDive)

The xDD framework from collaborators at the University of Wisconsin-Madison provides a platform where we are processing collections of documents that you will find represented in the GeoKB. This includes a long-standing partnership that continually feeds USGS Series Publications into processing pipelines as well as newer collections coming from our GeoArchive work (e.g., NI 43-101 Technical Reports). xDD processing develops additional claims from both relatively mundane search indexing as well as more advanced entity recognition and AI assisted processing. The GeoKB becomes the place where entity recognition becomes entity linking as we confirm recognized entities as viable and record them as claims/links on the entities representing the associated documents. The gddid property houses the persistent, resolvable identifier used in doc_id and other queries with the xDD APIs. We are working on documenting sources associated with xDD and will get those refined to be associated as references for claims.

This query returns 100 items that have a GDDID. The formatter URL for the GDDID as an external identifier points to the xDD API end point for the "article" - a basic rendering of the citation metadata.

PREFIX wdt: <https://geokb.wikibase.cloud/prop/direct/>

SELECT ?item ?itemLabel ?gddid
WHERE {
  ?item wdt:P93 ?gddid .
  SERVICE wikibase:label { bd:serviceParam wikibase:language "en" . }
}
LIMIT 100

Try it!


GeoKB Logistics/Specifications

Prefixes/Namespaces

SPARQL queries and work with RDF in general requires uses the concept of a short prefix string representing a URI to resolve an identifier. Prefix declaration in a query lets us use the short strings in place of constantly putting in a fully qualified and resolvable path. The wikibase.cloud folks have taken the stance that prefixes should always be explicitly declared as opposed to being in the default configuration for queries, which is good practice but a bit of a pain. Here is a rundown of the full set of prefixes for this Wikibase instance. You'll see the applicable prefixes from this exhaustive list in the query examples.

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix wikibase: <http://wikiba.se/ontology#> .
@prefix skos: <http://www.w3.org/2004/02/skos/core#> .
@prefix schema: <http://schema.org/> .
@prefix cc: <http://creativecommons.org/ns#> .
@prefix geo: <http://www.opengis.net/ont/geosparql#> .
@prefix prov: <http://www.w3.org/ns/prov#> .
@prefix wd: <https://geokb.wikibase.cloud/entity/> .
@prefix data: <https://geokb.wikibase.cloud/wiki/Special:EntityData/> .
@prefix s: <https://geokb.wikibase.cloud/entity/statement/> .
@prefix ref: <https://geokb.wikibase.cloud/reference/> .
@prefix v: <https://geokb.wikibase.cloud/value/> .
@prefix wdt: <https://geokb.wikibase.cloud/prop/direct/> .
@prefix wdtn: <https://geokb.wikibase.cloud/prop/direct-normalized/> .
@prefix p: <https://geokb.wikibase.cloud/prop/> .
@prefix ps: <https://geokb.wikibase.cloud/prop/statement/> .
@prefix psv: <https://geokb.wikibase.cloud/prop/statement/value/> .
@prefix psn: <https://geokb.wikibase.cloud/prop/statement/value-normalized/> .
@prefix pq: <https://geokb.wikibase.cloud/prop/qualifier/> .
@prefix pqv: <https://geokb.wikibase.cloud/prop/qualifier/value/> .
@prefix pqn: <https://geokb.wikibase.cloud/prop/qualifier/value-normalized/> .
@prefix pr: <https://geokb.wikibase.cloud/prop/reference/> .
@prefix prv: <https://geokb.wikibase.cloud/prop/reference/value/> .
@prefix prn: <https://geokb.wikibase.cloud/prop/reference/value-normalized/> .
@prefix wdno: <https://geokb.wikibase.cloud/prop/novalue/> .