BioChemEntity.additionalType (was Re: [Proposal] CategoryCode...)

If it's 'might', should this now be an optional property rather than recommended?

Also, fyi (or Kenneth's i) on the drafts page v0.4 of proteins is still linked rather than v0.5 [2].

[1] http://bioschemas.org/specifications/drafts
[2] https://github.com/BioSchemas/specifications/blob/master/Protein/proteinProfileSpecification.html

On 22/03/18 16:56, ljgarcia wrote:
> Hi Justin,
> 
> The additionalType might be useful for data providers or consumers if they want to link to other resources not necessarily using Bioschemas. It is also a way to 
> link to your own ontology. For instance, I imagine WikiData preferring to use their types, so if they are specified as additionalType, then they can reference 
> to their protein or gene or so type in WikiData.
> 
> Cheers,
> 
> On 2018-03-22 16:11, Justin Clark-Casey wrote:
>> Thanks Leyla for the edits, much appreciated.
>>
>> I hadn't realized from the old examples that BioChemEntity was now
>> being specified through multiple inheritance directly, e.g.
>>
>> {
>>     "@context": "http://schema.org",
>>     "@type": ["BioChemEntity",
>> "http://purl.obolibrary.org/obo/PR_000000001"],
>>     "additionalType":
>> "http://semanticscience.org/resource/SIO_010043",
>>     ...
>> }
>>
>> with "http://purl.obolibrary.org/obo/PR_000000001" as the mandatory
>> string for protein.  In this case, though, what is the purpose of also
>> giving additionalType (a recommended property)?  To optionally specify
>> the type further in a less controlled manner?
>>
>> On Wed, Mar 21, 2018 at 6:53 PM, ljgarcia <ljgarcia@ebi.ac.uk> wrote:
>>
>>> Hi Justin,
>>>
>>> Thanks for this initiative, nice summary for additionalProperty and
>>> its alternative via direct reuse of properties coined in other
>>> controlled vocabularies.
>>>
>>> There were some issues regarding the use of additionalType so I made
>>> some editions to the first and second sections. Feel free to ping me
>>> if you have any questions or want to discuss further.
>>>
>>> Regards,
>>>
>>> On 2018-03-21 17:59, Justin Clark-Casey wrote:
>>> I think you're right, this could be 2 distinct things.
>>>
>>> I recently read "Schema.org: Evolution of Structured Data on the
>>> Web"
>>> [1] and it was very illuminating as to the philosophy of schema.org
>>> [1].
>>> Namely that:
>>>
>>> * Things should be much easier for the data publishers and harder
>>> for
>>> the consumers
>>> * Developers chiefly implement by adapting examples (we knew this)
>>> * Getting initial adoption is much more important than getting the
>>> structures optimal upfront.  Once there is adoption, that's
>>> justification to improve structure if necessary.
>>>
>>> So I agree with you - specifying sample relations through
>>> additionalProperty is easiest and specifying more universal
>>> per-profile relations (e.g. amino acid sequence on protein) could be
>>> done through direct additional relations to make validation easier.
>>>
>>> To get additional relations (and the general
>>> BioChemEntity/DataRecord
>>> mechanisms) more straight in my head, I published a wiki page [2].
>>> Apologies for any mistakes, please anybody feel free to edit/extend
>>> and I will do so as necessary.  I ended up repeating quite a bit of
>>> what Alasdair originally wrote [3] and what is in examples, but I do
>>> find it useful to have this stuff in findable wiki form (Google docs
>>> aren't exposed to search engines afaik).
>>>
>>> [1] https://queue.acm.org/detail.cfm?id=2857276 [2]
>>> [2]
>>>
>> https://github.com/BioSchemas/specifications/wiki/Adding-profile-specific-relations-to-BioChemEntity-and-DataRecord
>>> [3]
>>> [3]
>>>
>> https://lists.w3.org/Archives/Public/public-bioschemas/2017Nov/0001.html
>>> [4]
>>>
>>> On 19/03/18 18:14, ljgarcia wrote:
>>> Hi all,
>>>
>>> I think we are talking about two different things here.
>>>
>>> For Samples, directly using additionalProperty seems the easiest
>>> option as this reduce requirements for small labs providing samples.
>>> They do not have to agree on any predefined terms or properties,
>>> just to provide key-value pairs via additionalProperty. Most likely,
>>> they will not including information regarding a CategoryCode, this
>>> one would be added whenever possible by BioSamples. @Luca, @Matt,
>>> please correct me if I am wrong. For the Samples case, it is a +1 on
>>> my side for accepting CategoryCode as a possible range for
>>> valueReference property on PropertyValue.
>>>
>>> For other groups/profiles, what Justin mentions makes sense and is
>>> useful. We use that way (or an approximation,I still need to tune a
>>> bit of things there) in the Protein profile.
>>>
>>> What do you think? Do we have two topics here? If so, let's separate
>>> them first. In any case, I will take a deeper look to Justin's
>>> examples later, I got a bit lost when I saw SampleDataRecord and
>>> also the schema:RangeIncludes.
>>>
>>> Regards,
>>>
>>> On 2018-03-19 17:47, Justin Clark-Casey wrote:
>>> So, last Friday at the Samples event, Leyla, Rafa and myself were
>>> talking about the alternative of specifying additional properties
>>> using a second context, rather than through AdditionalProperty.  The
>>> original discussion in November was at [1] but I don't think was
>>> fully
>>> formalized (and the example links are now broken).  But under this
>>> approach, I think the above would instead be something like
>>>
>>> {
>>> "@context": ["http://schema.org",
>>> "http://bioschemas.org/samples"],
>>> "@type": ["SampleDataRecord"],
>>> "diagnosisAvailable": [
>>> "http://purl.bioontology.org/ontology/ICD10/C00-C97.9 [5]",
>>> "http://purl.bioontology.org/ontology/ICD10/D00-D09.9 [6]"
>>> ]
>>> }
>>>
>>> with http://bioschemas.org/samples as
>>>
>>> {
>>> "@context": {
>>> "rdfs": "http://www.w3.org/2000/01/rdf-schema# [7]",
>>> },
>>> "@graph": [
>>> "@id"; "http://bioschemas.org/samples",
>>> {
>>> "@id": "http://bioschemas.org/samples/SampleDataRecord [8]",
>>> "@type": "rdfs:Class",
>>> "rdfs:subClassOf": { "@id": "http://schema.org/DataRecord" }
>>> }
>>> {
>>> "@id": "http://bioschemas.org/samples/diagnosisAvailable [9]",
>>> "@type": "rdfs:Property",
>>> "rdfs:label": "Diagnosis available",
>>> "http://schema.org/domainIncludes [10]": [
>>> {
>>> "@id": "http://bioschemas.org/samples/SamplesDataRecord
>>> [11]"
>>> },
>>> "http://schema.org/rangeIncludes [12]": [
>>> {
>>> "@id", "http://schema.org/URL"
>>> }
>>> ]
>>> }
>>> ]
>>> }
>>>
>>> See [2] for schema.org [1] [1]'s own type specification file.
>>>
>>> Pros:
>>> * Using existing validation tools should be easier, as this
>>> definition uses standard schema.org [1] [1] mechanisms to define
>>> additional properties, rather than the AdditionalProperty escape
>>> hatch.
>>> * Information such as name and label can go in the bioschemas.org
>>> [13]
>>> [7] file rather than be repeated in the data record text
>>>
>>> * Easier to put in different language translations to the
>>> bioschemas.org [13] [7] file
>>>
>>> Cons:
>>>
>>> * Applications may need to rely the URL itself (purl.org [14] [8]
>>> above)
>>> to retrieve information such as human-readable name for the
>>> categoryCode itself (e.g. "IN SITU NEOPLASMS").  This is good
>>> semantic
>>> web practise I believe, but may reduce reliability.  Possibly this
>>> information could also be served from http://bioschemas.org as a
>>> similar set of property definitions.
>>>
>>> * Perhaps not quite so easy to add arbitrary additional
>>> properties,
>>> though a data provider could always define and serve a third context
>>> themselves, or embed it inline.
>>>
>>> Thoughts?  Would especially like Leyla (though I know she's on
>>> holiday), Rafa, Alasdair, Dan, etc. to weigh in.
>>>
>>> [1]
>>>
>> https://lists.w3.org/Archives/Public/public-bioschemas/2017Nov/thread.html
>>> [15]
>>> [2] https://schema.org/version/latest/schema.jsonld [16]
>>>
>>> -- Justin Clark-Casey, http://justincc.org
>>>
>>> Research Software Engineer, Intermine, Cambridge
>>>
>>> ELIXIR UK Node technical co-orindator
>>>
>>> On Mon, Mar 19, 2018 at 11:21 AM, Philippe <proccaserra@gmail.com>
>>> wrote:
>>>
>>> Hi Luca,
>>>
>>> I am including a snippet from the notes so people can have a feel
>>> for how things could look like:
>>>
>>> {
>>>
>>> "@context": "http://schema.org" [1],
>>>
>>> "@type": ["DataRecord"],
>>>
>>> "additionalProperty": [
>>>
>>> {
>>>
>>> "@type": "PropertyValue",
>>>
>>> "name": "diagnosis_available",
>>>
>>> "value": "urn:miriam:icd:C00-C97",
>>>
>>> "valueReference": [
>>>
>>> {
>>>
>>> "@type": "CategoryCode",
>>>
>>> "name": "Malignant neoplasms",
>>>
>>> "url":
>>> "http://purl.bioontology.org/ontology/ICD10/C00-C97.9 [5]" [2],
>>>
>>> "codeValue": "C00-C97.9"
>>>
>>> }
>>>
>>> ]
>>>
>>> },
>>>
>>> {
>>>
>>> "@type": "PropertyValue",
>>>
>>> "name": "diagnosis_available",
>>>
>>> "value": "urn:miriam:icd:D00-D09",
>>>
>>> "valueReference": [
>>>
>>> {
>>>
>>> "@type": "CategoryCode",
>>>
>>> "name": "In situ neoplasms",
>>>
>>> "url":
>>> "http://purl.bioontology.org/ontology/ICD10/D00-D09.9 [6]" [3],
>>>
>>> "codeValue": "D00-D09.9"
>>>
>>> }
>>>
>>> ]
>>>
>>> },
>>> I also include the link the schema.org [1] [1] CategoryCode:
>>> https://pending.schema.org/CategoryCode [17] [4] and their JSON-LD
>>> snippet
>>>
>>> * {
>>> *  "@context": "http://schema.org/" [5],
>>> *  "@type": "CategoryCode",
>>> *  "codeValue": "Man",
>>> *  "inCodeSet": "http://id.loc.gov/vocabulary/resourceTypes [18]"
>>> [6]
>>> * }
>>>
>>> Question: Should 'inCodeSet' attribute be used instead ?
>>>
>>> Best
>>>
>>> Philippe
>>>
>>> On 19/03/2018 11:10, Luca Cherubin wrote:
>>>
>>> Hi everybody,
>>>
>>> During the Hackathon event last week with various Biobanks
>>> representatives we had the chance to use Bioschemas profiles and
>>> types to support BioBanks use cases for metadata sharing.
>>>
>>> As you may know, in the Sample profile we proposed a solution for
>>> linking ontology terms to a PropertyValue using CategoryCode as
>>> valid type for the valueReference field. Note that CategoryCode is
>>> already a proposed schema.org [1] [1] type but in the
>>> bioschemas/samples specification we propose that it should be an
>>> acceptable value for valueReference.
>>>
>>> To support BioBank use cases, we are using DataRecord and they
>>> need to use the same CategoryCode strategy to describe all the
>>> PropertyValue associated with a DataRecord.
>>>
>>> In our opinion this is a very strong use case for supporting the
>>> use of CategoryCode as valid type for valueReference for any
>>> PropertyValue in Bioschemas/schema.org [1] [1], not only for the
>>> Sample profile. We can see this being very useful in other areas
>>> where there is a need for a flexible linking of ontology terms to
>>> values.
>>>
>>> We would like to get your feedback on this.
>>>
>>> Best regards,
>>>
>>> Luca and Matt
>>
>> Links:
>> ------
>> [1] http://schema.org
>> [2] http://purl.bioontology.org/ontology/ICD10/C00-C97.9 [5]
>> [3] http://purl.bioontology.org/ontology/ICD10/D00-D09.9 [6]
>> [4] https://pending.schema.org/CategoryCode [17]
>> [5] http://schema.org/
>> [6] http://id.loc.gov/vocabulary/resourceTypes [18]
>> [7] http://bioschemas.org
>> [8] http://purl.org
>>
>>
>>
>> Links:
>> ------
>> [1] http://schema.org
>> [2] https://queue.acm.org/detail.cfm?id=2857276
>> [3]
>> https://github.com/BioSchemas/specifications/wiki/Adding-profile-specific-relations-to-BioChemEntity-and-DataRecord
>> [4] https://lists.w3.org/Archives/Public/public-bioschemas/2017Nov/0001.html
>> [5] http://purl.bioontology.org/ontology/ICD10/C00-C97.9
>> [6] http://purl.bioontology.org/ontology/ICD10/D00-D09.9
>> [7] http://www.w3.org/2000/01/rdf-schema#
>> [8] http://bioschemas.org/samples/SampleDataRecord
>> [9] http://bioschemas.org/samples/diagnosisAvailable
>> [10] http://schema.org/domainIncludes
>> [11] http://bioschemas.org/samples/SamplesDataRecord
>> [12] http://schema.org/rangeIncludes
>> [13] http://bioschemas.org
>> [14] http://purl.org
>> [15] https://lists.w3.org/Archives/Public/public-bioschemas/2017Nov/thread.html
>> [16] https://schema.org/version/latest/schema.jsonld
>> [17] https://pending.schema.org/CategoryCode
>> [18] http://id.loc.gov/vocabulary/resourceTypes
>

Received on Thursday, 22 March 2018 17:51:18 UTC