Interoperable Europe logo

GeoDCAT-AP [PR]: Example compliant to the new TG metadata

Anonymous (not verified)
Published on: 28/08/2015 Discussion Archived

References

This issue has been reported by Anja Loddenkemper.

http://joinup.ec.europa.eu/mailman/archives/dcat_application_profile-geo/2015-August/000189.html

 

Explanation

The XML example does not show xlink:href as mentioned in TG metadata draft v0.4.doc (https://ies-svn.jrc.ec.europa.eu/documents/51). It is kindly requested to include an example compliant to the new TG metadata in order to minimize further confusion concerning the operatesOn element. A "live example" from any JRC test-implementation might be helpful.

 

 

 

Component

Documentation

Category

improvement
Report abusive content Invite Share

Comments

Anja LODDENKEMPER Tue, 13/10/2015 - 11:28

I refer to http://joinup.ec.europa.eu/site/dcat_application_profile/GeoDCAT-AP/Geo….

 

There has not changed a thing concerning my point. So to me the mistake is still there.

 

There are two identifiers in metadata. One is the file identifier for the metadata (fileIdentifier). The other one is the identifier for the resource (resourceIdentifier).

The identifier for the metadata can be adressed by csw-request GetRecordById. The resource identifier cannot, at least not directy simple httpGet-request.

 

<srv:operatesOn xlink:href...> adresses the fileIdentifier for metadata. This is wrong if you take a look on the currently developed version of TG metadata. xlink:href has to address the resourceIdentifier, therefore you cannot have any GetRecordById-Request in xlink:href. The request for looking for the resourceIdentifier is far more complex. But in xlink:href you will only find the resourceIdentifier. No request in there.

 

If I had to write the GeoDCAT-AP, I `d first show correctly what are the two identfiers:

e.g.

resourceIdentfier = 7bae6dce-583c-4a25-b982-a01c93b7af29

fileIdentifier = ae6d7a1c-a394-40fc-87d3-67a1598ea177

Probably this example, given once at the start of the document, should be taken throughout the whole AP-document. Anybody could get it then.

 

The example shown with having one uuid with "-rec" behind is misleading (as the French correctly mention in JM17 comment). It is not only hard to be read / you can hardly notice, but a uuid with another "-rec" is no uuid anymore according to specification for uuids (by IANA or s.o.). But as far as I know, anybody should take uuids for metadataIdentifiers. - Except for the EU-documents showing us what to do - unfortunately. So the application profile, which should make things easer will possibliy lead people to the wrong direction, again.

 

resourceIdentifiers may have another problem. Maybe you double-check: In metadata they can be arranged in element MD_Identifier (this is used in Germany where you may find http://bkg.bund.de/gdi-ni/7bae6dce-583c-4a25-b982-a01c93b7af29) or it can be arranged in RS_Identifier. RS_Identifier is arranged with codespace (TG Requirement 6 in current TG metadata V1.3). So your example in GeoDCAT-AP should show examples how to convert resourceIdentifier in MD_Identifier and RS_Identifier if anybody uses that one instead or if it is still allowed to be used.

 

Good luck!

Login or create an account to comment.