Very, very cool module. As to your question, I would encourage the use of the term "Schema" over "Topology", unless you really mean it. Topology is a term that refers to geometry and/or connectivity. Presumably you are determining the connectivity of your data---one structure holds or refers to another---which describes a data structure topology. But, is this a key aspect of the analysis? Is it a key aspect of the results, i.e. is your module able to perform a proper analysis of (say) circular topologies where other modules fail? If not, Schema might be a better choice than Topology.
David On Mon, Oct 24, 2016 at 5:13 AM, Smylers <smyl...@stripey.com> wrote: > Aaron Trevena writes: > > > On 24 October 2016 at 09:49, Smylers <smyl...@stripey.com> wrote: > > > > > If your module is Json-specifiec and there already exists a JSON:: > > > top-level namespace, then I think it's much better to put it > > > somewhere under JSON:: than Data::, which is so generic it tells > > > users very little about the module's purpose. > > > > The main idea/purpose isn't json specific - this could apply to mongo > > or any other nosql data source, I'm using it for postgres jsonb data > > in this project. > > OK. In that case Data::Topology::JSON probably doesn't work either, for > the same reason. > > > If I was looking for a way to get RDF or other metadata from mongo I > > wouldn't be looking for JSON::Schema::Inferred. > > True. > > There's an awkward balance between picking a name that is too specific, > and therefore misleading, and one that's so general that it's too > abstract for readers to glean what situations it does cover. > > Smylers > -- > http://twitter.com/Smylers2 > -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." -- Brian Kernighan
