Re: Why is PhysicalThing.additionalType recommended rather than mandatory

Hi Michel,

Regarding what Justin said "In the InterMine case it might be that a 
user can't provide a URI because their new class is something that isn't 
in an ontology (yet).  Initially, I was thinking that maybe we could 
allow a bare string, but I also like Michel's suggestion that it could 
be a link to a general term."

A general term would work, of course. But, would it be possible to 
suggest those new types for integration in SIO? If so, what would be the 
process? Is there any link on how new types could be added to SIO?

Regards,

On 20/09/2017 10:09, Leyla Garcia wrote:
> Hi Justin,
>
> We are still tuning PhysicalEntity and Record. The specifications are 
> simple but how they will be used requires examples and so. By October, 
> we should have the protein case ready to show, probably samples as 
> well. The idea would be to see how it works for others as well and 
> then make the final adjustments to the specifications (including 
> beacons, datasets, etc.).
>
> Specifications are visible now at http://bioschemas.org/newSpecs/. 
> Record is not there yet but will be soon, work in progress.
>
> Regards,
>
>
> On 19/09/2017 18:21, Justin Clark-Casey wrote:
>> Thanks for making that change, Leyla.  I wasn't sure about the exact 
>> status of the PhysicalEntity/Record specifications.  It would be very 
>> good to go through them as a group in October.  Personally, I like 
>> this new structure from what I've seen so far.
>>
>> In the InterMine case it might be that a user can't provide a URI 
>> because their new class is something that isn't in an ontology 
>> (yet).  Initially, I was thinking that maybe we could allow a bare 
>> string, but I also like Michel's suggestion that it could be a link 
>> to a general term. However, I wonder if this could affect 
>> findability, e.g. an InterMine user labels an entity as an 'organic 
>> polymer' [1] but it gets swamped in a search engine because there are 
>> also millions of entities in organic polymer subclasses.
>>
>> Or maybe even this minimum level of structure, when combined with a 
>> bit more information like a name term, is sufficient to whittle down 
>> the hits to make cross data source search more useful than at present.
>>
>> [1] http://semanticscience.org/resource/SIO_010346.rdf 
>> <http://semanticscience.org/resource/SIO_010346.rdf>
>>
>> On 19 September 2017 at 13:36, Leyla Garcia <ljgarcia@ebi.ac.uk 
>> <mailto:ljgarcia@ebi.ac.uk>> wrote:
>>
>>     On 19/09/2017 12:35, Justin Clark-Casey wrote:
>>
>>         I see that PhysicalThing.additionalType is shown as
>>         recommended [1] whereas BiologicalEntity.biologicalType [2]
>>         was mandatory.  What is the reason for this change?  I
>>         thought that this was one for the most critical properties
>>         (since most entity types will not have their own Bioschemas
>>         subclass).
>>
>>         [1]
>>         http://bioschemas.org/bsc_specs/PhysicalEntity/specification/
>>         <http://bioschemas.org/bsc_specs/PhysicalEntity/specification/>
>>         [2]
>>         https://docs.google.com/document/d/1XASuESIHU3bi1aXMxQS5-rCOQX0ugjMNkh68VF4co4Q
>>         <https://docs.google.com/document/d/1XASuESIHU3bi1aXMxQS5-rCOQX0ugjMNkh68VF4co4Q>
>>
>>         -- Justin
>>
>>
>>     I might be wrong but I think the specifications are still work in
>>     progress. I am taking your comment as a suggestion for
>>     PhysicalEntity. Still, we should take a second look to M/R/O for
>>     PhysicalEntity and Record and get to some agreements as a group.
>>     I think the point you raised makes sense, additionalType should
>>     be mandatory (and it has been modified as such). However, I am
>>     wondering if anyone has a case where the biological type cannot
>>     be provided. Also, is ONE enough? Should be allowed MANY for that
>>     field? And, if we allow many, will sameAs be assumed by applications?
>>
>>     Regards,
>>
>>
>