have you looked at the OpenGeoportal Metadata toolkit activity? about mdeditor HOT 4 CLOSED

guess not...

from mdeditor.

Hi @smrazgs. We did take a look at the OGP effort. While I think it is similar, i.e. a "metadata editor", there's some fundamental differences. The mdEditor is fully a client-side JavaScript application. From what I can tell, the OGP editor is tightly integrated with server-side components, i.e. GeoNetwork. Granted I haven't taken the time to install it, so it may be available stand-alone (that was under the "other" heading in the design docs). I agree that there seem to be multiple simultaneous efforts at developing editors - I just learned about one that NASA EOSDIS is building thatt's integrated with their Common Metadata Repository (CMR). I don't know if it's necessarily a bad thing to have parallel efforts, but we should probably get folks together at some point to discuss efforts. We have tried to incorporate the better elements from other editors in our design, and avoid the complexity and UI issues that tend to make editors confusing and unappealing for users.

One thing that separates the mdEditor is the focus on non-spatial data and projects.

from mdeditor.

Thanks @jlblcc . We're trying to upgrade the metadata editor in CKAN and what I'd really like is a stand alone JavaScript editor client that could get a record from a url (or create a new one) and push the updated record back to some location (http POST?) It looks like your editor does something like that; what is the interchange format it uses to move the metadata in and out of the editor--ADIWG JSON?
@GaryHudmanAZGS

from mdeditor.

what I'd really like is a stand alone JavaScript editor client that could get a record from a url (or create a new one) and push the updated record back to some location (http POST?) It looks like your editor does something like that

Yep, the plan is to have configurable "publishing" endpoints. You'll need to provide support for authentication, e.g. OAuth, so folks can push to the catalog. Pulling the record should be relatively straightforward if you're generating something the editor can read - either directly or using the http://github.com/adiwg/mdTranslator API. Currently, that's limited to mdJSON, but that could be expanded by implementing new reader/writers in the mdTranslator. We did discuss implementing a limited import from FGDC/19115 directly in the editor, but it would be a pretty basic extract and no where near the depth supported by mdJSON.

what is the interchange format it uses to move the metadata in and out of the editor--ADIWG JSON?

Yes, that's the native format. You can find some mdJSON examples here: http://metadata.arcticlcc.org. What would be involved in implementing support for mdJSON in CKAN? I see there's support for the Project Open Data schema. I imagine mdJSON implementation would be similar? CKAN is using pycsw, right?

from mdeditor.