Open ksonda opened 2 years ago
I guess I'm a little confused about the premise here...
Since the relevant domain type is CreativeWork, we can't use it for a NIR or a MIR with a URI.
But the table you put up there is just "Used on these types" -- as in "used in existing schema.org objects". That doesn't seem like it's a strict limit on what it can be used on, right?
There's a sentence from the definition:
Another party (a seller) may offer those services or goods on behalf of the provider.
Another party (geoconnex) may offer those reference features on behalf of the provider.
Right? Maybe I'm thinking at a different level here?
It seems to me that schema:provider
is an appropriate way to decorate a blank node that also has a schema:url
well, we can implement any validation we want on stuff that isn't in schema.org I suppose, but the schema.org validator does not like if the subject of schema:provider is a schema.org Type that is not one of those things
I see. This makes me think we need to take more care in what the @type
is for things that are decorated with schema.org as much as change the predicates we are using.
More generally, I think we are just going to run into some logicaly issues here in general though. schema.org is assuming indirect identification of things like schema:Place. e.g. a resource URL that is "about" a place is thought to be a stand in for a URI for the place. This leads me to question whether "valid" in the schema.org context is really "invalid" in our context?
Wanting to think through this a bit more slowly. We currently have: (this was generated with the jsonld playground)
{
"@id": "https://geoconnex.us/ref/dams/1074846",
"@type": "https://schema.org/Place",
"http://www.opengis.net/ont/geosparql#hasGeometry": {
"@type": "http://www.opengis.net/ont/sf#Point",
"http://www.opengis.net/ont/geosparql#asWKT": {
"@type": "http://www.opengis.net/ont/geosparql#wktLiteral",
"@value": "POINT (-85.89643320731987 44.21302163137249)"
}
},
"https://schema.org/description": "Reference feature for USACE National Inventory of Dams: MI00229",
"https://schema.org/geo": {
"@type": "https://schema.org/GeoCoordinates",
"https://schema.org/latitude": 44.21302163137249,
"https://schema.org/longitude": -85.89643320731987
},
"https://schema.org/name": "Stronach Dam",
"https://schema.org/provider": {
"@type": "https://schema.org/url",
"@value": "https://nid.usace.army.mil"
},
"https://schema.org/subjectOf": {
"@type": "https://schema.org/url",
"@value": "https://nid.usace.army.mil/#/dams/system/489350/summary"
}
}
OK -- so with this, your example does make more sense. We should not be saying that "the provider of a place is an organization".
{
"@id": "https://geoconnex.us/ref/dams/1000002",
"@type": [
"https://www.opengis.net/def/schema/hy_features/hyf/HY_HydrometricFeature",
"https://www.opengis.net/def/schema/hy_features/hyf/HY_HydroLocation",
"https://schema.org/Place"
],
"https://schema.org/description": "Reference feature for USACE National Inventory of Dams: MS02525",
"https://schema.org/name": "Lake Wilhelmina Dam",
"https://schema.org/subjectOf": [
{
"@id": "https://doi.org/10.5066/P92S9ZX6",
"@type": "https://schema.org/Dataset",
"https://schema.org/isBasedOn": {
"@type": "https://schema.org/Dataset",
"https://schema.org/url": "https://nid.usace.army.mil/#/downloads"
}
},
{
"@type": "https://schema.org/WebPage",
"https://schema.org/provider": "https://nid.usace.army.mil/",
"https://schema.org/url": "https://nid.usace.army.mil/#/dams/system/501234/summary"
}
]
}
We have been using schema:provider for how a MIR for a reference feature links to
and subjectOf for
Technically,
schema:provider
is basically meant for business-type activities, and has domainSince the relevant domain type is CreativeWork, we can't use it for a NIR or a MIR with a URI. Particularly with reference features, I think we have to use a pretty specific combination of
schema:subjectOf
,schema:provider
, andschema:isBasedOn
to properly document what we mean by "this record is related to this record which came from here originally"something like
This will need to be updated in all templates, documentation, and in deployed reference features