Luckily nobody’s really using it ; so it’s not a huge problem :-D On Jan 24, 2014, at 11:14 AM, Karen Coyle <[email protected]> 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 > [email protected] http://kcoyle.net > m: 1-510-435-8234 > skype: kcoylenet
