- From: Franck Michel <franck.michel@cnrs.fr>
- Date: Fri, 29 Jun 2018 12:29:20 +0200
- To: Justin Clark-Casey <justinccdev@gmail.com>, Leyla Garcia <ljgarcia@ebi.ac.uk>
- Cc: Melanie Courtot <mcourtot@ebi.ac.uk>, "Gray, Alasdair J G" <A.J.G.Gray@hw.ac.uk>, public-bioschemas@w3.org
- Message-ID: <a57e1766-08d9-5626-4c72-8b13449cd932@cnrs.fr>
*Second sub-thread: How to name a profile? * Three different options are being discussed. (a) the context defines the profile name to be the chosen type URI, e.g. "Protein": { "@id": "http://purl.obolibrary.org/obo/PR_000000001" } (b) the context defines a type within namespace http://bioschemas.org like http://bioschemas.org/Protein. This is a hollow shell that just denotes we're talking about a Bioschemas profile. (c) We use the new schema.org concepts of defined term and defined term set, such as in the example provided by Mélanie: "@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" Here are a few thoughts with respect to these options: My concern with (a) is that a JSON-LD context is just a handy way to write data: the string "Protein" is a sheer shorthand, it could be named anything else. A webpage may use it this way: "@type": "Protein" But it would be perfectly equivalent to _not_ use the context and write this instead: "@type": "http://purl.obolibrary.org/obo/PR_000000001" My point is that a tool extracting Bioschemas markup should _not_ rely on the use of any specific shorthand. Besides, doing so would force using Bioschemas with JSON-LD only, but what about webpages using other markup formats? Unless I'm missing something here? Hence, I'm more inclined to go for (b) that defines a hollow shell for each profile such as http://bioschemas.org/Protein. The advantage is that it will always look the same whether a webpage uses the Bioschemas context or not. And this works the same across markup formats, JSON-LD, RDFa etc. (c) seems a interesting alternative. Instead of defining a JSON-LD context, we would define a Bioschemas vocabulary by means of DefinedTerms. For now, I don't quite understand how we would refer to the "Protein" defined term in a webpage markup. Any clues? Advantage: this solution avoids defining a Bioschemas profile as a type (option (b)), which makes the distinction between a type and a profile quite unclear. Still, I agree with Justin that there is a need for specific code to cope with such DefinedTerms. However, is this really an issue since, in any case, a Bioschemas extractor tool will have to know the profiles specifications to figure out what it looks for. Also, this is not much different from the additionalProperty case: there has to be some specific code to cope with it too. Right? 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:29:53 UTC