W3C home > Mailing lists > Public > public-bioschemas@w3.org > November 2017

Re: Vote on usage of non-schema.org terms

From: Gray, Alasdair J G <A.J.G.Gray@hw.ac.uk>
Date: Fri, 17 Nov 2017 12:35:25 +0000
To: Melanie Courtot <mcourtot@ebi.ac.uk>
CC: "public-bioschemas@w3.org" <public-bioschemas@w3.org>
Message-ID: <8FC16302-1251-4A1E-A146-04CE172B5E45@hw.ac.uk>
Hi Melanie, All,

For clarification, the vote is for when a profile makes a statement that it needs a term (either minimal, recommended, or optional) for a specific property, then it makes a declaration about the ontology term that is to be used.

I used Protein as an example, it would be up to the Protein profile developers to discuss and agree on the term.

Alasdair

On 17 Nov 2017, at 12:05, Melanie Courtot <mcourtot@ebi.ac.uk<mailto:mcourtot@ebi.ac.uk>> wrote:

Alasdair, all,

The ask was for a vote or counter proposal/amendment; I provided the latter.

You mention that the Protein working group has agreed that they require addition of an additional property. I don't think it is fair to ask all working groups to agree on a solution without giving them a chance to raise alternatives. If this vote is *only* for the Protein working group property then this group only should vote; but I thought we were here making a critical design decision for all of Bioschemas.

You have previously stated that you believed we should fix terms to a particular ontology URI, I am here stating that I am not fundamentally disagreeing but that I would like this to be limited to profile types. Specifically in this case my vote would be no about fixing the property which connects to the gene (and others have raised issues with this property).

I therefore propose that either this vote is amended to make it clear that we are voting on *only* the connection to gene for the Protein working profile or an additional option be added to the vote in which we consider the option of fixing the URIs but *only* for the profile types. I would also add that choosing the latter allows us to move forward as a group right now, and doesn't precludes us from revisiting this issue once we have started deploying markups and have more practical experience with what works well and what doesn't. It may very well be that we then realize we should constrain further, but IMO this decision would be premature at this stage.

Cheers,
Melanie






On 17/11/2017 11:43, Gray, Alasdair J G wrote:
Hi

On 17 Nov 2017, at 11:00, Melanie Courtot <mcourtot@ebi.ac.uk<mailto:mcourtot@ebi.ac.uk>> wrote:

I would like to offer an alternative, as stated by Andra: "Wouldn't the best option simply be to be strict on the type Protein, but for the remaining properties use the complete ontological space out there, without any limitations.", where the type Protein would be replaced by others as appropriate.

I donít see that this helps us with the search use case that has been identified by the Protein working group which has agreed that having the connection with gene is a minimal property. As such, in the bioschemas approach a property needs to be used for the connection to gene.

The purpose of this vote is then to see whether we use profiles to fix that term to a particular ontology URI, as there is not a suitable term in schema.org<http://schema.org/>.

By leaving things totally unconstrained, data providers must select a term to use and then hope that the clients can interpret the selected term.

The Bioschemas approach is about specifying the terms to use. Thus I believe that we should state the ontology term to use. This makes both adoption of markup easier (no choices to be made) and the use of the markup (the tool knows what to expect and how to interpret the terms).

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

________________________________

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:

  1.  Heriot-Watt University, a Scottish charity registered under number SC000278
  2.  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
  3.  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.



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
ORCID: http://orcid.org/0000-0002-5711-4872
Office: Earl Mountbatten Building 1.39
Twitter: @gray_alasdair
Received on Friday, 17 November 2017 12:35:52 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:08:00 UTC