AlgebraicJulia / SyntacticModels.jl

Specifying models with syntax trees
MIT License
3 stars 3 forks source link

Incorporate additional properties and metadata into decapodes model representations #22

Closed p-stokes closed 11 months ago

p-stokes commented 11 months ago

@jpfairbanks Here is a list of properties and metadata included in models from other frameworks. The main ones, e.g. the ones attached to states and transitions in Petri nets, are: name, description, properties, grounding, units. Separated into semantics for Petri nets are also: rates, initials, and parameters, which can have expressions, values, or distributions.

Currently for the other frameworks, metadata is a separate block containing a lot of fields related to the extractions, e.g. provenance or document.

Does it make sense to have this new list of properties be in a block similar to semantics but called something else?

jpfairbanks commented 11 months ago

It looks the only properties that are stored in the Petri Net schema are the name and the description for transitions. So I don't think we need a generic key value store in there. If people want to change what goals in this block, then they should submit a PR and update the data types.

We could call these annotations because metadata is taken. I think that metadata rightfully refers to information about how we got the data and not these things which are more like annotations about the model object.

name, description, grounding, units all seem good to me. What do you think of this?

@data Note begin
  Name(str::String)
  Description(str::String)
  Grounding(ontology::String, identifier::String)
  Units(expression::String)
end

@as_record Annotation{E,T} begin
  entity::E
  type::T
  note::Note
end

and then change ASKEMDeca to

@data ASKEMDeca <: AbstractTerm begin
  ASKEMDecaExpr(header::AMR.Header, model::Decapodes.DecaExpr, annotations::Vector{Annotation{Symbol,Symbol})
  ASKEMDecapode(header::AMR.Header, model::Decapodes.SummationDecapode, annotations::Vector{Annotation{Symbol,Symbol})
end
jpfairbanks commented 11 months ago

I suggested a big list of all the annotations where each annotation knows what entity it is annotating because this will handle missing annotations and multiple annotations better.

p-stokes commented 11 months ago

Yes, makes sense. What's your thought on annotations possibly referring to the names of functions that generate initial/boundary condition values?

jpfairbanks commented 11 months ago

Yeah, when we do the ACSet Transforms to store the IC/BC data, we will need to be able to refer to those functions as entities.