Re: Bioschemas profile specification: multiple candidate terms from various ontologies

(hit the send button too fast: I renamed this one to split the threads.)

*What do we do when there are multiple candidate terms from various 
ontologies?**

*I guess there is a consensus here: each specification group proposes a 
single approved term for each type and each property, that represents 
the group consensus.
The only difficulty may be to reach this consensus while sparing 
different communities' sensitivity.

It's been suggested that the context may document mappings to equivalent 
terms in other ontologies. Although the idea is compelling, I'm not sure 
how this can be achieved technically. I have tried the [invalid] example 
below. Let us assume the Biodiversity group chooses the TDWG rank 
property (tc:rank) to denote the taxonomic rank. The context names this 
property while providing the equivalent Wikidata property 
(owl:equivalentProperty) and webpage thereof (remember that 
schema:sameAs gives the "URL of a reference Web page that unambiguously 
indicates the item's identity (...)".
{
     "@context": [
         "http://schema.org/",
         {
             "tc": "http://rs.tdwg.org/ontology/voc/TaxonConcept#",
             "tc:rank": {
                 "@type": "@id",
                 "owl:equivalentProperty": 
"http://www.wikidata.org/prop/direct/P105",
                 "sameAs": "https://www.wikidata.org/wiki/Property:P105"
             }
         }
     ],
     "tc:rank": "http://rs.tdwg.org/ontology/voc/TaxonRank#Species"
}

Unfortunately, this example is invalid 
<https://json-ld.org/playground/#startTab=tab-expanded&json-ld=%7B%22%40context%22%3A%5B%22http%3A%2F%2Fschema.org%2F%22%2C%7B%22tc%22%3A%22http%3A%2F%2Frs.tdwg.org%2Fontology%2Fvoc%2FTaxonConcept%23%22%2C%22wdt%22%3A%22http%3A%2F%2Fwww.wikidata.org%2Fprop%2Fdirect%2F%22%2C%22tc%3Arank%22%3A%7B%22%40type%22%3A%22%40id%22%2C%22owl%3AequivalentProperty%22%3A%22wdt%3AP105%22%2C%22sameAs%22%3A%22https%3A%2F%2Fwww.wikidata.org%2Fwiki%2FProperty%3AP105%22%7D%7D%5D%2C%22tc%3Arank%22%3A%22http%3A%2F%2Frs.tdwg.org%2Fontology%2Fvoc%2FTaxonRank%23Species%22%7D> 
because a JSON-LD term definition cannot contain a sameAs or 
owl:equivalent property.

Can you think of other ways to express this mapping?

Franck.

Le 28/06/2018 à 19:40, Justin Clark-Casey a écrit :
> On Thu, 28 Jun 2018 at 16:42, ljgarcia <ljgarcia@ebi.ac.uk 
> <mailto:ljgarcia@ebi.ac.uk>> wrote:
>
>     Hi,
>
>     What Melanie suggests is useful to describe profiles, they would
>     become
>     a DefinedTerm. That would help as well to avoid type/profile
>     confusion.
>     We would talk then about DefinedTerms. If we find a way to also
>     described the properties accepted with their restrictions, that
>     would be
>     even better. That might be a good subject for a different discussion.
>
>
> This means there will have to be special Bioschemas code that knows to 
> look in a DefinedTerm somewhere for this information.  I still think 
> using a subtype to signify a profile will be simpler.
>
> I also disagree with Alasdair in that I think there should be a 
> http://bioschema.org/Protein type.  This would be an empty type that 
> just signifies we're talking about a Bioschemas defined protein. so it 
> isn't treading on anybodies toes.  This would have information saying 
> it's defined by http://purl.obolibrary.org/obo/PR_000000001 and it's 
> same as terms.  Without this, there's not much point having a 
> bioschemas context, and requiring people to use this specific string 
> every time is cumbersome, especially if every group chooses something 
> from a different ontology.  This makes writing and consuming markup 
> harder.
>
>
>     The question remains. How do we choose a term over others to
>     associate
>     it to a profile/DefinedTerm?
>
>
> I suggest having members of each specification group propose which 
> term they want and then come to consensus via discussion and/or vote.
>
>
>     Regards,
>
>
>     On 2018-06-28 15:45, Melanie Courtot wrote:
>     > Hi,
>     >
>     > We could consider using the defined terms,
>     >
>     https://dataliberate.com/2018/06/18/schema-org-introduces-defined-terms/,
>     > to do that.
>     >
>     > So have a protein be defined as
>     >
>     >            "@type": "DefinedTerm",
>     >             "@id": "http://purl.obolibrary.org/obo/PR_000000001",
>     >             "name": "Protein",
>     >             "inDefinedTermSet": "http://bioschemas.org/terms",
>     >             "description": "An amino acid chain that is produced de
>     > novo by ribosome-mediated translation of a genetically-encoded
>     mRNA.",
>     >             "sameAs": "http://purl.obolibrary.org/obo/NCIT_C17021",
>     >             "sameAs":
>     "http://semanticscience.org/resource/SIO_010043"
>     >
>     > (Using random examples of sameAs from
>     > https://www.ebi.ac.uk/ols/search?q=protein)
>     >
>     > Cheers,
>     > Melanie
>     >
>     > ---
>     > Melanie Courtot, PhD
>     > EMBL-EBI
>     > GA4GH/BioSamples project lead
>     >
>     >> On 28 Jun 2018, at 15:18, ljgarcia <ljgarcia@ebi.ac.uk
>     <mailto:ljgarcia@ebi.ac.uk>> wrote:
>     >> Hi,
>     >>
>     >> I understood Franck's question in a different way.
>     >>
>     >> Alasdair says
>     >>
>     >>> I also agree that a context file should be provided which has the
>     >>> chosen types and terms in it, i.e. the context file would define
>     >>> Protein to be the URI http://purl.obolibrary.org/obo/PR_000000001.
>     >>
>     >> I think what Franck is asking is how to choose
>     >> http://purl.obolibrary.org/obo/PR_000000001 over other possible
>     >> terms to define a Protein. For the taxon case, same as it happens
>     >> with proteins, there are multiple possibilities. Franck, is this
>     >> your question? If it is, I do not think there is any agreement on
>     >> how to choose, other than going for well-known ontologies broadly
>     >> accepted by the community of interest, even better if the term is
>     >> mapped to other possible ones.
>     >>
>     >> Regards,
>     >>
>     >> On 2018-06-28 11:50, Gray, Alasdair J G wrote:
>     >> On 27 Jun 2018, at 19:19, Justin Clark-Casey
>     <justinccdev@gmail.com <mailto:justinccdev@gmail.com>>
>     >> wrote:
>     >> I think we should have mandatory known @types and properties.  In
>     >> my view, Bioschemas should be as easy as possible to write and
>     >> consume.  Multiple options will increase cognitive load on writers
>     >> (which one do I choose?  Why are these 2 examples using these
>     >> different terms?) and open the door to greater inconsistency.
>     >> Non-mandatory types will also raise the barriers for writing
>     >> Bioschemas software that will have to be aware of equivalent
>     >> mappings.
>     >> I completely agree that we should have a single approved type for
>     >> each profile, and likewise for each property a single chosen term.
>     >> This is the whole point of having the profiles.
>     >> I would go one step further and say that Bioschemas should provide
>     >> an http://bioschemas.org [1] [1]context that will define types such
>     >> as
>     >> Taxon, rather than blessing particular ontology terms.
>     >> I also agree that a context file should be provided which has the
>     >> chosen types and terms in it, i.e. the context file would define
>     >> Protein to be the URI http://purl.obolibrary.org/obo/PR_000000001.
>     >> To
>     >> be completely explicit, we would not be defining a type in the
>     >> bioschemas namespace, e.g. http://bioschemas.org/Protein.
>     >> This context can also document equivalent terms in different
>     >> ontologies.
>     >> I like the idea that this also contains mappings to the equivalent
>     >> terms in other ontologies.
>     >> Alasdair
>     >> Alasdair J G Gray
>     >> Fellow of the Higher Education Academy
>     >> Assistant Professor in Computer Science,
>     >> School of Mathematical and Computer Sciences
>     >> (Athena SWAN Bronze Award)
>     >> Heriot-Watt University, Edinburgh UK.
>     >> Email: A.J.G.Gray@hw.ac.uk <mailto:A.J.G.Gray@hw.ac.uk>
>     >> Web: http://www.macs.hw.ac.uk/~ajg33
>     <http://www.macs.hw.ac.uk/%7Eajg33>
>     >> ORCID: http://orcid.org/0000-0002-5711-4872
>     >> Office: Earl Mountbatten Building 1.39
>     >> Twitter: @gray_alasdair
>     >> Untitled Document
>     >> -------------------------
>     >> _HERIOT-WATT UNIVERSITY IS THE TIMES & THE SUNDAY TIMES
>     >> INTERNATIONAL
>     >> UNIVERSITY OF THE YEAR 2018_
>     >> Founded in 1821, Heriot-Watt is a leader in ideas and solutions.
>     >> With
>     >> campuses and students across the entire globe we span the world,
>     >> delivering innovation and educational excellence in business,
>     >> engineering, design and the physical, social and life sciences.
>     >> This email is generated from the Heriot-Watt University Group,
>     which
>     >> includes:
>     >> * Heriot-Watt University, a Scottish charity registered under
>     >> number
>     >> SC000278
>     >> * Edinburgh Business School a Charity Registered in Scotland,
>     >> SC026900. Edinburgh Business School is a company limited by
>     >> guarantee,
>     >> registered in Scotland with registered number SC173556 and
>     >> registered
>     >> office at Heriot-Watt University Finance Office, Riccarton, Currie,
>     >> Midlothian, EH14 4AS
>     >> * Heriot- Watt Services Limited (Oriam), Scotland's national
>     >> performance centre for sport. Heriot-Watt Services Limited is a
>     >> private limited company registered is Scotland with registered
>     >> number
>     >> SC271030 and registered office at Research & Enterprise Services
>     >> Heriot-Watt University, Riccarton, Edinburgh, EH14 4AS.
>     >> The contents (including any attachments) are confidential. If you
>     >> are
>     >> not the intended recipient of this e-mail, any disclosure, copying,
>     >> distribution or use of its contents is strictly prohibited, and you
>     >> should please notify the sender immediately and then delete it
>     >> (including any attachments) from your system.
>     >> Links:
>     >> ------
>     >> [1] http://bioschemas.org/
>     >
>     >
>     >
>     > Links:
>     > ------
>     > [1] http://bioschemas.org/
>

Received on Friday, 29 June 2018 10:28:36 UTC