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]].
>