MRTG Structuring

→ Information about submission as TDWG standard
→ MRTG Wiki Homepage
→ Current Schema Draft. This version is under internal review as part of the submission to TDWG.
→ Audubon Core Non normative document
→ MRTG Development History
→ MRTG Meeting Notes
→ MRTG Best Practices
→ XML Schema representation of Audubon Core
→ RDF representation of Audubon Core
→ MediaWiki Help

1 Agents

"a) With respect to Agents, Creators etc. they DO NOT create an Agent structure for each person, but instead have a sequence of creators (names), plus a single structure of Contact Details. I find this very appealing, because it is way more practical. Given that the relevant media management applications are likely to all work like this in the future, I suggest to adopt this method." Comments on IPTC structuring from Email of Gregor Hagedorn March 1

• I don't follow. If Agent A and Agent B have different contact details, then this is yet another linking problem. --BobMorris 04:26, 2 March 2009 (CET)
  • I suggest to model the MRTG schema with relation to where metadata are available and how they are structured there, not to develop an ideal world schema, where everything is known. The reality will be that we either have no contact information, or that in many cases (both from current databases, and relevantly, all image management systems based on xmp will have ONE contact information, without the link to which creators contact that is, or whether it is a specific creator or organisational contact. I don't try to argue that this is ideal, but suggest to follow this existing example. --GregorHagedorn 11:39, 2 March 2009 (CET)

2 Repeatability

"b) One convention I found very useful and propose that we should adopt this: they use the type field to express both repeatability and data type using the RDF conventions: Text means simple text, not repeatable, bag Text means repeatable, order not significant (example: Keywords), seq Text means repeatable, order significant (example Creators). I suggest we adopt this as a convention for our specification as well - independent of the actual binding to xml-schema, RDF, or flat file. Comments on IPTC structuring from Email of Gregor Hagedorn March 1

• I see no reason to do this. The Collection normative document did quite well with "R" for repeatable. We could add "O" for ordered. I thought we were trying to avoid programmer jargon? --BobMorris 04:00, 2 March 2009 (CET)
  • Yes we can do that, although I think with an explanation the codes "seq", "alt", and "bag" are just as good. "alt" is the third option available in RDF, carrying semantics of "choose one" (mostly by language). I have no problems with private codes of RO, RA, RU though. The point I see is that with starting to use structures, we will need to add type information anyways, and I like about the IPTC for XMP that they combine the two in one column in a readable way. --GregorHagedorn 11:39, 2 March 2009 (CET)

• What is a "plus namespace"? --BobMorris 04:00, 2 March 2009 (CET)
  • One of the namespaces used in XMP metadata, they uses 5 namespaces (dc, photoshop, Iptc Core, Iptc Ext, and plus). --GregorHagedorn 11:39, 2 March 2009 (CET)

• Multiline is always tricky unless a linebreak marker is defined. --BobMorris 04:00, 2 March 2009 (CET)