additionalType still in use, its use is discouraged by Bioschemas (double check with @AlasdairGray )

[albangaignard]

No description provided.

[albangaignard]

Why is it discouraged ? It can be examplified through bio.tools entries.

[AlasdairGray]

In general, a thing that is being describe should be of a single type, e.g. a Gene is not a Protein and vice versa. There may be cases where it does make sense but as a general rule it doesn't.

This guidance is explicit as previously we were using multiple typing as an approach to reduce the number of schema.org types we were proposing.

@albangaignard can you give the specific example you have in mind? Looking at the Jaspar example, I don't see any multiple typing going on.

[albangaignard]

Ok, that's clear.

In bio.tools you can provide a category for tools based on a controlled vocabulary.
For instance :

"sc:additionalType": [
        "Database portal",
        "Web API",
        "Web application"
      ],

So we used the additionalType property, without interpreting it as strong "typing" (≠ from the rdf:type semantics).

[AlasdairGray]

Why are you not using the applicationCategory property for that?

The examples that you give are not valid types.

[albangaignard]

Thanks @AlasdairGray , that would also make sense with applicationSubCategory pointing to EDAM Topics.
I think that it requires a quick fix in the 0.6-DRAFT before the release.

[AlasdairGray]

I think that will be more consistent with the Schema.org way of things. However, in the interest of getting this out, lets make this a feedback comment from the community, i.e. we still circulate 0.6-DRAFT as a proposed 1.0-RELEASE and you fix this as part of the feedback for 1.0.

[marco-brandizi]

The following is more general than the software type case (and possibly, it's more about schema.org):

In my opinion, the fact that additionalType extends rdf:type can be problematic. In particular,
I have strings that I convert into "sample properties" and then enrich with ontology terms using
text mining tools (eg, ZOOMA, Bioportal Annotator). The result is something like:

ex:prop1234 rdf:type schema:PropertyValue;
  schema:propertyID "Sample Characteristic";
  schema:value "seed size"; # The string it was created from
  schema:additionalType ex:seed, ex:size # computed by text mining, not much under manual control

with additionalType as subproperty of rdf:type, the case above implies a couple of formally wrong statements: one, the property value is an information artifact entity, and not a seed. Two, seed and size are disjoint classes (and declared as such in many actual ontologies).

This might not be very important if you don't expect to use a formal (OWL) reasoner with your data, yet I don't like to introduce such potential inconsistencies in my data.

So, in conclusion, I wonder if the declaration of additionalType as subproperty of rdf:type could be removed in schema.org, or, alternatively, I wish there were guidelines to deal with cases like the above.

Personally, in a few datasets I've chosen to use dc:type in place of additionalType, maybe schema:about could be a similar option, but I realise it would preferrable to have at least an established convention or best practice for that (or even specifications in the profiles in the case of Bioschemas).

[ljgarcia]

@marco-brandizi has given an excellent example on why this is discouraged.
@albangaignard have you explored in bio.tools the possibility of using other property. From your example, it does not look like additionalType is the best/right one

[albangaignard]

Thanks all, I will update the code in bio.tool so that we rather use applicationCategory. That's not a big change.

[AlasdairGray]

I believe that this change has been made to the profile so we can close this issue.