Thanks for the good (and huge) work with the MODS/RDF ontology, including 
the primer and the XSLT. Here are a few comments.

I did not find a description of the design choices which have been made 
for the MODS RDF Ontology and XSLT. For example, I wonder about the 
choices made about hash vs. slash namespaces. More information about that 
may be found at

One other thing I did not find is a few sentences about the reasons why 
XSLT 2.0 was chosen (and not the more widely implemented XSLT 1.0). Maybe 
it is because the code is easier to write, but we could also consider the 
use of the @version attribute on different XSLT elements.

The primer does not validate according to: 
because its code is a mixture of HTML and XHTML. Furthermore, depending of 
the (X)HTML version chosen, I suggest to add more @xml:id and / or @id and 
/ or @name attributes, to make it easier to refer to different parts of 
the primer.

I have read the XSLT code and plan to comment it in light of the design 
choices made (as I described above), but in this e-mail, I will focus on 
the primer at where I noticed a 
need for clarifications (and maybe some typos):

- In the table describing the namespaces and their prefixes at several 
of the prefixes used in the ontology are missing. Furthermore, several 
prefixes used in the primer are not in this table either: class identifier 
madsrdfs madsrds rds xs xsd (some of them may be duplicates or typos)

- The phrase "information about the about the descriptivemetadata" 
probably needs to be reformulated

- "Doman" is probably a typo for "Domain"

- "corresond" is probably a typo for "correspond"

- In the MODS 3.4 schema, the shelfLocator element is defined as xsString, 
which is xsd:string with language attributes. In xsd:string space 
characters are significant (not collapsed) and therefore, the space before 
"DAG" in

<shelfLocator> DAG no. 1410</shelfLocator>

is significant but not rendered in

"DAG no. 1410"

Whether the schema or the primer should be modified can be discussed.

- one can read "For some MODS typed elements , this ontology chooses to 
ignore the type." and one could refer to a description of the reasons for 

- The table called "Summary Tables for Element/Property Relationships" is 
described to show "MODS Top-level Elements". I assumed that this refers to 
the elements below the xs:choice of

xs:group name="modsGroup"

in the MODS 3.4 schema. These are also called "top level" (with quotation 
marks) in the MODS 3.4 schema. The quotation marks signal that the term 
"top level" is not related to MODS instances as XML. In the primer, these 
quotation marks are gone, which creates confusion, because these "top 
level" elements are under the mods:mods element(s), which in turn may 
reside under a mods:modsCollection within an instance, and thus are not 
"top level" from the instance's point of view.

Furthermore, the two elements mods:extension and mods:typeOfResource which 
are considered "top level" (with quotation marks) in the MODS 3.4 schema 
are not in this table for reasons that I consider would need to be 
clarified within this table.

I hope this helps.