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