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.

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.

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

Jon



On Thu, Jan 23, 2014 at 10:50 AM, Dan Scott
<[log in to unmask]<javascript:_e({}, 'cvml', [log in to unmask]);>
> wrote:

> On Thu, Jan 23, 2014 at 10:08 AM, Jon Phipps <[log in to unmask]<javascript:_e({}, 'cvml', [log in to unmask]);>>
> wrote:
> > Hi Ben,
> >
> > On Thu, Jan 23, 2014 at 4:48 AM, Ben Companjen
> > <[log in to unmask] <javascript:_e({}, 'cvml',
> [log in to unmask]);>>wrote:
> >
> >> Returning an HTML document (or XML document as I get) in
> >> response to a request for an RDA property or class is wrong in the
> Linked
> >> Data sense [note 1]. This is explained in the W3C WG Note that you
> >> referred to in recipe 2 [2].
> >>
> >
> > I'm the co-author of that note, so I'm all too familiar with it. :-)
> >
> > At the moment, it shouldn't be possible to request html from
> > rdaregistry.info without getting redirected to www.rdaregistry.info(hosted
> > on github using github pages). Although I'm doing a minimal job of
> checking
> > the HTTP Accept header.
> >
> >>
> >> Are you planning on introducing 303-redirects?
> >>
> >
> > I'm deeply embarrassed (really) by the fact that the redirect is not a
> 303
> > and that it may not be consistent. As well as by the fact that it doesn't
> > return the requested fragment (which I still believe is best practice).
> So,
> > yeah, as soon as I get back from the ALA Midwinter conference (sooner if
> I
> > can get some meeting-free time). I'll at least get a 303 redirect header
> in
> > there (still learning nginx).
>
> Oh. I'm going to take a guess that this announcement was pushed out to
> meet an ALA Midwinter deadline, and therefore was a tad premature.
>
> If that's the case (or even if not), why not market it as a beta,
> collect up the known bugs in a visible place, and (perhaps most
> importantly) invite the denizens of the W3C Public Linked Open Data
> mailing list to weigh in on the opaque identifiers vs. meaningful
> identifiers vs. both opaque + meaningful direction? You want this
> vocabulary to be adopted and used; it would be really good to have
> their buy-in to the vision.
>
> In my opinion, I think it would be a mistake to continue with the
> opaque identifiers as the primary identifiers; the vocabulary is
> almost unreadable as it stands. And I believe they will make
> communication between people trying to implement it harder, as they
> continually struggle to translate
> http://rdaregistry.info/Elements/e/actor to
> http://rdaregistry.info/Elements/e/P20012 (because you *know* that
> someone will insist on communicating in opaque identifiers: insert
> flashbacks to "You know, 100 $a $4 act!"). If you *really* want to
> keep the opaque identifiers as an option, you could invert everything
> so that the "owl:sameAs" assertions identify the opaque identifier
> instead, and make the rest of the assertions target the meaningful
> identifiers.
>
> Oh, and on that note there's another technical bug to add to the list:
> the owl:sameAs assertions appear in the RDF/XML document, but they do
> not currently appear in the Turtle document.
>



-- 
Jon