Meta Resource structure

bsimons14 commented 4 years ago

Previous issues #100 #94 etc have discussed this ad nauseum. However, at the risk of opening the issue again (and in the face of Dave's request to only close issues!) the final decision about what goes under schema:sameAs and schema:subjectOf was left to the whim of the data provider. At the moment FedUni has three versions of the Meta Resource structure and I'd like to think we can agree on one of these. Or at least be told which pattern is preferred. Note that the representations are all 'in-band'. I think the third option reduces the flexibility allowed by data providers, thereby increasing the standardization. For a resource "@type": "gw:GW_Well",

All json-ld 'similar' resources are under "sameAs". e.g. all of these "@type": "gw:GW_Well", "@type": "gw:Borehole","@type": "gs:Borehole", "@type": "sosa:ObservationCollection" The current FedUni SELFIE services deliver this structure.
Only those resources which are the same as the @type are allowed under "sameAs" e.g. only "@type": "gw:GW_Well". The others "@type": "gw:Borehole","@type": "gs:Borehole", "@type": "sosa:ObservationCollection" are under "subjectOf". This is how the CeRDI example under docs is structured.
Only those resources which are the same as the @type are allowed under "sameAs" e.g. only "@type": "gw:GW_Well". The others are provided under their own tags, not under "subjectOf". I'm not sure of the json-ld encoding, but something like: ... "@type": "gw:GW_Well", "sameAs" [ { "@id": "https://id.cerdi.edu.au/wmis/data/gwml2/well/107972", "@type": "gw:GW_Well", ] ... "gw:Borehole"[ { "@id": "https://id.cerdi.edu.au/wmis/data/gwml2/borehole/107972", "@type": "gw:Borehole", ... "gs:Borehole"[ { "@id": "https://id.cerdi.edu.au/gsv/data/gsml2/borehole/107972?f=json", "@type": "gs:Borehole", … "ssn-ext:ObservationCollection"[ { "@id": "https://id.cerdi.edu.au/wmis/data/sosa/observationcollection/107972", "@type": "sosa:ObservationCollection", ...

dr-shorthair commented 4 years ago

Note that the ssn-ext: namespace was retired, and all the new classes and properties from https://www.w3.org/TR/vocab-ssn-ext/ are in the sosa: namespace.

dr-shorthair commented 4 years ago

See https://github.com/opengeospatial/SELFIE/issues/99

bsimons14 commented 4 years ago

