Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Exact Matches #187

Open
ben-norton opened this issue Sep 12, 2024 · 3 comments
Open

Exact Matches #187

ben-norton opened this issue Sep 12, 2024 · 3 comments
Assignees
Labels
open-review Open review openDS suggestion

Comments

@ben-norton
Copy link

Suggestion

In SKOS mapping properties, exact matches are transitive, where x = y and y = z then x = z. Therefore, I highly recommend limiting terms borrowed from other standards (e.g. schema:name) to exact matches. Currently, the openDS model uses borrowed terms with a broader scope in the source vocabulary such as schema:name. If the mappings are narrower or broader, and therefore not transitive, then a minting a new term is highly recommended.

@ben-norton ben-norton added open-review Open review openDS suggestion labels Sep 12, 2024
@sharifX
Copy link
Contributor

sharifX commented Sep 12, 2024

can we not describe the mapping scope as broader or narrower instead?

@ben-norton
Copy link
Author

Unfortunately not. The issue is the transitive property. I think you should include the mappings, but it doesn't mitigate the issue of borrowing terms that are not exact matches. Here's a better way of representing it:
x = y and y = z then x must equal z.
Including the mappings doesn't make this statement true.

@samleeflang
Copy link
Contributor

Hi Ben, thanks for putting forth this point.
To borrow or not to borrow has been a topic I tried to wrap my head around for a while.
If you have any references explaining what the specific rules are, I would definitely be interested.

What we decided for within openDS is to generally stick with relatively open, reusable term lists such as the TDWG term lists, schema.org and dcterms.
As these term list are not full-fledged ontologies, they don't enforce a specific structure but are aimed at reusability.
The term schema:name is a good example.
The definition for this term is: "The name of the item" with as datatype: "Text".
We include the term in for example the ods:SourceSystem to give the source system a name.
To me, this falls in line with what the term is intended to as we name the item (in this case ods:SourceSystem).
As schema.org does not restrict the classes on which you can use, the term is safe to reuse in an openDS defined class.

Reusing terms where possible/sensible is also in line with how we interpret Semantic Data and Linked Open Data.
By using the globally used term for naming an item, we connect with the broader semantic language of the web.
This way, we only need to create new terms for domain or even infrastructure specific information.
I believe this is also in line with how TDWG reuses for example dcterms terms in DarwinCore or Audiovisual Core and other projects such as https://oceaninfohub.org/ use schema.org (who actually gave us feedback that we didn't use enough schema.org).

Do you feel we misinterpret how we should use existing term lists?
Any suggestions in how we could improve the use of existing terms is always welcome.

@samleeflang samleeflang self-assigned this Oct 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
open-review Open review openDS suggestion
Projects
None yet
Development

No branches or pull requests

3 participants