 |
 |
Hi Jon, To present the other side of the argument so that others on the list can make an informed decision... On Thu, Jan 23, 2014 at 4:22 PM, Jon Phipps <[log in to unmask]> wrote: > 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. 100% Agreed. Good documentation is essential for any ontology, and it has to be read to understand the semantics. You cannot just look at oa:hasTarget, out of context, and have any idea what it refers to. However if that URI is readable it makes developers lives much easier in a lot of situations, and it has no additional cost. Opaque URIs for predicates is the digital equivalent of thumbing your nose at the people you should be courting -- the people who will actually use your ontology in any practical sense. It says: We don't care about you enough to make your life one step easier by having something that's memorable. You will always have to go back to the ontology every time and reread this documentation, over and over and over again. Do you have some expectation that in order > for the data to be useful your relational or object database identifiers > must be readable? Identifiers for objects, no. The table names and field names? Yes. How many DBAs do you know that create tables with opaque identifiers for the column names? How many XML schemas do you know that use opaque identifiers for the element names? My count is 0 from many many many instances. And the reason is the same as having readable predicate URIs -- so that when you look at the table, schema, ontology, triple or what have you, there is some mnemonic value from the name to its intent. > By whom, and in English? This to me is a frankly colonial > assumption of the dominance of English in the world of metadata. In the world of computing in general. "for" "if" "while" ... all English. While there are turing complete languages out there, the ones that don't have real world language constructions are toys, like Whitespace for example. Even the lolcats programming language is more usable than whitespace. Again, it's a cost/value consideration. There are many people who will understand English, and when developers program, they're surrounded by it. If your intended audience is primarily people who speak French, then you would be entirely justified in using URIs with labels from French. Or Chinese, though the IRI expansion would be more of a pain :) > The proper > understanding of the semantics, although still relatively minimal, is from > the definition, not the URI. Yes. Any short cuts to *understanding* rather than *remembering* are to be avoided. > 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. So in my opinion, as is everything in the mail of course, this is even worse. Now instead of 1600 properties, you have 1600 * (number of languages +1) properties. And you're going to see them appearing in uses of the ontology. Either stick with your opaque identifiers or pick a language for the readable ones, and best practice would be English, but doing both is a disaster in the making. > 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. Writing queries is something developers have to do to work with data. More importantly, writing code that builds the triples in the first place is something that developers have to do. And they have to get it right ... which they likely won't do first time. There will be typos. That P1523235 might be written into the code as P1533235 ... an impossible to spot typo. dc:title vs dc:titel ... a bit easier to spot, no? So the consequence is that the quality of the uses of your ontology will go down. If there were 16 fields, maybe there'd be a chance of getting it right. But 1600, with 5 digit identifiers, is asking for trouble. Compare MARC fields. We all love our 245$a, I know, but dc:title is a lot easier to recall. Now imagine those fields are (seemingly) random 5 digit codes without significant structure. And that there's 1600 of them. And you're asking the developer to use a graph structure that's likely unfamiliar to them. All in my opinion, and all debatable. I hope that your choice goes well for you, but would like other people to think about it carefully before following suit. Rob