Yes I was aware of the changes (we now use sosa:ObservationCollection yes?), but the link you provide (https://www.w3.org/TR/vocab-ssn-ext/) and my google searches etc still deliver it as ssn-ext, so I left it as it was in the examples. Note this is not pertinent to issue #104, but is to how we configure the sosa properties.

bsimons14 commented 4 years ago

Changed examples to sosa

dr-shorthair commented 4 years ago

https://github.com/w3c/sdw/blob/gh-pages/ssn-extensions/rdf/ssn-ext.ttl#L40

dblodgett-usgs commented 4 years ago

@bsimons14 -- I prefer option 2.

I feel like sameAs should be used to link non-information identifiers that are intended to identify the same real-world feature. (maybe of a different type or minted by a different organization) subjectOf is then used to associate meta resources or data resources to each other. sameAs is too strong an association to use down in the meta/data realm. But that's a gut-call based on my anecdotal experience and engineering common sense, not based on rigorous evaluation of practice.

@dr-shorthair Is this good now? https://opengeospatial.github.io/ELFIE/contexts/elfie-2/sosa.jsonld Linked here: https://opengeospatial.github.io/ELFIE/contexts/elfie-2/ PRs welcome here: https://github.com/opengeospatial/ELFIE/tree/master/docs/contexts/elfie-2

bsimons14 commented 4 years ago

The resources in option 2 all refer to the same NIR, just different representations/profiles/sources. This is why they are all listed under “sameAs” in option 1. I’m concerned that by lumping these under “subjectOf “ it doesn’t make the connection tight enough. Note that in option 3 the tags (e.g. gs:Borehole, GW:Borehole etc.) are at the same level as “sameAs”, not contained within it.

dblodgett-usgs commented 4 years ago

Here's the issue -- we have no basis to assess whether:

doesn’t make the connection tight enough.

Is a valid concern given how this stuff is going to get implemented.

My sense is that a representation is not the sameAs a non information resource.

I don't know what you mean by "at the same level".

For SELFIE, the whole JSON-LD document should be properties of one NIR @id and potentially some pre-fetched properties of the properties of the NIR.

Maybe preparing three complete examples that we can poke at in the json-ld playground would help?

abhritchie commented 4 years ago

Recall, sameAs should be used very rarely. Only when the provider is adamant that the non-information resource they have identified and published is exactly the same as the non-information resource they have linked to using the identifier published by another party (in another HTTP domain). The SELFIE use case is restricted to duplicated databases like the GSV CERDI borehole database. If you are using words like 'whim' and 'similar' when considering the use of sameAs, walk away. PS I don't particularly care if owl:sameAs and schema:sameAs are different (one more permissive than the other) the labels are the same, will cause confusion and we should treat them as the same ... i.e. with the same caution.

abhritchie commented 4 years ago

schema:subjectOf is messy. In part it is a hack (or more generously 'place holder') in lieu of a better understood/specified implementation of content negotiation by profile. We are using URLs to directly access different representations of the same published (same @id) non-information resource (instead of the URI and HTTP Headers). We've also muddied things by trying to handle close or partial matches between different non-information resources (even if we do try to mash them into sameAs instead). But, it is currently our only fallback if we can't use a more meaningful relationship from a published ontology. I.e. if all our conceptual non-overlapping sampling features describe activities at exactly the same place perhaps a spatial topology association is best used?

abhritchie commented 4 years ago

Both comments long winded ways of supporting option 2.

abhritchie commented 4 years ago

Option 3 doesn't bring any nuance to the matching issue, it's just a crude string matching exercise (gw:GW_Well = gw:GW_Well) that doesn't consider the conceptual scope of the ontologies defining the @type. What if all instances of type:X are also instances of type:Y? And vice versa?

abhritchie commented 4 years ago

Also, @bsimons14, are you suggesting using class names as property names?

bsimons14 commented 4 years ago

Option 3 is the least popular and most contentious, so this example first. I think this is what @dblodgett-usgs was suggesting for sosa:ObservationCollection. All these are of the same NIR with different representations. 'gw:Borehole', 'gs:Borehole' and 'sosa:ObservationCollection' may need to be aliased to exclude the ":" as per ELFIE.

(syntax fixed by dblodgett)
{
  "@context": [
    "..."
  ],
  "@id": "https://geo.org.au/id/well/46217",
  "@type": "gw:GW_Well",
  "rdfs:comment": "put more stuff here!",
  "sameAs": [
    {
      "@id": "https://id.cerdi.edu.au/wmis/data/gwml2/well/46217",
      "@type": "gw:GW_Well",
      "format": [
        "application/ld+json"
      ],
      "provider": "http://www.water.vic.gov.au"
    },
    {
      "@id": "https://id.cerdi.edu.au/wmis/data/gwml2/borehole/46217",
      "@type": "gw:Borehole",
      "format": [
        "application/ld+json"
      ],
      "provider": "http://www.water.vic.gov.au"
    },
    {
      "@id": "https://id.cerdi.edu.au/gsv/data/gsml2/borehole/46217?f=json",
      "@type": "gs:Borehole",
      "format": [
        "application/ld+json"
      ],
      "provider": "https://earthresources.vic.gov.au/geology-exploration/geological-survey-victoria"
    },
    {
      "@id": "https://id.cerdi.edu.au/wmis/data/sosa/observationcollection/46217",
      "@type": "sosa:ObservationCollection",
      "format": [
        "application/ld+json"
      ],
      "provider": "http://www.water.vic.gov.au"
    }
  ],
  "subjectOf": {
    "url": "http://data.water.vic.gov.au/static.htm?ppbm=46217&gw&0&gwlf_org",
    "format": [
      "text/html"
    ],
    "provider": "http://www.water.vic.gov.au"
  }
}

abhritchie commented 4 years ago

I'm far too far behind on things SOSA to comment properly but ... wouldn't it be legitimate to type your root resource as a gw:GW_Well and a sosa:Sample? (He said nervously - can't recall how much sosa:Sample and sams:SF_SamplingFeature overlap.) The link to the sosa:ObservationCollection would be via sosa:isFeatureOfInterestOf. E.g.:

{
    "@context": [ ...],
    "@id": "https://geo.org.au/id/well/46217",
    "@type": "gw:GW_Well, sosa:Sample",
    ... more stuff here ...
    "sosa:isFeatureOfInterestOf": 
        {
            "@id": "https://id.cerdi.edu.au/wmis/data/sosa/observationcollection/46217",
            "@type": "sosa:ObservationCollection",
            ... more stuff here ...
        }
}

dr-shorthair commented 4 years ago

sosa:Sample is essentially the same as sams:SF_SamplingFeature.

(I wish we could go back to Turtle instead of JSON. You can always generate the JSON later to please the kiddies. But it introduces unnecessary syntactic fog.)

abhritchie commented 4 years ago

Be nice @dr-shorthair - this is a JSON-LD implementation project. Turtle alienates most of our target audience.

dblodgett-usgs commented 4 years ago

Note that I fixed the JSON syntax up so it will render above.

My suggestion of getting complete examples that would work in the playground would allow us to easily reformat and work with these documents properly. And convert to ttl if that's your thing @dr-shorthair. Going through that exercise would also give some clarity to things akin to building a reproducible example of a bug. Until we have that here, I am going to hold further comment.

bsimons14 commented 4 years ago

This issue needs to stay on track about the use of sameAs, SubjectOf and option 3 and not be sidetracked by sosa discussions. A separate issue can (should) be raised re proper use of sosa.

bsimons14 commented 4 years ago

OK Alistair's suggestion of multiple @type provides a variation on option 3 that I wasn't aware of. Can we have: { "@context": [ ...], "@id": "https://geo.org.au/id/well/46217", "@type": "gw:GW_Well, gw:Borehole, gs:Borehole", ... more stuff here ...

If so, I'd want option 1 where all of these would appear under "sameAs".

bsimons14 commented 4 years ago

Option 2 is my least preferred because it puts everything under "subjectOf" which is far to nebulous. The example is: https://github.com/opengeospatial/SELFIE/blob/master/docs/examples/CeRDI_Borehole_MetaResource.jsonld

The use of sosa/ssn-ext is wrong in these examples, so please ignore that aspect.

dr-shorthair commented 4 years ago

A separate issue can (should) be raised re proper use of sosa.

It was, but but errors persisted. https://github.com/opengeospatial/SELFIE/issues/99

multiple @type

Always a strength of RDF - being based on set-theory rather than oo inheritance.

bsimons14 commented 4 years ago

Option 1 (with a single @type in the header): https://github.com/opengeospatial/SELFIE/blob/master/docs/examples/CeRDI_BoreWell_MetaResource_107972.json The use of sosa/ssn-ext is wrong in these examples, so please ignore that aspect.

bsimons14 commented 4 years ago

Sorry @dblodgett-usgs I missed your comment about proper json-ld. Note that Option 1 and 2 are already in the examples folder )(https://github.com/opengeospatial/SELFIE/tree/master/docs/examples), which is why I need to have this resolved. They 'should' parse correctly(!). The use of sosa/ssn-ext is wrong in these examples, so please ignore that aspect.

abhritchie commented 4 years ago

Good progress. Most important thing about #105 is that we are using actual meaningful relations from existing ontologies, not trying to crudely link everything with subjectAsOfSame.

abhritchie commented 4 years ago

OK Alistair's suggestion of multiple @type provides a variation on option 3 that I wasn't aware of. Can we have: { "@context": [ ...], "@id": "https://geo.org.au/id/well/46217", "@type": "gw:GW_Well, gw:Borehole, gs:Borehole", ... more stuff here ...

If so, I'd want option 1 where all of these would appear under "sameAs".

So, if sameAs links non-information resources, in this case you have four non-information resources:

https://geo.org.au/id/well/46217 a gw:GW_Well
https://id.cerdi.edu.au/wmis/data/gwml2/well/46217 a gw:GW_Well
https://id.cerdi.edu.au/wmis/data/gwml2/borehole/46217 a gw:Borehole
https://id.cerdi.edu.au/gsv/data/gsml2/borehole/46217?f=json a gs:Borehole

Agree?

PS 4. is a URL. PPS I'm ignoring https://id.cerdi.edu.au/wmis/data/sosa/observationcollection/46217 because I don't want to live in a world where an observation collection is a sampling feature.

bsimons14 commented 4 years ago

@abhritchie wrote: "PPS I'm ignoring https://id.cerdi.edu.au/wmis/data/sosa/observationcollection/46217 because I don't want to live in a world where an observation collection is a sampling feature." For the sake of this discussion I'll ignore it too, especially since it seems I'm the only one who believes that objects and features are just a collection of observations.

dr-shorthair commented 4 years ago

OK Aristotle

bsimons14 commented 4 years ago

There aren't four non-information resources, there is one (https://geo.org.au/id/well/46217) and it is a real world borehole. (= point 1) There are three on-line representations of this non-information reource. Some information about https://geo.org.au/id/well/46217 is available from WMIS and it can be represented using the groundwater domain class gw:GW_Well. This is available at https://id.cerdi.edu.au/wmis/data/gwml2/well/46217 (when the services go back on-line!) (=2). Some other information about https://geo.org.au/id/well/46217 is also available from WMIS and it can be represented using the groundwater domain class gw:Borehole. This is available at https://id.cerdi.edu.au/wmis/data/gwml2/borehole/46217 (=3) Some different information about https://geo.org.au/id/well/46217 is available from GSV and it can be represented using the geology domain class gs:Borehole. This is available at https://id.cerdi.edu.au/gsv/data/gsml2/borehole/46217?f=json (=4). So if the json-ld @type is gw:GW_Well, then the other representations (gw:Borehole and gs:Borehole) aren't really sameAs it. However, if the json-ld @type="gw:GW_Well, gw:Borehole, gs:Borehole", then maybe sameAs is valid.

dblodgett-usgs commented 4 years ago

Your examples don't work in the playground because the contexts are stale.

I think I got your option 1 and 2 working in the playground... is there an option 3 to look at?

Based on: https://github.com/opengeospatial/SELFIE/blob/master/docs/examples/CeRDI_BoreWell_MetaResource_107972.json
which has stale contexts.

Option 1 , unroll for valid JSON-LD

```jsonld { "@context": [ "https://opengeospatial.github.io/ELFIE/contexts/elfie-2/elf-index.jsonld", "https://opengeospatial.github.io/ELFIE/contexts/elfie-2/elf-data.jsonld", "https://opengeospatial.github.io/ELFIE/contexts/elfie-2/gwml2.jsonld", "https://opengeospatial.github.io/ELFIE/contexts/elfie-2/gsmlb.jsonld", "https://opengeospatial.github.io/ELFIE/contexts/elfie-2/sosa.jsonld" ], "@id": "https://geo.org.au/id/well/107972", "@type": "gw:GW_Well", "name": [ "107972", "YARRAGON 12" ], "spatialCoverage": { "@type": "Place", "geo": { "@type": "GeoCoordinates", "latitude": "-38.171636", "longitude": "146.255074" } }, "label": [ { "@language": "en", "@value": "107972,YARRAGON 12" } ], "sameAs": [ { "@id": "https://id.cerdi.edu.au/wmis/data/gwml2/well/107972", "@type": "gw:GW_Well", "format": [ "application/ld+json", "application/gml+xml", "text/html" ], "provider": "http://www.water.vic.gov.au" }, { "@id": "https://id.cerdi.edu.au/wmis/data/gwml2/borehole/107972", "@type": "gw:Borehole", "format": [ "application/ld+json", "application/gml+xml", "text/html" ], "provider": "http://www.water.vic.gov.au" }, { "@id": "https://id.cerdi.edu.au/gsv/data/gsml2/borehole/107972?f=json", "@type": "gs:Borehole", "format": [ "application/ld+json", "application/gml+xml" ], "provider": "https://earthresources.vic.gov.au/geology-exploration/geological-survey-victoria" }, { "@id": "https://id.cerdi.edu.au/wmis/data/sosa/observationcollection/107972", "@type": "ssn-ext:ObservationCollection", "format": [ "application/ld+json", "application/gml+xml" ], "provider": "http://www.water.vic.gov.au" } ], "subjectOf": [ { "url": "http://data.water.vic.gov.au/static.htm?ppbm=107972&gw&0&gwlf_org", "format": [ "text/html" ], "provider": "http://www.water.vic.gov.au" }, { "url": "http://gsv.vic.gov.au/birt/frameset?__report=report/boreholes/borehole_details_pdf.rptdesign&showAllFlag=true&site_id=107972", "format": [ "application/pdf" ], "provider": "https://earthresources.vic.gov.au/geology-exploration/geological-survey-victoria" }, { "url": "https://gsv.vic.gov.au/getBoreDataV2/rest/v1/user/107972?sdcApplicationId=microservice", "format": [ "application/json" ], "provider": "https://earthresources.vic.gov.au/geology-exploration/geological-survey-victoria" } ] } ```

based on:
https://github.com/opengeospatial/SELFIE/blob/master/docs/examples/CeRDI_Borehole_MetaResource.jsonld
Which is invalid JSON.

Option 2, unroll for valid JSON-LD

```jsonld { "@context": [ "https://opengeospatial.github.io/ELFIE/contexts/elfie-2/elf-index.jsonld", "https://opengeospatial.github.io/ELFIE/contexts/elfie-2/elf-data.jsonld", "https://opengeospatial.github.io/ELFIE/contexts/elfie-2/gwml2.jsonld", "https://opengeospatial.github.io/ELFIE/contexts/elfie-2/gsmlb.jsonld", "https://opengeospatial.github.io/ELFIE/contexts/elfie-2/sosa.jsonld" ], "@id": "https://geo.org.au/id/well/46217", "@type": "gw:GW_Well", "name": [ "46217", "ARDNO 2" ], "image": [ "https://www.vvg.org.au/bores/bore_attachments/bore_917937_1365_amacleod.JPG", "https://www.vvg.org.au/bores/bore_attachments/bore_917937_1351_kmckenna.JPG", "https://www.vvg.org.au/bores/bore_attachments/bore_917937_1350_kmckenna.JPG", "https://www.vvg.org.au/bores/bore_attachments/bore_917937_1349_kmckenna.JPG", "https://www.vvg.org.au/bores/bore_attachments/bore_917937_1348_kmckenna.JPG" ], "report": [ "https://www.vvg.org.au/bores/bore_attachments/bore_917937_1346_kmckenna.pdf" ], "spatialCoverage": { "@type": "Place", "geo": { "@type": "GeoCoordinates", "latitude": "-37.784881", "longitude": "140.971284" } }, "label": [ { "@language": "en", "@value": "46217,ARDNO 2" } ], "sameAs": [ { "@id": "https://id.cerdi.edu.au/wmis/data/gwml2/well/46217", "@type": "gw:GW_Well", "format": [ "application/ld+json", "application/gml+xml", "text/html" ], "provider": "http://www.water.vic.gov.au" } ], "subjectOf": [ { "@id": "https://id.cerdi.edu.au/wmis/data/gwml2/borehole/46217", "@type": "gw:Borehole", "format": [ "application/ld+json", "application/gml+xml", "text/html" ], "provider": "http://www.water.vic.gov.au" }, { "@id": "https://id.cerdi.edu.au/gsv/data/gsml2/borehole/46217?f=json", "@type": "gs:Borehole", "format": [ "application/ld+json", "application/gml+xml" ], "provider": "https://earthresources.vic.gov.au/geology-exploration/geological-survey-victoria" }, { "@id": "https://id.cerdi.edu.au/wmis/data/sosa/observationcollection/46217", "@type": "sosa:ObservationCollection", "format": [ "application/ld+json", "application/gml+xml" ], "provider": "http://www.water.vic.gov.au" }, { "url": "http://data.water.vic.gov.au/static.htm?ppbm=46217&gw&0&gwlf_org", "format": [ "text/html" ], "provider": "http://www.water.vic.gov.au" }, { "url": "http://gsv.vic.gov.au/birt/frameset?__report=report/boreholes/borehole_details_pdf.rptdesign&showAllFlag=true&site_id=46217", "format": [ "application/pdf" ], "provider": "https://earthresources.vic.gov.au/geology-exploration/geological-survey-victoria" }, { "url": "https://gsv.vic.gov.au/getBoreDataV2/rest/v1/user/46217?sdcApplicationId=microservice", "format": [ "application/json" ], "provider": "https://earthresources.vic.gov.au/geology-exploration/geological-survey-victoria" } ] } ```

bsimons14 commented 4 years ago

@dr-shorthair I’d rather Deleuze over Aristotle

abhritchie commented 4 years ago

Use Linked Data, they said. Make the most of the existing ontologies (sometimes working at different meta-levels), they said. Discuss concepts in these ontologies as they were formally defined, they said. Oh, maybe they didn't.

abhritchie commented 4 years ago

There aren't four non-information resources, there is one (https://geo.org.au/id/well/46217) and it is a real world borehole. (= point 1) There are three on-line representations of this non-information reource. Some information about https://geo.org.au/id/well/46217 is available from WMIS and it can be represented using the groundwater domain class gw:GW_Well. This is available at https://id.cerdi.edu.au/wmis/data/gwml2/well/46217 (when the services go back on-line!) (=2). Some other information about https://geo.org.au/id/well/46217 is also available from WMIS and it can be represented using the groundwater domain class gw:Borehole. This is available at https://id.cerdi.edu.au/wmis/data/gwml2/borehole/46217 (=3) Some different information about https://geo.org.au/id/well/46217 is available from GSV and it can be represented using the geology domain class gs:Borehole. This is available at https://id.cerdi.edu.au/gsv/data/gsml2/borehole/46217?f=json (=4). So if the json-ld @type is gw:GW_Well, then the other representations (gw:Borehole and gs:Borehole) aren't really sameAs it. However, if the json-ld @type="gw:GW_Well, gw:Borehole, gs:Borehole", then maybe sameAs is valid.

Next question. What response do you expect back when you deference one of the sameAs URIs? E.g. https://id.cerdi.edu.au/wmis/data/gwml2/well/46217 - note the @id values:

{
    "@id": "https://id.cerdi.edu.au/wmis/data/gwml2/well/46217",
    "@type": "gw:GW_Well",
    "more": "... extensive description of the well ..."
}

or

{
    "@id": "https://geo.org.au/id/well/46217",
    "@type": "gw:GW_Well",
    "more": "... extensive description of the well ..."
}

bsimons14 commented 4 years ago

“@id”: “https://geo.org.au/id/well/46217”,

I think this is the nub of SELFIE. No matter what format (HTML, XML, RDF, JSON-LD), profile (gw:GW_Well, gw:Borehole, gs:Borehole) or source (WMIS, GSV) they are all representations of the same non-information resource. My understanding is that for SELFIE, if these representations are JSON-LD (in-band) then the “@id” will be the non-information resource identifier.

abhritchie commented 4 years ago

But that is not what happens when you convert your document to RDF (e.g. in the play-ground). The nested objects in your sameAs block don't become triples with the root non-information resource as the subject. They become triples with the nested @id as the subject. Accordingly, dereferencing an @id URI and getting a resource with a different @id looks like a broken redirect.

Note that our use of nesting in JSON-LD objects is a useful side effect of JSON. It doesn't translate into RDF at all. Also, compared with our previous preferred encoding (GML) the nested objects were proposed (in ELFIE) to map on to xlink:href - with some extra meta-data. Not to build big multi resource graphs that start from a single root resource.

abhritchie commented 4 years ago

With the exception of linking the physically separate CERDI and GSV repositories of data about the same borehole, you're trying to solve the problem of providing different views of the same non-information resource based on different ontologies, or versions of the same ontology. I.e. don't present everything that can be said about a resource at one - provide some mechanism to present subsets of the graph. Implementing sameAs as you propose doesn't achieve this. Not every problem we have can be solved with a data model, some require architectural soultions. Our options are (tentatively - much reading, testing to be done):

Content negotiation by profile;
OGC API Features collections bound to an ontology;
Methods like _view from the Linked Data API (option for CERDI);
The use of Linked Data Registries alongside our feature graph (option for CERDI);
More ...

bsimons14 commented 4 years ago

I'm confused. The @id for the NIR will be the same for all three Data Resources. If this is not the case in our examples, then they are wrong. Of course none of the responses is exactly the same as one of the others, so perhaps ''sameAs' is always inappropriate. I expect the meta resource to specify what on-line resources are available for the NIR. This is fine when there is only one 'in-band' normative resource and the rest are 'related resources'. But for us each of the three data resources are equally associated with the NIR. It seems that @abhritchie suggests the meta-resource should distinguish these as "views" of the NIR, in much the same way as the different formats are dealt with. So maybe our Data Resource links should not be under 'sameAs', but with their own property (I've used the domain model class names, but they could all be under a property such as sosa:hasFeatureOfInterest {or whatever the appropriate sosa property is}) and use profile/view content negotiation to distinguish them (using whatever the "view" semantics is). The Meta Resource could look like this (subject to the above caveats):

{
"@context": [ ...],
"@id": "https://geo.org.au/id/well/46217",
"@type": "gw:GW_Well, gw:Borehole, gs:Borehole",
... more stuff here ...
"gw:GW_Well": [
        {
            "@id": "https://geo.org.au/id/well/46217&view=gw:GW_Well",
            "@type": "gw:GW_Well",
... more stuff here ...
"gw:Borehole": [
{
            "@id": "https://geo.org.au/id/well/46217&view=gw:Borehole",
            "@type": "gw:Borehole",
... more stuff here ...
"gs:Borehole": [
{
            "@id": "https://geo.org.au/id/well/46217&view=gs:Borehole",
            "@type": "gs:Borehole",
... more stuff here ...
"sameAs": [ ... maybe nothing here ...

And then: "https://geo.org.au/id/well/46217&view=gw:GW_Well" redirects to the data record "https://id.cerdi.edu.au/wmis/data/gwml2/well/107972", "https://geo.org.au/id/well/46217&view=gw:Borehole" redirects to the data record "https://id.cerdi.edu.au/wmis/data/gwml2/borehole/107972" and "https://geo.org.au/id/well/46217&view=gs:Borehole" redirects to the data record "https://id.cerdi.edu.au/gsv/data/gsml2/borehole/107972"

Each of these data records would then have: "@id": "https://geo.org.au/id/well/46217", "@type": "xxxxxx", where "xxxxxx" is one of "gw:GW_Well", "gw"Borehole" or "gs"Borehole". Does this make sense?

dblodgett-usgs commented 4 years ago

(edit -- should be "landing-content" not "meta-resource" and "data resource" should be "representation")

Again, examples that function in the playground would be super helpful here.

The redirect behavior goes beyond the scope of what we are trying to deal with (and bypasses the landing-content so let's take that off the table for now and say that a client is actually going to use the meta-resource.

Taking your example above, this is valid JSON-LD: link to playground that works (playground is down?)

{
  "@id": "https://geo.org.au/id/well/46217",
  "@type": "gw:GW_Well, gw:Borehole, gs:Borehole",
  "gw:GW_Well": {
    "@id": "https://id.cerdi.edu.au/wmis/data/gwml2/well/107972",
    "@type": "gw:GW_Well"
  }
}

and for people who like ttl better, becomes: link to converter

@prefix ns0: <gw:> .

<https://geo.org.au/id/well/46217>
  a <gw:GW_Well, gw:Borehole, gs:Borehole> ;
  ns0:GW_Well <https://id.cerdi.edu.au/wmis/data/gwml2/well/107972> .

<https://id.cerdi.edu.au/wmis/data/gwml2/well/107972> a ns0:GW_Well .

You are using gw:GW_Well as both an rdfs:type AND an association property?

Now there's the separate issue of using sameAs, -- which has historically been conflated with use of @id or schema:url -- in your case, your representations return linked data so @id is appropriate. If your representation were only available in non-linked data formats then schema:url would be the option. That is entirely separate from the sameAs discussion. sameAs would only ever be used to relate two non-information resources that are exactly the same thing and merging the linked data graph (two or more landing-content sets)

We seam to be stumbling over JSON-LD syntax as much as anything here, so please please please only work with fully functioning examples and convert them to formats that are more familiar if needed from now on.

bsimons14 commented 4 years ago

Yes valid JSON-LD examples would be useful, but at this stage I am struggling with what pattern is appropriate, not the syntax. The requirement is simple: the Meta Resource must contain links to multiple Data Resources, all of which can equally be considered 'primary' data resources for the same NIR. Note that in this discussion we always only have one NIR, but multiple 'in-band' Data Resources. Discussion has previously centred around using "sameAs" to identify the multiple data resources. But each of these would have the same non-information resource ID. So how to distinguish them? @abhritchie has suggested that if they have different IDs they represent different NIRs, which is not what we want. He suggest either using 'views' or a Linked Data Registry approach. I've no idea how the LDR would work, and so had a go at using 'views'.

bsimons14 commented 4 years ago

@abhritchie wrote: "Our options are (tentatively - much reading, testing to be done):

Content negotiation by profile;
OGC API Features collections bound to an ontology;
Methods like _view from the Linked Data API (option for CERDI);
The use of Linked Data Registries alongside our feature graph (option for CERDI);
More ... " I can see that at least 1 and 3 could resolve this issue. However, I believe that these were all considered out of scope for SELFIE.

dblodgett-usgs commented 4 years ago

re:

Yes valid JSON-LD examples would be useful, but...

I can't follow your examples to make sense of them and some have been invalid / nonsensical. We need to up our game on that front.

re:

I believe that these were all considered out of scope for SELFIE.

Yes -- those are all beyond what we are able to accomplish here.

You've not answered my, and I think Alistair's, question above... "You are using gw:GW_Well as both an rdfs:type AND an association property?"

I fail to see what's wrong with:

{
  "@id": "https://geo.org.au/id/well/46217",
  "@type": "gw:GW_Well, gw:Borehole, gs:Borehole",
  "schema:subjectOf": {
    "@id": "https://id.cerdi.edu.au/wmis/data/gwml2/well/107972",
    "@type": "gw:GW_Well"
  }
}

If you add the mime-types, provider, and potentially profiles to the "@id": "https://id.cerdi.edu.au/wmis/data/gwml2/well/107972" node, then you've got everything you need to make an informed decision?

abhritchie commented 4 years ago

Recall that an explicit resource model defining Meta Information Resources and Data Information Resources was rejected around December after much discussion (e.g. #75, #76, #77 and in calls).

This issue is helpful in that it shows that attempts to reset our terminology (e.g. 77-selfie-resources-and-content and the relevant sections of the ER) have not adequately clarified matters. Addressing this is a matter of urgency for the ER.

abhritchie commented 4 years ago

That said, and assuming you are using data in the sense of Data Information Resources ...

Discussion has previously centred around using "sameAs" to identify the multiple data resources

In ELFIE and SELFIE sameAs was never proposed to link to data.

abhritchie commented 4 years ago

Part of the confusion is the presence of schema.org and its (admittedly successful) lack of conceptual rigour and tendency towards semantic drift. When SELFIE is over I'm working up the courage to write something about exactly where schema.org has value to a formal standards organisation like the OGC.

abhritchie commented 4 years ago

@abhritchie wrote: "Our options are (tentatively - much reading, testing to be done):

Content negotiation by profile;

OGC API Features collections bound to an ontology;

Methods like _view from the Linked Data API (option for CERDI);

The use of Linked Data Registries alongside our feature graph (option for CERDI);

More ... " I can see that at least 1 and 3 could resolve this issue. However, I believe that these were all considered out of scope for SELFIE.

1 was out of scope (only because the specification was not complete). 3 was never explicitly out of scope, from what I can tell it simply never got traction no-one but me liked it.

bsimons14 commented 4 years ago

You've not answered my, and I think Alistair's, question above... "You are using gw:GW_Well as both an rdfs:type AND an association property?"

Yes. But as I said before:

I've used the domain model class names, but they could all be under a property such as sosa:hasFeatureOfInterest {or whatever the appropriate sosa property is}

dblodgett-usgs commented 4 years ago

But can it? You are saying that <a real world thing of type gw:GW_Well> sosa:hasFeatureOfInterest <a data thing of type gw:GW_Well> ?

or: <a real world thing of type gw:GW_Well> gw:GW_Well <a data thing of type gw:GW_Well> ?

I still don't understand what's wrong with:

{
  "@id": "https://geo.org.au/id/well/46217",
  "@type": "gw:GW_Well, gw:Borehole, gs:Borehole",
  "schema:subjectOf": {
    "@id": "https://id.cerdi.edu.au/wmis/data/gwml2/well/107972",
    "@type": "gw:GW_Well"
  }
}

abhritchie commented 4 years ago

These discussions were more fun when @bsimons14 and I sat next to each other in a Melbourne office and I could storm off and cry in the bathroom.

bsimons14 commented 4 years ago

I understand from @abhritchie comment above that the problem with this is that the nested objects in the subjectOf block don't become triples with the root non-information resource as the subject. They become triples with the nested @id as the subject. Accordingly, dereferencing an @id URI and getting a resource with a different @id looks like a broken redirect. The @id in the current service responses return the subjectOf @ids, but this implies that each data response is about a different non-information resource. Hence my attempt to go down the {NIR id+view}.

(I ran the following through JSON-LD Playground so should be valid)

{ "@id": "https://geo.org.au/id/well/46217", "@type": "gw:GW_Well, gw:Borehole, gs:Borehole", "schema:subjectOf": [ { "@id": "https://id.cerdi.edu.au/wmis/data/gwml2/well/46217", "@type": "gw:GW_Well", "format": [ "application/ld+json", "application/gml+xml", "text/html" ], "provider": "http://www.water.vic.gov.au" }, { "@id": "https://id.cerdi.edu.au/wmis/data/gwml2/borehole/46217", "@type": "gw:Borehole", "format": [ "application/ld+json", "application/gml+xml", "text/html" ], "provider": "http://www.water.vic.gov.au" }, { "@id": "https://id.cerdi.edu.au/gsv/data/gsml2/borehole/46217", "@type": "gs:Borehole", "format": [ "application/ld+json", "application/gml+xml", "text/html" ], "provider": "https://earthresources.vic.gov.au/geology-exploration/geological-survey-victoria" } ] }

abhritchie commented 4 years ago

When using schema:subjectOf in this way the URL would be provided as the value of schema:url, not @id.

"schema:subjectOf": [
{
"url": "https://id.cerdi.edu.au/wmis/data/gwml2/well/46217",
"@type": "gw:GW_Well",
"et": "cetera"
}
]

opengeospatial / SELFIE

Meta Resource structure #104