update spec for metadata element

[jbs1]

migrated from Trac, where originally posted by kohlhase on 22-Sep-2010 4:37am

I thought about the use of the old metadata framework in OMdoc1.3, when I was revamping the RelaxNG schema. And here is what I think we should do (and have implemented in the schema).

We should restrict the old metadata element to have the old DC and CC contents, and allow it where it has always been (though I have liberalized the schema to allow it not only as the first child for schema uniformity).

We should allow the new and elements interspersed with the other content as we want to allow it in OMDoc2.

This should be discussed and synchronized with the spec.

[jbs1]

migrated from Trac, where originally posted by kohlhase on 22-Sep-2010 4:38am

And I guess Krextor and friends have to be updated to the new situation as well if necessary.

[jbs1]

migrated from Trac, where originally posted by clange on 22-Sep-2010 9:12am

Replying to [ticket:1623 kohlhase]:

I thought about the use of the old metadata framework in OMdoc1.3, when I was revamping the RelaxNG schema. And here is what I think we should do (and have implemented in the schema).
Did you read the metadata chapter in my thesis? Not that I'm saying it would completely change your mind, but I think it would allow you to make a more informed decision.
We should restrict the old metadata element to have the old DC and CC contents, and allow it where it has always been (though I have liberalized the schema to allow it not only as the first child for schema uniformity).
Makes sense, sounds like a clean solution. But then there wouldn't be a nice way of adding "just one more previously unsupported metadata field" to a document ported from the 1.2 to the 1.3 syntax. You would have to write:

<metadata>
  <dc:oldstuff>value</dc:oldstuff>
  ...
</metadata>
<meta property="something:new">value</meta>

FYI, I managed to specify (informally) a complete translation of the OMDoc 1.2 metadata to RDF, including your non-standard extensions, but not including things that can be expressed in OMDoc but are not valid in the target ontologies (e.g. some licences).
We should allow the new and elements interspersed with the other content as we want to allow it in OMDoc2.
OK – also recall that the purpose of the meta and link elements is merely making things a bit more readable for humans. We decided to support full RDFa, i.e. to allow all RDFa attributes on all OMDoc elements, at least in the strict syntax. (Why? In a nutshell: Given the complexity of the RDFa parsing rules, it is not trivial to find a reasonable and still standards-compliant subset.)
This should be discussed and synchronized with the spec.
And I guess Krextor and friends have to be updated to the new situation as well if necessary.
IIRC there is not too much to be done. Krextor doesn't care much about the order of elements, so metadata or meta or link in any place is OK. On the restricted pragmatic vocabulary (meta, link, resource) and on the OMDoc 1.2 metadata, Krextor performs quite well (with possibly a few bugs); the problem is with unrestricted RDFa, where it still fails a number of test cases.

[jbs1]

migrated from Trac, where originally posted by kohlhase on 22-Sep-2010 4:36pm

OK, it seems we are in basic agreement here. If you have better ideas than the ones that I implemented while cleaning up the schema (metadata reorganization was only a side-product whose state I wanted to document in this ticket), please state them here and implement them.

[jbs1]

migrated from Trac, where originally posted by clange on 29-Sep-2010 9:07pm

Replying to [comment:4 kohlhase]:

OK, it seems we are in basic agreement here. If you have better ideas than the ones that I implemented while cleaning up the schema (metadata reorganization was only a side-product whose state I wanted to document in this ticket), please state them here and implement them.
I didn't actually intend to say that I don't like your changes. It's rather that I'm undecided

1. whether we should allow vocabulary enhancements within the 1.2-style metadata block
2. or whether the metadata block should remain exactly as it was in OMDoc 1.2, and immediate meta and link children should be recommended whenever further vocabulary is needed

(Note: my comment is only based on your previous one, I didn't check the schema.)

(1) would allow for a less disruptive migration/enhancement of OMDoc 1.2 content, but OTOH I think that most of the existing OMDoc documents with relevant metadata have been generated from sTeX, so we don't have to worry about compatibility/usability/user-acceptance issues where there are none.

(2) would encourage a quicker introduction of RDFa. Given (2), mixing 1.2-style metadata and RDFa metadata looks so ugly that one would rather avoid the 1.2-style metadata altogether.

(In principle, we could deprecate metadata instead of ennobling them to an official pragmatic syntax, as, with appropriate ontologies, the RDFa representation of 1.2-style metadata is only a little bit more verbose.)

[jbs1]

migrated from Trac, where originally posted by kohlhase on 30-Sep-2010 4:08am

Replying to [comment:5 clange]:

(In principle, we could deprecate metadata instead of ennobling them to an official pragmatic syntax, as, with appropriate ontologies, the RDFa representation of 1.2-style metadata is only a little bit more verbose.)

I can also live with deprecating , but we have to wait with this until the change is implemented in the XSLTs and so on. The only problem I see with this is the use of the dc:title and dc:creator fields (these are basically the only fields that are regularly now) and they do not have metadata character, but document part character.

Maybe we should introduce new document structure elements for these two and allow (require) them to be decorated with new-style metadata?