Re: Why is PhysicalThing.additionalType recommended rather than mandatory

That's fine - just use the issue tracker
https://github.com/micheldumontier/semanticscience/issues

On Wed, Sep 20, 2017 at 11:42 AM, Leyla Garcia <ljgarcia@ebi.ac.uk> wrote:

> 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
>
> On 19 September 2017 at 13:36, Leyla Garcia <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/
>>> [2] https://docs.google.com/document/d/1XASuESIHU3bi1aXMxQS5-rCO
>>> QX0ugjMNkh68VF4co4Q
>>>
>>> -- 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,
>>
>>
>
>
>