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

Naming Convention (for the ontologies RDF Terms) #13

Open
Tracked by #146
hoijui opened this issue Dec 16, 2022 · 2 comments
Open
Tracked by #146

Naming Convention (for the ontologies RDF Terms) #13

hoijui opened this issue Dec 16, 2022 · 2 comments
Assignees

Comments

@hoijui
Copy link
Collaborator

hoijui commented Dec 16, 2022

This mainly concerns property- and class-names.

We should choose one and stick to it, and I would prefer it to match mostly what is already out there.

I came to this issue, because we have properties with a has prefix, which seems odd to me,
as I have no seen this often in widely used ontologies.

Doing some research, I found two options, but none of them seems very official.

  1. I like this one, but it is not very explicit with examples:
    http://www-sop.inria.fr/acacia/personnel/phmartin/RDF/conventions.html
    It also seems to match with the common RDF ontologies out there ... mostly.
    excerpt: "Singular Nouns for Names (whenever possible) ... Even for Property Names"

  2. This one has some parts contradicting the previous one:
    Naming conventions for the RDF/OWL G-Node/python-odml#112
    for example: "Name all properties as verb senses"
    which means that they suggest a has prefix for properties,
    e.g. hasReadme vs just readme.

I saw even schema.org use both of these (though only about 20 properties use the has prefix).

@hoijui
Copy link
Collaborator Author

hoijui commented Dec 16, 2022

This post goes into detail for exactly the issue I faced (has prefix), explains it so even I understand it, and gives a solution for when to use the prefix and when not:

http://www.jenitennison.com/2009/09/13/naming-properties-and-relations.html

relevant parts:

So we have two vocabularies that represent the same concepts with equivalent classes, and obviously they have equivalent properties linking them. And this is what I find interesting. In the FRBR vocabulary, the relationships are:

  • frbr:Work -- frbr:realization --> frbr:Expression
  • frbr:Expression -- frbr:realizationOf --> frbr:Work
  • frbr:Expression -- frbr:embodiment --> frbr:Manifestation
  • frbr:Manifestation -- frbr:embodimentOf --> frbr:Expression

The FRBR vocabulary uses nouns to name the relations. It’s the same pattern that’s often used to name properties (ie predicates that take literals as values):

  • foaf:name
  • dc:title
  • rdfs:label

Using nouns leads you to read statements in the pattern “subject’s predicate is object”:

  • Jeni’s name is “Jeni”
  • the legislation’s title is “Criminal Justice Act 1993”
  • England’s label is “England”
  • the legislation’s realization is the version from 1st December 2001
  • this document’s embodiment is that XML file

The trouble is that this pattern really doesn’t work for the inverse relationships: frbr:realizationOf and frbr:embodimentOf:

  • the version from 1st December 2001’s realization of is the legislation
  • that XML file’s embodiment of is this document

They really want to support a sentence structure like “subject is a predicate object”:

  • the version from 1st December 2001 is a realization of the legislation
  • that XML file is a embodiment of this document

But if you then map that back to the original relation, you run into trouble, because there’s a temptation to add a preposition into the sentence to make it make sense, and inserting that preposition inverts the meaning of the statement:

  • the legislation is a realization [of] the version from 1st December 2001
  • this document is a embodiment [of] that XML file

You don’t run into this problem when you use nouns to name properties because there’s never an inverse relationship from a literal to a resource that you need to name. You also won’t run into it for relations that have easily named inverses, such as parent/child or owner/possession although there is a similar confusion with the use of comparatives for relation names, as in SKOS, where the relation skos:broader could mean:

  • X is broader than Y; or
  • X’s broader term is Y

In the Metalex ontology, on the other hand, the relationships are:

  • metalex:BibliographicWork -- metalex:realizedBy --> metalex:BibliographicExpression
  • metalex:BibliographicExpression -- metalex:realizes --> metalex:BibliographicWork
  • metalex:BibliographicExpression -- metalex:embodiedBy --> metalex:BibliographicManifestation
  • metalex:BibliographicManifestation -- metalex:embodies --> metalex:BibliographicExpression

Here, the relationships are verbs, leading you to read sentences in the form “subject [is] predicate object”:

  • the legislation is realized by the version from 1st December 2001
  • the version from 1st December 2001 realizes the legislation
  • this document is embodied by that XML file
  • that XML file embodies this document

The only weirdness here is having to add “is” before some predicates but not others.

The tradition in AI is to use verbs everywhere. Instead of foaf:name or dc:title, you would have foaf:hasName and dc:hasTitle. Doing this for properties with literal values seems unnecessarily verbose, but for relations I think it’s a good rule of thumb in order to disambiguate the direction of the relation.

@hoijui
Copy link
Collaborator Author

hoijui commented Jul 29, 2023

This should now be mostly "in vivo"

@hoijui hoijui self-assigned this Jul 29, 2023
@hoijui hoijui transferred this issue from OPEN-NEXT/OKH-LOSH May 30, 2024
@hoijui hoijui changed the title Naming Convention (for identifiers) Naming Convention (for ontology RDF Terms) Jul 28, 2024
@hoijui hoijui changed the title Naming Convention (for ontology RDF Terms) Naming Convention (for the ontologies RDF Terms) Jul 28, 2024
@hoijui hoijui mentioned this issue Jul 28, 2024
23 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant