JSON-LD support about geoclient HOT 6 CLOSED

I know we talked about this in-person a couple of times. I agree that it would be a killer feature and beneficial to everyone, but, again, this is really outside the scope of Geoclient which is just a library for making it possible to call Geosupport and reduce boilerplate code for searching and working with the data.

The domain rules about location validation and processing exist in Geosupport alone. Similarly, the data itself is owned (co-owned in some cases, oy vey!) by several City agencies and it is curated, standardized, etc.by DCP and then disseminated by Geosupport.

Your proposal would seem to require that Geoclient use some algorithm to define what uniquely identifies various kinds of location-related datasets. In doing so, however, we'd simply be inventing domain rules that don't necessarily make sense to the actual owners/producers of the data.

If I've learned anything these last couple of years working on inter-agency workflows (some days, sadly, I begin to doubt whether that's a rhetorical question), it's that unless the purpose of your application is expressly to do so, proxy, integration, pass-through type libraries and apps should not interpret or otherwise attach new meaning to data that they themselves don't own.

That said, I'd love to contribute to a project that did this kind of thing with NYC agency data. It might be a cat-herding exercise and you'd need to be careful not to re-create the horrors of SOAP/WSDL/XML schemas for remoting...but as a developer working with this data, it would be a huge win.

Also, what I said above isn't completely true: there are some kinds of unique identifiers that are returned by Geosupport already which have fully defined and agreed upon semantics (BBL, BIN, 5,7,10-digit street codes, etc.). Low hanging fruit....there for the pickin'!

from geoclient.

Joel,
LMK if you decide to build something like this and you want my input and/or you have geoclient integration questions.

Thanks!
Matt

from geoclient.

I agree that low hanging fruit is the way to go. Enterprise Integration is always hard, never mind across several agencies!

If you don't mind, let's just leave this open on the Issue Tracker and just leave it in the backlog even though its out of scope.

Don't have bandwidth to build something right now even on our fork, but some other interested parties may jump in.

In my mind, you don't necessarily need to rock the boat to explore this. JSON-LD could just be another supported format alongside regular JSON and XML.

from geoclient.

Hmm. I'm getting the sense that we are not getting through to each other. My main point is that this feature does not belong in the Geoclient project, regardless of it being easy or hard. I don't agree that JSON-LD is just another format: yes, it's written with the same serialization syntax (JSON) and is delivered using the same remote protocols (HTTP) but that's where the similarity ends. Unlike the existing schema-less XML and JSON that the service simply uses to marshall data back to the client in a low ceremony format, the purpose of this format (seemingly) is to provide context about the meaning of the data.

I've seen a bit of snark around the interwebs already implying that we're not working with the community; speaking for myself only, I just don't get this[1]. So, please, help me understand how/why from a purely technical perspective why stewardship for this idea belongs with this project?

Thanks,
Matt

[1]Not for nothing, but if didn't know from first-hand experience that everyone's heart was in the right place, I'd be a little angry: saying "yes" or "no" (in my mind) has nothing to do with project "ownership" and everything to do with producing solid, maintainable software.

from geoclient.

My mistake is that I'm treating the GH Issue Tracker as a community backlog too.

Perhaps you may want to consider creating another repo which can serve as an "ideas-and-roadmap" repo (similar to CKAN's https://github.com/ckan/ideas-and-roadmap, maybe even use waffle.io to help manage the community backlog), and use this repo's issue tracker primarily for bug reports and showing the "official" roadmap.

Along those lines, you may also want to create a CONTRIBUTING.md file ( https://github.com/blog/1184-contributing-guidelines) to make clear what should be reported as issues?

And thanks for this outreach! Really appreciate that the Geoclient team is going is well beyond the extra mile in an effort to engage the community!

from geoclient.

@jqnatividad - I'm closing this enhancement and requesting that you add this to your fork of geoclient if you intend to implement it. LMK if you go forward and ultimately intend to submit it back via pull request. We can discuss ideas like a geoclient-contrib sub/separate project, etc.

Thanks for the ideas!

from geoclient.