Haffner, Alexander
Wed, 28 Oct 2009 06:57:06 -0700
Hello Jon, thanks a lot for this detailed explanation. And yes all the questions did make my head hurt a little... I wasn't aware about the idea to define a functional "access point" as a string in aggregation ranges like in publicationStatement. Of course, in this case it is necessary to use a SES. But this information is redundant, so actually I expected mechanisms in upcoming systems which generate access points out of the subordinated elements (sub-elements). You are exactly right, in future rda:placeOfPlublication as well as rda:publishersName will link to according entities (RDF-Descriptions) because this is the basic idea of linked data and so non-literal values will become more and more important. Consequently, an SES has to support this circumstances, and if the SES isn't able to express our linked situation we are probably back at the point of dynamically generated access points, aren't we? Unfortunately there is no way to look at the content of your SESs. So how could a metadata instance look like? <rdf:Description rdf:about="http://abc.de/record123-e1-m1";> <rdf:type rdf:resource="http://RDVocab.info/uri/schema/FRBRentitiesRDA/Manifestati on" /> ... <rda:publicationStatementManifestation> ??? </rda:publicationStatementManifestation> <rda:placeOfPublicationManifestation rdf:resource="http://abc.de/Place/123"; /> <rda:publishersNameManifestation rdf:resource="http://abc.de/CorporateBody/123"; /> <rda:dateOfPublicationManifestation>2000</rda:dateOfPublicationManifesta tion> </rdf:Description> The declaration of rda-frbr-specific aggregated statements as properties with a domain of an rda-frbr entity and a range of an SES still is the critical point. So are you already developing approaches for alternative specifications of custom datatypes which allow a reflection of linked resources and if yes, how do they look? Best regards. Alexander ________________________________ Von: List for discussion on Resource Description and Access (RDA) [mailto:dc-...@jiscmail.ac.uk] Im Auftrag von Jon Phipps Gesendet: Donnerstag, 22. Oktober 2009 17:44 An: DC-RDA@JISCMAIL.AC.UK Betreff: Re: RDA element vocabularies Hi Alexander, I've put some responses to your questions in-line below. Thanks, Jon Phipps http://metadataregistry.org http://metadataregistry.org/rdabrowse.htm On Wed, Oct 21, 2009 at 4:47 AM, Haffner, Alexander <a.haff...@d-nb.de> wrote: Hello everyone, my name is Alexander Haffner and I started working at German National Library in September 2009. I am involved as a research fellow in the competence centre for interoperable metadata and I am responsible for investigations regarding a fitting integration of RDA compliant metadata for the Semantic Web in the German National Library landscape. Last week I gave a presentation about RDA and the Semantic Web in the Library Community Session at DC-2009 (slides online soon). That would be great, we'd love to see them. During my preparation I ran into some trouble and misunderstandings regarding the RDA Element Sets. In the presentation I tried to bridge the idea out of RDA Element Analysis (www.rda-jsc.org/docs/5rda-elementanalysisrev3.pdf) and the registered elements in the NSDL Registry. As you may have noticed, the RDA Element Analysis itself tries to bridge RDF, XML, Indecs, and DCAM and isn't yet fully formed or formally reviewed (as far as we know). So even though we're paying attention to it, we've departed from it in a number of areas as we've tried to coerce the RDA "Element Set" into a set of RDFS/OWL ontologies. Since the element analysis and the RDA documentation haven't always been written with RDFS/OWL or even RDF in mind, we've had to make some judgment calls. Many of these decisions try to take into account the utility of the RDA elements beyond the domain of RDA/FRBR as well as the need to be specific about the RDA/FRBR model. We're also thinking about how many of the RDA properties might map beyond the obvious MARC21 mappings and about how our description of the semantics might enable or restrict such mappings. And of course there are some additional challenges, such as the fact that there isn't yet a formal FRBR ontology that can be incorporated into the model. For example, I cannot understand why rda:publicationStatementManifestation and rda:publishersNameManifestation are specified as properties (property and its sub-property) with domain manifestation. Because out of my point of view rda:publicationStatementManifestation has to be of type class and has to offer a property rda:publishersNameManifestation. Because the RDA Element Analysis clarifies that these element sub-element relationships reflect composite patterns and so we have to find mechanisms to describe these aggregations in our schema too. The "aggregated" statements pose a particular problem and have been the source of much online and offline discussion. One of the primary questions is the one you pose and I think there are a number of problems with the approach you mention. The element analysis clarifies the fact that there is an element/sub-element relationship between publicationStatement and publishersName. In XML this is very easy to express: <Publication statement> <Place of publication> Austin, TX </Place of publication> <Publisher's name>The University of Texas at Austin, College of Liberal Arts </Publisher's name> <Date of publication> [2001]- </Date of publication> </Publication statement> And this maps very nicely to a MARC21 260 field: 260 $a Austin, TX 260 $b The University of Texas at Austin, College of Liberal Arts 260 $c [2001]- This is clearly the way that the RDA authors are thinking about how these aggregated statements will be expressed in instance data. Note that in neither instance do the rules for the main element -- <Publication statement> or 260 -- permit that element to contain a value. It's clean and simple. So what's the best way to express this instance data in RDF and the semantics in RDFS/OWL? We tried this out in a number of different models and found that there are quite a few formal and informal inferences that we have to take into consideration. Despite the MARC21 rules, can an RDA:publicationStatement contain a string? If so, can that string be expected to conform to a particular encoding scheme? These aggregated statements are functional "access points" in a card catalog and as such they're strings that have a clearly specified order of elements -- typed literals defined by a syntax encoding scheme. This isn't in the rules, but is widely understood. If we disable the ability to use such an encoded string as a value for this property, what are the consequences for mapping? Does Publication Statement as a distinct entity/element have any value at all in the description of a resource in the RDF data model if it can't exist independent of its constituent parts? And then of course there's those constituent parts. Do we want/need to restrict those to plain literals? Can we assume that in an open world the value of rda:placeOfPlublication will always be the plain literal that the rda:publicationStatement encoding scheme requires? It seems that it's just as likely, maybe more likely, that rda:placeOfPlublication will have a non-literal value. How do we conform to the RDA rules and still make the ontology extensible and future-proof and relatively domain independent? Do we need to be OWL-DL compatible as does that make us DCAM-compatible too? What about OWL2 and DCAM2? What's the best way to define a Syntax Encoding Scheme in an ontology? Does your head hurt yet? Unless there's some serious objection, we've decided that yes, aggregated statements have value in the ontology, but primarily as a place to store the aggregated syntax-encoding string as it might appear in a card catalog or a display. Given the lack of semantics, it has limited value, in an RDF query, as a superproperty of its constituent parts. For the moment, we have decided to... * declare a general class of Syntax Encoding Schemes * declare a SES subclass for each statement for use later as a custom datatype * declare each aggregated statement with no domain or range * declare each rda-frbr-specific aggregated statement as a property with a domain of the rda-frbr entity and a range of the SES -- this is incorrect, but right now we need a placeholder until we can come up with a good way of registering custom datatypes * declare each sub-element component of the statement as a generic property with no domain or range * declare each rda-frbr-specific sub-element component of the statement as a subproperty of the generic property with a domain of the rda-frbr entity * There is no range declared on the rda-frbr-specific properties and they're not declared as either an owl:objectProperty or an owl:dataProperty We welcome further feedback and discussion on this approach -- it's very clear that this isn't the only possible approach. I've inserted the related ontology fragments at the end of this email. Together with Alistair Miles I discussed my concerns and he shard my doubts. So I would appreciate to get some feedback regarding your decision making. Furthermore, I want to offer my contribution for the finalization of the RDA Element Vocabularies. So don't hesitate to involve me. Your contributions to the discussion are most welcome, as are Alistair's doubts. Additionally, I'd like to mention that we intend the development of a transformation from MARC to RDA metadata (in the beginning as proof of concept). Alistair already created an account to code4rda. In this context I'd like to know if there are any parallel efforts in this field I don't know yet. Thanks in advance for your support and best regards from Frankfurt, Alexander -- Alexander Haffner Deutsche Nationalbibliothek Informationstechnik Adickesallee 1 D-60322 Frankfurt am Main Telefon: +49-69-1525-1766 Telefax: +49-69-1525-1799 mailto:a.haff...@d-nb.de <mailto:a.haff...@d-nb.de> http://www.d-nb.de <http://www.d-nb.de/> <!--Class: Publication Statement Encoding Scheme--> <rdf:Description rdf:about="http://RDVocab.info/Elements/PublicationStatementEncodingSche me"> <rdfs:isDefinedBy rdf:resource="http://RDVocab.info/Elements"; /> <reg:status rdf:resource="http://metadataregistry.org/uri/RegStatus/1002"; /> <reg:name xml:lang="en">PublicationStatementEncodingScheme</reg:name> <rdfs:label xml:lang="en">Publication Statement Encoding Scheme</rdfs:label> <skos:definition xml:lang="en">This subclass has been created to define the Syntax Encoding Scheme for the RDA Publication Statement composite string. The Publication Statement is composed of an ordered, concatenated list of properties: - Place of publication - Parallel place of publication - Publisher's name - Parallel publisher's name - Date of publication </skos:definition> <rdf:type rdf:resource="http://www.w3.org/2002/07/owl#Class"; /> <rdfs:subClassOf rdf:resource="http://RDVocab.info/Elements/RDASyntaxEncodingScheme"; /> </rdf:Description> <!--Class: RDA Syntax Encoding Scheme--> <rdf:Description rdf:about="http://RDVocab.info/Elements/RDASyntaxEncodingScheme";> <rdfs:isDefinedBy rdf:resource="http://RDVocab.info/Elements"; /> <reg:status rdf:resource="http://metadataregistry.org/uri/RegStatus/1002"; /> <reg:name xml:lang="en">RDASyntaxEncodingScheme</reg:name> <rdfs:label xml:lang="en">RDA Syntax Encoding Scheme</rdfs:label> <skos:definition xml:lang="en">This subclass has been created to gather the Syntax Encoding Schemes used in RDA. </skos:definition> <rdf:type rdf:resource="http://www.w3.org/2002/07/owl#Class"; /> <rdfs:subClassOf rdf:resource="http://www.w3.org/2000/01/rdf-schema#Datatype"; /> </rdf:Description> <!--Property: Publication statement--> <rdf:Description rdf:about="http://RDVocab.info/Elements/publicationStatement";> <rdfs:isDefinedBy rdf:resource="http://RDVocab.info/Elements"; /> <reg:status rdf:resource="http://metadataregistry.org/uri/RegStatus/1002"; /> <reg:name xml:lang="en">publicationStatement</reg:name> <rdfs:label xml:lang="en">Publication statement</rdfs:label> <rdf:type rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#Property"; /> <skos:definition xml:lang="en">A statement identifying the place or places of publication, publisher or publishers, and date or dates of publication of a resource.</skos:definition> </rdf:Description> <!--Property: Publication statement (Manifestation)--> <rdf:Description rdf:about="http://RDVocab.info/Elements/publicationStatementManifestatio n"> <rdfs:isDefinedBy rdf:resource="http://RDVocab.info/Elements"; /> <reg:status rdf:resource="http://metadataregistry.org/uri/RegStatus/1002"; /> <reg:name xml:lang="en">publicationStatementManifestation</reg:name> <rdfs:label xml:lang="en">Publication statement (Manifestation)</rdfs:label> <skos:definition xml:lang="en">A statement identifying the place or places of publication, publisher or publishers, and date or dates of publication of a resource.</skos:definition> <rdf:type rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#Property"; /> <rdfs:subPropertyOf rdf:resource="http://RDVocab.info/Elements/publicationStatement"; /> <rdfs:domain rdf:resource="http://RDVocab.info/uri/schema/FRBRentitiesRDA/Manifestati on" /> <rdfs:range rdf:resource="http://RDVocab.info/Elements/PublicationStatementEncodingS cheme" /> </rdf:Description> <!--Property: Publisher's name--> <rdf:Description rdf:about="http://RDVocab.info/Elements/publishersName";> <rdfs:isDefinedBy rdf:resource="http://RDVocab.info/Elements"; /> <reg:status rdf:resource="http://metadataregistry.org/uri/RegStatus/1002"; /> <reg:name xml:lang="en">publishersName</reg:name> <rdfs:label xml:lang="en">Publisher's name</rdfs:label> <skos:definition xml:lang="en">The name of a person, family, or corporate body responsible for publishing, releasing, or issuing a resource.</skos:definition> <rdf:type rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#Property"; /> </rdf:Description> <!--Property: Publisher's name (Manifestation)--> <rdf:Description rdf:about="http://RDVocab.info/Elements/publishersNameManifestation";> <rdfs:isDefinedBy rdf:resource="http://RDVocab.info/Elements"; /> <reg:status rdf:resource="http://metadataregistry.org/uri/RegStatus/1002"; /> <reg:name xml:lang="en">publishersNameManifestation</reg:name> <rdfs:label xml:lang="en">Publisher's name (Manifestation)</rdfs:label> <skos:definition xml:lang="en">The name of a person, family, or corporate body responsible for publishing, releasing, or issuing a resource.</skos:definition> <rdf:type rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#Property"; /> <rdfs:subPropertyOf rdf:resource="http://RDVocab.info/Elements/publishersName"; /> <rdfs:domain rdf:resource="http://RDVocab.info/uri/schema/FRBRentitiesRDA/Manifestati on" /> </rdf:Description> <!--Property: Place of publication--> <rdf:Description rdf:about="http://RDVocab.info/Elements/placeOfPublication";> <rdfs:isDefinedBy rdf:resource="http://RDVocab.info/Elements"; /> <reg:status rdf:resource="http://metadataregistry.org/uri/RegStatus/1002"; /> <reg:name xml:lang="en">placeOfPublication</reg:name> <rdfs:label xml:lang="en">Place of publication</rdfs:label> <skos:definition xml:lang="en">A place associated with the publication, release, or issuing of a resource.</skos:definition> <rdf:type rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#Property"; /> </rdf:Description> <!--Property: Place of publication (Manifestation)--> <rdf:Description rdf:about="http://RDVocab.info/Elements/placeOfPublicationManifestation"; > <rdfs:isDefinedBy rdf:resource="http://RDVocab.info/Elements"; /> <reg:status rdf:resource="http://metadataregistry.org/uri/RegStatus/1002"; /> <reg:name xml:lang="en">placeOfPublicationManifestation</reg:name> <rdfs:label xml:lang="en">Place of publication (Manifestation)</rdfs:label> <skos:definition xml:lang="en">A place associated with the publication, release, or issuing of a resource. </skos:definition> <rdf:type rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#Property"; /> <rdfs:subPropertyOf rdf:resource="http://RDVocab.info/Elements/placeOfPublication"; /> <rdfs:domain rdf:resource="http://RDVocab.info/uri/schema/FRBRentitiesRDA/Manifestati on" /> </rdf:Description>