Use subjectOf instead of sameAs

[bsimons14]

From #94 Today's (25/2/2020) SELFIE meeting suggested that we are not using sameAs vs subjectOf to distinguish between in-band and out-of-band resources, we should stay well clear of owl:sameAs, and it is unclear what resources belong in schema:sameAs vs subjectOf. Instead, we should just use subjectOf for links to all data resources. The "@id" and "@type" vs "url" tags provide sufficient information to distinguish the various resources.

[bsimons14]

In the composite borehole meta resource example (https://github.com/opengeospatial/SELFIE/blob/master/docs/examples/CeRDI_Borehole_MetaResource.jsonld). The NIR is typed "gw:GW_Well", so I have placed the gw:GW_Well profile response under "sameAs". Other representations (gs:Borehole, gw:Borehole, sosa:ObservationCollection) are provided under 'subjectOf".

[abhritchie]

In #98 I state that sameAs has a specific, and perhaps not widely needed, purpose. When using it we are staying 'in-band', i.e. in a ELFIE flavoured RDF graph.

Reading across issues, and recalling previous discussions, it is not clear why participants are using subjectOf. Sometimes I wonder if people are feeling compelled to use it whereas subjectOf should be a property of last resort.

Going back to ELFIE, our motivation is to make the domain models we have developed available in a form usable by web-developers (JSON-LD). These domain models combine to give us a rich vocabulary and we should make extensive use of it.

I'd welcome comments that give individual examples of its use.

(PS I don't, and never have, like subjectOf so forgive any negative biases I have.)

[abhritchie]

subjectOf (specifically subjectOf.url) seems to have value when linking to 'out-of-band' resources. But would a more general property (a see also) be better?

[abhritchie]

Stronger use case: linking to 'in-band' resources of near-equivalent, but non-overlapping, @type. subjectOf: {"@id": "http://...", "@type: "Thing2"}

[dblodgett-usgs]

See "https://github.com/opengeospatial/SELFIE/issues/37#issuecomment-517056365" for where we made the call to use subjectOf for:

The decision to use schema:subjectOf instead of seeAlso

[abhritchie]

Uncool dude. Uncool.

There has been a lot of discussion since August 1, and external feedback to consider. New issues continue to be opened.

Note that #37 was inconclusive (https://github.com/opengeospatial/SELFIE/issues/37#issuecomment-540182317), not a decision.

[dblodgett-usgs]

Just pointing to where I think that came from and why people started adopting the practice.

Either way, we need to keep options generally open here.

[dblodgett-usgs]

This issue continues to confuse me and the linked data vs. semantic web concerns are totally confounding.

Given chatter above and in #98, this is where I think we stand.

One thing I think we can say is that we will use schema:sameAs and schema:subjectOf and NOT owl:sameAs. Exactly what properties should be used for linking to representations is not well established but I think your interpretation in CERDI of where we landed was actually correct (noting the objection to owl:sameAs that came in from the side). Note that this is different from what we discussed yesterday and is stated in #37

So I think if we change this context: https://opengeospatial.github.io/ELFIE/contexts/elfie-2/elf-index.jsonld to use schema:sameAs and you make sure you are referencing that context appropriately, your documents that use sameAs are more-or-less in line with the outcomes of SELFIE to date.

That said, there may still be a better property to link to representations in this case — I don’t think we are going to make firm conclusions on this front in SELFIE.

Finally, a reminder that this doc: https://docs.google.com/document/d/1jNg2J1KR0BZ91Oi4iy-A0z-NuhyYwFy7x41gX-OaB-E/edit# more or less stands as Alistairs best summary of where we landed on a number of these issues and we will continue to work this and other material into the ER.

[dblodgett-usgs]

elf-index context now uses schema:sameAs. @bsimons14 I think that in your example, you could bring any representation that is "in band" into the "sameAs" according to our best thinking, but we are at the edge of what we are going to claim to have any recommendations about.

OK closing this? I'll be working this into the ER and hopefully we can have it settled now.

[bsimons14]

I am happy to have everything that is in-band (SELFIE compatible) and about the NIR under sameAs. Everything that is out-of-band and about the NIR is under subjectOf. There is a whole philosophical debate about what 'sameness' is that I'm sure will result in different providers locating similar resources in different places (i.e. some under sameAs, some under subjectOf). However, for the IE I think we only need note the issue and leave it for others to debate. So I'm OK with closing the issue.

[dblodgett-usgs]

🙏

[abhritchie]

Not trying to reopen the issue, and unlikely adding anything new, just want the following out of my head: sameAs thing:A schema:sameAs thing:B: merges RDF graphs (therefore 'in-band') where thing:A = thing:B. Explicit. Not to be used with doubts (or in the presence of philosophy). A formal statement, rarely used. subjectOf Catch-all. Extends (with inevitable overlaps) a description of a non-information resource. May be:

1. a link to an 'out-of-band' resource, a PDF or GML document, using a URL (schema:url) or
2. a hook into another 'in-band' RDF graph (thing:A schema:subjectOf thing:B) where there is reasonable confidence that some or all of the content of thing:B is about thing:A. When in-band it is a property of last resort, used only when the semantics of our domain and topological models are inadequate.