Hi Dan, Thanks for taking such an interest! Regarding your questions and concerns: 'slash' vs. 'hash' URIs: As a matter of design, we coin URIs for retrieval of information about the resource identified by the URI by machines, not humans. The most current formal rules[1] state that retrieving a 'slash' fragment should return just that fragment when resolved. We're currently breaking that rule by always returning the entire vocabulary, as if it was indeed using hash URIs and will fix it in the next few weeks. An example of such a fragment (generated by the Open Metadata Registry for http://rdaregistry.info/Elements/w/P10001) is here: http://metadataregistry.org/schemaprop/show/id/15304.rdf We believe, as a matter of good design, that URIs coined for large vocabularies should minimize retrieval bandwidth, particularly since it's highly unlikely that the entire vocabulary will (or should) be retrieved when the properties are used individually as part of an application profile. The entire vocabulary can always be acquired by requesting it from the vocabulary's namespace URI: http://rdaregistry.info/Elements/w/ Lexical (readable, but not semantic) URIs: One of the most common misuses of vocabularies is the misunderstanding of the semantics of the property identified by the URI based on the user's personal, colloquial, or domain-specific interpretation of the semantics of the URI (dc:title is the one I've seem misused most often). So we believe that good vocabulary design _should_ obscure the semantics requiring that the actual vocabulary documentation be viewed by a human. The other problem is that the 'semantics' are most often broadly identified with the lexical label used in the URI. Vocabularies, no matter how stable semantically, _will_ evolve and that evolution often results in a change to the label(s), even if the semantics communicated by the URI don't change. And then there's the issue of spelling (British English vs. American English) and language. Should we assume that the entire world must use, and _understand_ English in order to effectively use a vocabulary? We don't think so. To at least partially address this we have coined multiple URIs for each property, as explained here: http://www.rdaregistry.info/Elements/e/ "All RDA URIs have both an immutable canonical form and a 'readable', lexical form, which is subject to change (changes will be redirected)." The lexical URIs follow the naming convention you identified and are largely based on the current English (British) label. Content-type: application/octet-stream: We just got the server (nginx) setup yesterday and we haven't yet set the mime types correctly. Again we'll fix that very shortly. Jon Phipps Metadata Management Associates Open Metadata Registry [1] http://www.w3.org/TR/swbp-vocab-pub/ Jon On Wed, Jan 22, 2014 at 12:57 PM, Dan Scott <[log in to unmask]> wrote: > I'm still pretty new at this linked data thing, but I find it strange > that RDA element properties URIs such as > http://rdaregistry.info/Elements/a/P50034 and > http://rdaregistry.info/Elements/a/P50209 both return the same HTML > page in a browser. Would it not have been more usable if the > properties used hash-URIs that could have located the particular > property on the particular page (e.g. > http://rdaregistry.info/Elements/a#P50034)? > > Also, a plain "curl" request returns Content-type: > application/octet-stream -- but it's pretty clearly Turtle, so I think > that should be Content-type: text/turtle > > I would have liked to see more meaningful URIs--like > http://rdaregistry.info/Elements/agent/addressOf instead of > http://rdaregistry.info/Elements/a/P50209--as meaningful URIs seem a > lot more approachable to this non-machine, but I guess that would have > been a lot more work. > > > > > On Tue, Jan 21, 2014 at 10:45 AM, Diane Hillmann > <[log in to unmask]> wrote: > > Folks: > > > > I hope this announcement will be of general interest (and apologies if > you > > receive more than one). > > > > Diane > > > > ---------- Forwarded message ---------- > > From: JSC Secretary <[log in to unmask]> > > Date: Tue, Jan 21, 2014 at 10:23 AM > > Subject: [rules] Publication of the RDA Element Vocabularies > > <snip recipients> > > > > RDA colleagues, > > > > See the announcement below, also posted on the JSC website. Feel free to > > share this information with your colleagues. > > > > Regards, Judy Kuhagen > > > > = = = = = > > > > The Joint Steering Committee for Development of RDA (JSC), Metadata > > Management Associates, and ALA Publishing (on behalf of the co-publishers > > of RDA) are pleased to announce that the RDA elements and relationship > > designators have been published in the Open Metadata Registry (OMR) as > > Resource Description Framework (RDF) element sets suitable for linked > data > > and semantic Web applications. > > > > The elements include versions "unconstrained" by Functional Requirements > > for Bibliographic Records (FRBR) and Functional Requirements for > Authority > > Data (FRAD), the standard library models underpinning RDA, that are > > intended for use in applications by non-RDA communities. > > > > The published version of the RDA element sets builds on several years of > > work by the DCMI/RDA Task Group. Earlier versions developed by the Group > > will remain available, but will be deprecated for further development and > > use, and redirected to the new version. > > > > Gordon Dunsire, Chair of the JSC, said "The RDA element set is a > > distillation of modern approaches to resource discovery supporting rich > > descriptions of library and cultural heritage materials and detailed > > relationships between them at international level. The JSC has recently > > established a working group to assist in extending and refining the RDA > > elements, and hopes that they will be useful to other communities, > ranging > > from close neighbours in library linked data to the global networks of > > general search." > > > > Diane Hillmann of Metadata Management Associates said "We are extremely > > pleased to be able to make this new version available now in fully > > published form, ready for implementation by libraries and vendors. We > look > > forward to discussing the important features available in this version > with > > our colleagues at the upcoming ALA Midwinter meetings and beyond." > > > > James Hennelly, Managing Editor of RDA Toolkit, said "This is an > important > > update to the RDA Registry and a crucial step in the advancement of RDA's > > mission to be a standard that is accessible to both cataloging > > professionals, through the toolkit and print and ebook publications, and > to > > application developers seeking to make use of library data, through the > > Registry's expression of the RDA elements and vocabularies." > > > > The basic RDA element set namespace is rdaregistry.info and it contains > a > > total of over 1600 properties and classes. Elements are distributed in > sets > > (the number of elements in each set is given in brackets): > > Agent properties > > [http://metadataregistry.org/schema/show/id/81.html]< > http://metadataregistry.org/schema/show/id/81.html>(226) > > Expression properties > > [http://metadataregistry.org/schema/show/id/78.html]< > http://metadataregistry.org/schema/show/id/78.html>(236) > > Item properties > > [http://metadataregistry.org/schema/show/id/80.html]< > http://metadataregistry.org/schema/show/id/80.html>(54) > > Manifestation properties > > [http://metadataregistry.org/schema/show/id/79.html]< > http://metadataregistry.org/schema/show/id/79.html>(213) > > Work properties > > [http://metadataregistry.org/schema/show/id/77.html]< > http://metadataregistry.org/schema/show/id/77.html>(232) > > Unconstrained properties > > [http://metadataregistry.org/schema/show/id/82.html]< > http://metadataregistry.org/schema/show/id/82.html>(698) > > Classes [http://metadataregistry.org/schema/show/id/83.html]< > http://metadataregistry.org/schema/show/id/83.html>(8) > > > > Follow the links to see details of each element set. > > > > Questions or comments on the content of the element sets may be addressed > > to the Chair of the JSC, Gordon Dunsire [[log in to unmask]]. > Questions > > and comments on the encoding of the vocabularies or on the Open Metadata > > Registry may be addressed to Diane Hillmann [[log in to unmask]]. >