- From: Karen Coyle <kcoyle@kcoyle.net>
- Date: Tue, 19 Apr 2011 09:10:23 -0700
- To: public-lld@w3.org
Quoting Antoine Isaac <aisaac@few.vu.nl>: > > Trying to understand, is something like Poolparty [1] at the right > level of tooling you'd be expecting (for SKOS in that case)? The only example of a tool that is at the right level of service that I know of is the Open Metadata Registry. A Poolparty implementation might also be an example (I looked at it briefly but couldn't get a good understanding so quickly). The registry is a tool with a full user interface that requires very little (if any) knowledge of the underlying LD code. Users fill in a form for names, labels, descriptions, broader terms, and that's all. The service then provides all of the translation of this to RDF/OWL/SKOS. If I were to give requirements for a tool, it would be: - requires no technical skills beyond those of a general computer user (meaning either online forms or a program that an average Windows user can install) - the interface is expressed in the language of the user - provides help and direction where decisions must be made Note, however, the the Registry and Poolparty are designed for DEVELOPMENT of metadata properties and vocabularies, and what we really need are tools that help us create and use the instance data. That's the tool that I am asked about every time I speak about LD. The people who would create the properties in Poolparty are not the same people who would create the instance data (in most cases) and tools for the latter must be even closer to the mental models used by those data creators. kc > does implement some linked data technology, its adaptation to one > domain (SKOS) makes it a bit more community-friendly. > (at everyone: I'm just using Poolparty for the sake of the example here!) > > > Now, on whether we should aim to produce a fully-fledged list of > tools in the small amount of time we have left, I share Emmanuelle's > doubts. Given the maturity of the field, there are not many > library-focused tools. Plus it would take quite some time to > investigate. > > I'd be more than happy to put such a list among our recommendation > for future work, though. And even, to try and present an > infrastructure to start the listing, as we've done for datasets at > CKAN [2]. > > In fact I do really like what Jeff has done in this respect, making > reference to the tool lists at W3C, like [3] or [4]. > A contribution from our group in the coming weeks may be to identify > whether we could use the W3C infrastructure for this. I think the > W3C templates are pretty flexible, we could maybe add a tag > "library" to be used by the tool publishers when they want to > advertise their stuff on W3C there. And then create a wiki page at > W3C which would pull dynamically the tools annotated with that tag. > Just as the SKOS tool section on the W3C wiki was created [4]. > > If that's deemed interesting, we could ask the W3C team what they > think of it. > > Cheers, > > Antoine > > [1] http://www.w3.org/2001/sw/wiki/PoolParty > [2] http://ckan.net/group/lld > [3] http://www.w3.org/2001/sw/wiki/OWL > [4] http://www.w3.org/2001/sw/wiki/SKOS > >> >> Lukas Koster >> >> On 18-4-2011 7:53, Emmanuelle Bermes wrote: >>> On Sun, Apr 17, 2011 at 7:04 PM, Karen Coyle<kcoyle@kcoyle.net> wrote: >>>> Nice and concise, Jeff. >>> >>> +1 ! >>> >>>> >>>> I wonder, though, about our focus for this section and for the >>>> vocabularies >>>> section. The latter mixes LLD and BLD (B = bibliographic). If we agree >>>> that's a good scope then we should bring the "B" word into the >>>> report early >>>> on. I think it would be hard to separate library and bibliographic, >>>> especially when we are talking about linked data where the two will >>>> presumably blend together in actual use. >>>> >>>> The tools here seem to be general SemWeb tools, so to include these in our >>>> report we need to give a reason why they are here. >>> >>> You're right on this, Karen. >>> In the 1st place, we thought of including a "tools" section because >>> it's something that is needed and asked for by the community. Maybe >>> its place is not in the report, though. >>> This very interesting starting point created by Jeff could be >>> considered as a preview of what we recommend be elaborated - a list of >>> tools that can help create LLD. >>> It's also probably possible to state that one "requirement" for LLD is >>> that tools are available. A possible recommendation could be to >>> evaluate these tools, and check if they need be adapted for LLD. >>> >>> Also, maybe a better sense of what "tools" are expected is needed. I >>> suspect that people asking for tools in the library community are more >>> or less hoping that we will point them to a ready-made "marc-2-rdf" >>> converter, or a GUI for cataloguing books as triples, or even an >>> rdf-based OPAC. Not sure that developper tools will seem relevant to >>> them, what do you think ? >>> >>> Should we point in the report to experiments like Lukas' [1] or >>> initiatives like eXtensible Catalog [2] ? >>> >>> Emma >>> >>> [1] http://lists.w3.org/Archives/Public/public-lld/2011Apr/0069.html >>> [2] http://lists.w3.org/Archives/Public/public-xg-lld/2011Apr/0034.html >>> >>> >>> I don't know of any >>>> specific LLD tools, does anyone?. (The closest I can think of is the Open >>>> Metadata Registry, which has an input interface to RDA and other library >>>> vocabularies, but it also includes non-library vocabularies.) We could say >>>> that "tools are tools" and we don't have/expect LLD-specific tools, or we >>>> could say that LLD-specific tools will be built on these tools... >>>> >>>> kc >>>> >>>> Quoting "Young,Jeff (OR)"<jyoung@oclc.org>: >>>> >>>>> Here's a rough draft of the Relevant Technologies section that I >>>>> promised. It looks like the W3C keeps good lists of tools for several of >>>>> these categories, so I deferred to them whenever possible. >>>>> >>>>> >>>>> >>>>> http://www.w3.org/2005/Incubator/lld/wiki/Draft_Relevant_Technologies >>>>> >>>>> >>>>> >>>>> Comments, suggestions, and elaborations are welcome. >>>>> >>>>> >>>>> >>>>> Jeff >>>>> >>>>> >>>>> >>>>> --- >>>>> >>>>> Jeffrey A. Young >>>>> Software Architect >>>>> OCLC Research, Mail Code 410 >>>>> OCLC Online Computer Library Center, Inc. >>>>> 6565 Kilgour Place >>>>> Dublin, OH 43017-3395 >>>>> www.oclc.org<http://www.oclc.org> >>>>> >>>>> Voice: 614-764-4342 >>>>> Voice: 800-848-5878, ext. 4342 >>>>> Fax: 614-718-7477 >>>>> Email: jyoung@oclc.org<mailto:jyoung@oclc.org> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> -- >>>> Karen Coyle >>>> kcoyle@kcoyle.net http://kcoyle.net >>>> ph: 1-510-540-7596 >>>> m: 1-510-435-8234 >>>> skype: kcoylenet >>>> >>>> >>>> >>> >> > > > -- Karen Coyle kcoyle@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet
Received on Tuesday, 19 April 2011 16:10:53 UTC