 |
 |
Dear Gordon, Thanks for the feedback. We're going to revisit the documentation shortly in order to clarify a few passages. We hope that will address the discrepancy you're seeing in items 2 and 5 of section 1.4 (and there are other spots). Cordially, Kevin ________________________________________ From: Metadata Object Description Schema List [[log in to unmask]] On Behalf Of [log in to unmask] [[log in to unmask]] Sent: Wednesday, January 19, 2011 06:45 To: [log in to unmask] Subject: Re: [MODS] MADS/RDF for review All: I am confused by the references to "record" in section 1.4 of the MADS/RDF ontology. Item 2) says: '... a “record” – the compilation of facts about something – may be one of two types ...' and Item 5) says: 'It is imperative to support deprecated records (headings/terms).' This seems to imply that a MADS record is a compilation of headings/terms; i.e. there are only headings, and no other "facts", in the record. I am also confused by the mechanism proposed to support deprecated records outlined in item 5) of section 1.4. Using the Cookery example: Initially, the label "Cookery" is the authoritative term for a concept. The concept has a URI, say my:Cookery, so we have: my:Cookery a madsrdf:Authority. Later, the label "Cookery" is deprecated in favour of the labels "Cooking" and "Cookbooks". Each of these is the authoritative term for a concept, with URIs, say, my:Cooking and my:Cookbooks; we cannot say: *my:Cookery a madsrdf:Variant. because Authority and Variant are disjoint classes. Ignoring "Cookbooks", we have: my:Cooking a madsrdf:Authority. We cannot say: *my:Cooking madsrdf:hasVariant my:Cookery. because the range of hasVariant is Variant. So we have to create another URI for the concept with the label "Cookery" as a variant heading, say my:Cookery2. We can now say: My:Cookery2 a madsrdf:Variant. My:Cooking madsrdf:hasVariant my:Cookery2. To link the initial Authority and subsequent Variant, both with the label "Cookery", we try: *my:Cookery madsrdf:hasLaterEstablishedForm my:Cookery2 But this is wrong, because the range of hasLaterEstablishedForm is Authority. Trivially,: *my:Cookery2 madsrdf:hasLaterEstablishedForm my:Cookery fails for similar reasons. We can correctly say: My:Cookery hasLaterEstablishedForm my:Cooking. But this is indistiguishable from the case given in section 3.3, item a), where the earlier heading remains valid and is not "deprecated". The only way we have of directly linking my:Cookery as Authority to my:Cookery2 as Variant is: My:Cookery2 madsrdf:hasLaterEstablishedForm my:Cookery1 We can do this because hasLaterEstablishedForm has no specified domain. But the statement is counter-intuitive, of course. So it seems that the ontology fails to meet the imperative support for deprecated headings, except by some tortuous method involving comparing labels of concepts that are related by a specific combination of properties. I'm sure I am misinterpreting the ontology, but I can't see where. Cheers Gordon