Re: Naming stuff is hard.. Data::Topology::JSON

[David Mertens]

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  wrote:

> Aaron Trevena writes:
>
> > On 24 October 2016 at 09:49, Smylers  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

Re: Naming stuff is hard.. Data::Topology::JSON

[Smylers]

Aaron Trevena writes:

> On 24 October 2016 at 09:49, Smylers  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

Re: Naming stuff is hard.. Data::Topology::JSON

[Konstantin S. Uvarin]

Hello,

 Does this module work on JSON-encoded data, or on a Perl structure
achieved by decoding JSON? If latter is the case, then maybe the JSON part
may be omitted altogether? Something like Data::Schema::Inferred?

  If it's JSON-encoded, I second Smylers' answer.

On Mon, Oct 24, 2016 at 11:49 AM, Smylers  wrote:

> Aaron Trevena writes:
>
> > I don't have a clean-room data set I can use as an example right now,
> > but essentially I'm parsing json, making a note of the names and
> > hierarchy of the fields, using dot-notation (i.e. like mongo) to name
> > nested fields, infer their type (i.e. ip address, mac address, epoch
> > time, etc) from data, and get a sample of the data. From that I can
> > then output a JSON::Schema or other documentation describing the data
> > itself.
>
> 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.
>
> How about JSON::Schema::Inferred?
>
> Smylers
> --
> http://twitter.com/Smylers2
>



-- 
Konstantin S. Uvarin
jabber: see 
skype: kuvarin
http://github.com/dallaylaen

Re: Naming stuff is hard.. Data::Topology::JSON

[Aaron Trevena]

On 24 October 2016 at 09:49, Smylers  wrote:
> Aaron Trevena writes:
>
>> I don't have a clean-room data set I can use as an example right now,
>> but essentially I'm parsing json, making a note of the names and
>> hierarchy of the fields, using dot-notation (i.e. like mongo) to name
>> nested fields, infer their type (i.e. ip address, mac address, epoch
>> time, etc) from data, and get a sample of the data. From that I can
>> then output a JSON::Schema or other documentation describing the data
>> itself.
>
> 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.

This is an implementation of extracting a metadata structure, example
data and schema from schema-less data, in this case JSON.

> How about JSON::Schema::Inferred?

JSON::Schema was just an example of the output, the simplest use case
in this case, but there's no reason it couldn't later output RDF,
Dublin Core or even HTML documentation using TT.

If I was looking for a way to get RDF or other metadata from mongo I
wouldn't be looking for JSON::Schema::Inferred.

A.

-- 
Aaron J Trevena, BSc Hons
http://www.aarontrevena.co.uk
LAMP System Integration, Development and Consulting

Re: Naming stuff is hard.. Data::Topology::JSON

[Smylers]

Aaron Trevena writes:

> I don't have a clean-room data set I can use as an example right now,
> but essentially I'm parsing json, making a note of the names and
> hierarchy of the fields, using dot-notation (i.e. like mongo) to name
> nested fields, infer their type (i.e. ip address, mac address, epoch
> time, etc) from data, and get a sample of the data. From that I can
> then output a JSON::Schema or other documentation describing the data
> itself.

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.

How about JSON::Schema::Inferred?

Smylers
-- 
http://twitter.com/Smylers2

Re: Naming stuff is hard.. Data::Topology::JSON

[Aaron Trevena]

On 24 October 2016 at 09:23, Konstantin S. Uvarin  wrote:
>  Could you please explain in more details? Sounds interesting, but it's not
> clear from the message what you mean by "de-facto schema". Maybe an example?

I don't have a clean-room data set I can use as an example right now,
but essentially I'm parsing json, making a note of the names and
hierarchy of the fields, using dot-notation (i.e. like mongo) to name
nested fields, infer their type (i.e. ip address, mac address, epoch
time, etc) from data, and get a sample of the data. From that I can
then output a JSON::Schema or other documentation describing the data
itself.

A.

-- 
Aaron J Trevena, BSc Hons
http://www.aarontrevena.co.uk
LAMP System Integration, Development and Consulting

Naming stuff is hard.. Data::Topology::JSON

[Aaron Trevena]

Hi all,

I've written some code to extract a "de-facto schema" from json, in
order to provide documentation and possibly other useful metadata
(i.e. dropdowns in UIs, etc).

For want of a better name I've gone with Data::Topology::JSON but any
better suggestions are much appreciated.

Cheer,

Aaron (TEEJAY)


-- 
Aaron J Trevena, BSc Hons
http://www.aarontrevena.co.uk
LAMP System Integration, Development and Consulting