Add pattern_iri key.

[balhoff]

@dosumis how does this key sound? It could also simply be iri if preferred.

[matentzn]

I prefer pattern_iri to avoid confusion. Will it be a required component of a DOSDP pattern? Also: Do you plan on issuing a warning in the case that two patterns accidentally get the same id (in the future).

[balhoff]

Will it be a required component of a DOSDP pattern?

I would say no.

Also: Do you plan on issuing a warning in the case that two patterns accidentally get the same id (in the future).

The only place dosdp-tools could do this is during creation of a "prototype" ontology. That's the only time it sees more than one pattern at the same time.

[matentzn]

That would be fine by me. The generation of the pattern ontology is exactly meant for debugging the pattern base; so its a good place for this.

Regarding whether a pattern identifier is required: I would kind of like to annotate all generated classes with the pattern they were generated with. If an iri is not required, it would be difficult to A) make sure that a meaningful default IRI is used for that annotation and B) generally track down a pattern from which a definition was generated...

[dosumis]

Original plan was to roll a pattern IRI from the pattern_name + some standard base, but I appreciate that better to have full iri in the pattern as a useful reference when it's shared. Question to me is how to make this play nicely with pattern_name.

Couple of options:

1. Treat pattern_name as a readable label unrelated to pattern_iri (in which case I think the current request works, but we need to think about pattern_iri schemes separately from pattern_names).
2. Add an optional base_iri field - with the understanding that base+pattern name => full, resolve-able URI.

Any preference?

[dosumis]

Question: Do you think using this IRI for pattern ontology terms AND have it resolve to the YAML pattern file is a potential source of confusion?

[matentzn]

My preference is option 1. You probably dont want to start restricting the name field to stuff that plays well in a URL. But good point regarding possible confusion..

[dosumis]

Edit was to wrong file. Have now edited the correct spec file. Tending towards accepting (option 1 above).

[balhoff]

Thanks—do we just need to update the "full" file in the future?

[dosumis]

Thanks—do we just need to update the "full" file in the future?

Yep.

I should really split into core and OBO extension. A couple of things have stopped me doing that so far:

1. I've chose to write the master schema files in YAML, which means I can't use $ref import directly (expects json). I should probably just switch completely to JSON as master for schema to that I can do this easily.

2. I need a strategy for asserting closure for checking purposes (additional_properties = False) and core (if that's what is being used) or core + extension (currently only OBO). I think this can be achieved with an import strategy, but need to investigate.