Closed lazlop closed 1 year ago
I'm not quite sure how to effectively approach that w/o requiring that the SHACL shapes have some extra annotation saying what the parameter should be called. Maybe we parse out rdfs:label
or something similar, but it's not clear what the heuristic would be for determining the name
That's a good point. I think having some rdfs:label would work well, even if the name is nonsense it would at least be consistent and would allow one to find the shape definition in the ontology. Another idea is to skolemize the ontology files before storing them, so the naming could be consistent. This would also allow one to find the shape in the ontology, but it wouldn't require an extra parameter to be added to the SHACL shapes. In the example above, the only reason I knew 'p27' required the TimeseriesID is because it was the only constraint other than the name in the template.
Whatever the solution is. It seems like we should prioritize programmatic usage or these auto-generated templates. At the very least that means deterministic parameter names.
Sorry this took me so long to get to, but this should be addressed in https://github.com/NREL/BuildingMOTIF/pull/278 . We use sh:name
to inform the parameters when they are generated
Is there any way to reliably and helpfully name parameters that are created based on SHACL rules?
For example, I am creating a TimeseriesReference using the template in Brick-full.ttl
The ref_template will have the parameter name, then a randomly named parameter for the TimeseriesId (p12,p27,p3, etc.).