Metadata interest group
general forum for questions, comments, discussion about metadata
The CI_OnlineResource element is used in a variety of contexts in ISO19115 content. This complex-content-element provides a linkage to some online resource related to the metadata or the described context resource. It is thus analogous to atom:link (IETF RFC-4287) or the link element described in IETF RFC-5988. For links that locate online documents accessible using standard browser and file type resolution technology, the link can be as simple as a single URL element that retrieves a representation of the resource. There are many other kinds of related resources that the onlineResource element may point to, including web services that provide access to a dataset resource, metadata for related or source resources, specifications for standards or extensions to standards.
Useful guide to search term syntax for any applicaiton that's hitting a lucene index
Incorporates concepts from ISO 19115, 19115-1, 19119, FGDC, 19110, and FRBR along with some additional stuff like recording the lineage of the metadata record, which is useful in a metadata harvesting federated system. Builds on the conceputal model presented in a previous discussion here.
This is an experiment to see what it would look like, trying to bring in just about any metadata property from those various specs... Lot's of comments in line.
The JSON is not perfect -- I'm a newbie.
This is a scenario for a generic metadata edit tool, intended for brainstorming development of a community component that is transportable and reusable. Use of a standardized tool for editing metadata will reduce the cost of entry into the metadata game by reducing training and increasing productivity, and should help improve the quality and consistency of metadata. The attached word document has the same text. Please add any other features or requirements that would be useful.
Here is a run down of some functionality.
Start: User opens the editor application.
I spent some time researching this issue in the context of some other projects I've been following or involved in (OWS context Standards Working Group, energy industry ISO19115 metadata profile, and USGS CGI Web Application Integration Framework group). I would like to see this considered in a larger context to come up with a solution that can be used in these various contexts, because it's essentially the same problem.
Here' s the gist of the proposal for link attributes outlined in the attached doc:
href -- the link URL
type -- MIME type of response. Specifies encoding and optionally the native software application environment. We're sort of stuck with this because of existing usage. One big question is how much of serviceType, puprpose, and outputScheme it makes sense to conflate in the MIME type. I favor keeping the MIME type limited to low-level file formatting--to answer the question 'what software can read this file in a useful way' Understanding the content and intention of a document or the interface to a service should be specified by separate properties.
We can all agree that search engines like Google have really defined the way that we search for information on the internet. So the question is, why aren't we using Google to search for our geologic datasets? Do we have to do all that formal, structured metadata? What the hell is CSW anyways?
It acts as a proxy server. You ask it for http://metadata.usgin.org/record/a386a4ba-e892-11e0-9e4a-0024e880c1d2, and it reads that file identifier out and issues a CSW GetRecordByID request to a CSW server. The response to that CSW request is an XML document, and nobody (including Google) really cares about that, so the server formats the record as a very simple HTML page.
We write metadata so that we can search through it to find datasets we're interested in using for some purpose. I've recently started building a map-centric user-interface for doing this that has highlighted some simple functional requirements that metadata should meet in order to be helpful in accomplishing the task.
What I've done here is essentially listed the conceptual elements that seem neccessary in order to make a functional user-interface for searching. This has nothing to do with metadata syntax, just with metadata concepts.
FYI-- this is a draft profile against the upcoming revision of ISO19115 for metadata, scoped to energy industry, but the scope overlaps requirements for USGIN (I've been very active in developing profile and looked after that). Please have a look at the docs if you're interested in metadata. Given the standards process time lines, it probably won't directly impact us until next year.
I have built a UML model (using Enterprise Architect 7.5 tool) of metadata content that is based on ISO19115/19119, but attempts to clean up some of the logical incoherence and inscrutable element labeling in those specifications, as well as adding hooks for more detailed information on specific resource types and resource lineage.
The attached files include a zip archive of the Enterprise Architect-generated html report on the UML model; unzip to a directory and start on the index.htm page.
The EA document (zipped into GenericCompleteMetadataConceptualModel.zip) is the actual UML model. You'll need EA 7.5 or later to open it. The project contains a Metadata package, within which the 'GenericMetadataModel' package contains the actual model. The other packages include UML models for related ISO specifications, elements of which have been incorporated (copied, renamed, modified -- not imported) into the generic model. They are included for reference.
The html documentation generated by Enterprise Architect can also be viewed at
Now that we have a better grasp of the IT and informatics challenges of a distributed and interoperable information network, we can think more again about its adoption - how to make it work and useful on the ground. Following was our rough chain of thought on metadata:
It appears that the GeoNetwork WMS harvest selects an incorrect codeListValue for a service metadata record's srv:DCPList (Distributed Computing Platform). Currently, it enters HTTP-GET and HTTP-POST. However, there is a bit of confusion within GeoNetwork and among standards and profiles. Specifically, one could interpret a conflict between DCP in a service's GetCapabilities (OGC) and a service's metadata record (ISO):
The geospatial metadata community has benefitted greatly from the CSDGM Metadata Editor reviews created by Hugh Phillips and posted at:. As we make the transition toward implementation of an international metadata standard, the community requested that FGDC compile information about applications capable of creating ISO 19115 metadata. The information on this page was compiled to address that need.