 |
 |
Luckily nobody’s really using it ; so it’s not a huge problem :-D On Jan 24, 2014, at 11:14 AM, Karen Coyle <[log in to unmask]> wrote: > On 1/24/14, 6:56 AM, Jon Phipps wrote: >> >> Thanks for reminding me that this is an academic panel discussion in front >> of an audience, rather than a conversation. >> > > Not entirely clear what you meant by that, but I do think that we have a very practical issue in front of us, and it's one of the things that, IMO, is holding back the adoption of linked data: the limitations of the tools in this area. As I said above, there is no reason why we should be working with "raw" URIs in our work, but few tools present the human-readable labels to the developer. So we are unfortunately forced to work directly with "rdaa:P50209" even though we would prefer to be working with "addressee of" (the rdfs:label). Although we shouldn't be designing vocabularies to make up for the limitations of the tools, it's basically inevitable if we want to get things done. (There are, BTW, enterprise-level tools, but they are beyond the $$ of most folks on this list.) > > I also think that rdfs:label presents us with the same problem that we found with SKOS that led to SKOS-XL and "content as text" -- there are times when you need to say something more about the label; more than what language it is in. It seems quite logical to me that you would have one label for experts, another for the general public; one label for those doing input, another for your basic UI; one label for children, another for adults; etc. You could do that in your application software, but then you aren't sharing it. That you found the need for a local "reg:name" is evidence of this, but it, too, will prove to be inadequate for some needs. > > kc > > -- > Karen Coyle > [log in to unmask] http://kcoyle.net > m: 1-510-435-8234 > skype: kcoylenet