search

buda-base / editor-templates

SHACL templates for the BUDA editor
MIT License
1 stars 0 forks source link

property for BDRC prefix indication #13

Open eroux opened 4 years ago

eroux commented 4 years ago

for instance P for a bdo:Person, etc. so that it can drive the editor ID generation

xristy commented 4 years ago

There is io.bdrc.libraries.Identifer where a version of that information is collected.

It would be nice to have a single central item that could be used in both JS and Java. A config file in the bdrc-libraries repo perhaps. Change one place and all identifiers get the same rules independent of language.

wdyt?

eroux commented 4 years ago

I think the easiest way to share data between JS and Java is through what they will both use which is RDF... as long as the data is available online for the editor I'm fine with anything, but having yet another configuration file to specify, with its own format, API, etc. is a lot of effort in specs, additional code, maintainance, etc. I would need a few convincing arguments to go that route... wdyt?

xristy commented 4 years ago

Surely, RDF is most sensible, identifer.prefixes.ttl, could be in bdrc-libraries or perhaps editor-templates with the various items of information needed in io.bdrc.libraries.Identifer (prefix string, sub part info, and so on). It would be loaded as a Model and interrogated in either Java (io.bdrc.libraries.Identifer) or JS.

I'm not sure it would be better to encode the various items of identifier information in root shapes for various Entity resources rather than in one model. If the identifier information is distributed across shapes modules, then io.bdrc.libraries.Identifer will have dependencies that in their turn are not as simple as a single source for the data.

Whatever set of properties are needed (it seems more than a single property, bds:identifierPrefix, is needed):

bds:PersonShape  bds:identifierPrefix "P" ;

can be encoded in person.shapes.ttl or another file that it imports.

I'm simply suggesting that a solution that provides a single place to specify each item of information rather than maintaining each item in two or more places, like a shape file and io.bdrc.libraries.Identifer or other.

eroux commented 4 years ago

if the triples are fetched with the rest of the triples of shapes I'm fine with anything yes. I'm just thinking of the balance between:

if having a system where this (more or less immutable) value must be changed in one file instead of two takes 2 more weeks to develop, it's clearly not worth it (2 weeks is of course not realistic in this case, but this kind of things accumulate)

xristy commented 4 years ago

I haven't tried to understand all that is going on in io.bdrc.libraries.Identifer and where it is used.

If all that is really needed is the single bds:identifierPrefix then sticking it in the root shape it applies to is fine. Either io.bdrc.libraries.Identifer gets updated or it just becomes the only other thing that needs updating if/when there's a change or (more likely) an addition.

I'll just stick the bds:identifierPrefix in the various shape files.