Hi Jon:

On Thu, Jan 23, 2014 at 6:22 PM, Jon Phipps <[log in to unmask]> wrote:
> Well, the notion of 'beta' is a bit complicated... The vocabularies aren't
> beta and shouldn't be regarded as such. They've been well- vetted and
> reviewed and various folks, including me, have been working on them for
> quite a few years, with plenty of feedback from quite a few 'communities'.
> That said, the dereferencing service infrastructure isn't yet quite right,
> but we're pretty happy that it mostly works the way need it to right now --
> it's not just good, it's good enough. For now.

Thanks - from the announcement, I had no idea that the first bits of
the vocabulary actually started getting published five years ago.

> I've developed a quite strong opinion that vocabulary developers should not
> _ever_ think that they can understand the semantics of a vocabulary
> resource by 'reading' the URI. Do you have some expectation that in order
> for the data to be useful your relational or object database identifiers
> must be readable? By whom, and in English? This to me is a frankly colonial
> assumption of the dominance of English in the world of metadata. The proper
> understanding of the semantics, although still relatively minimal, is from
> the definition, not the URI. Our coining and inclusion of multilingual
> (eventually) lexical URIs based on the label is a concession to developers
> who feel that they can't effectively 'use' the vocabularies unless they can
> read the URIs. Go for it. Use them. The machines, if they're configured
> correctly, will fetch the correct URI permanently. I grant that writing ad
> hoc sparql queries with opaque URIs can be intensely frustrating, but the
> vocabularies aren't designed specifically to support that incredibly narrow
> use case. If you want to see/use label-based browse use the Open Metadata
> Registry (and yes that could be improved too):
> http://metadataregistry.org/schemaprop/list/schema_id/81.html
>
> Ultimately I'm not responding on this list to defend decisions that I
> didn't personally make, despite the fact that I completely support the
> decision.

You've described the rationale for those decisions elsewhere in this
thread, and thank for that. While I think it's a noble position to
take, I still believe that it's practically unusable and that adoption
will suffer as a result.

That said, as I went back to follow the history of development of the
RDA vocab, I came across Bruce D'Arcus' comments at
http://metadataregistry.org/blog/2009/03/09/multiple-languages-and-rda/
and http://permalink.gmane.org/gmane.comp.text.mods/847 that would
have benefited from a more detailed justification and discussion at
that (truly early!) time. But hey, we have it now, so that's good at
least.

> WRT the bug you mention, please take the trouble to put an issue on GitHub
> so we can track it:
> https://github.com/RDARegistry/RDA-Vocabularies/issues
> ...but, the issue isn't that the sameAs assertions don't appear in the
> turtle representation, it's that they do appear in the N3 representation
> we've published using "=" (valid N3, invalid turtle), and we don't actually
> publish turtle at the moment, even if that's what you ask for.

Heh, I couldn't tell the difference between N3 and Turtle at a glance
anyway; like I said, I'm still relatively new to the linked data thing
:)

> We publish
> N3 generated using the very useful RDF translation service:
> http://rdf-translator.appspot.com/
> ...which uses RDFLib to generate N3, and there appears to be a bug in
> RDFLib that isn't a bug:
> https://github.com/RDFLib/rdflib/issues/218
>
> I haven't had time to effectively research our options, but clearly we need
> to either generate both turtle and N3 serializations (my preference), or
> just turtle.

Thanks for making a public repository for issues; I've opened three
issues for the various oddities that I've noticed so far.