- From: Simon Jupp <simon.jupp@manchester.ac.uk>
- Date: Thu, 18 Jun 2009 11:08:19 +0100
- To: <Simon.Cox@csiro.au>
- Cc: SKOS <public-esw-thes@w3.org>, steve.richard@azgs.az.gov, User support for the Protege-OWL editor <protege-owl@lists.stanford.edu>, skos-dev@googlegroups.com
Hi Simon, I'm can't diagnose the problems you are experiencing with SKOSEd from this mail alone. We have a mailing list at skos-dev@googlecode.com and I would encourage you to post any bugs to that list so I can deal with it properly. Round tripping and import/export is vague, what is the problem exactly? Have you got a test case? Not sure about the label issue either, the current version of the SKOS plugin treats labels as owl datatype properties and has full support for typed and untyped literals along with language attributes. I would need a copy of the SKOS file to confirm this but I suspect Steves problem is that a resource has been used as the object of a prefLabel assertion, this causes protege to treat prefLabel as an OWL object property. All of this will go away in the next version of Protege 4.1 and SKOSEd as all skos labels will simply be handled as OWL annotations. Steve, could you send me a snippet of your SKOS file so I can try to recreate this behaviour? I should point out that the SKOS plugin and Protege are OWL 2 editors and are designed for users wanting to stay in a decidable fragment of OWL, more details can be found in this paper I presented at ESWC the other week [1]. As for other tools, I never found anything that worked for me which is why I wrote the SKOS plugin for Protege 4 in the first place. I accept it is not a polished piece of software and it's currently aimed at people familiar with both Protege and the OWL nature of SKOS. The plan is to release a standalone SKOS editor based on the Protege platform that hides a lot of the 'OWLiness' from the average user. I am providing support/bug fixes/feature requests etc.. on demand at the moment and encourage feedback from users which is the only way the tool will improve!! It's an open source project hosted on google code so any java developers who would like to join/contribute to the project should get in touch with me, I will be at the Protege conference next week if anyone wants to discuss this further. Cheers Simon 1 - Simon Jupp, Sean Bechhofer, Robert Stevens: A Flexible API and Editor for SKOS. ESWC 2009: 506-520. http://www.springerlink.com/content/d6703475j580h618/ On 18 Jun 2009, at 02:53, <Simon.Cox@csiro.au> wrote: > Dear SKOS list - > > The GeoSciML project has been evaluating SKOS to implement its > 'controlled concpet' model (see http://www.geosciml.org/geosciml/2.0/doc/GeoSciML/Vocabulary/package-summary.html > for the UML representation, and you'll see how SKOS is a close > match!). > My colleague Steve Richard is the lead editor, on behalf of a > consortium including many of the world's leading geological > surveys*, for around 25 vocabularies related to geology. > This is a significant effort in the natural sciences. > > Being a happy old XML hacker I can tolerate RDF/XML and a text > editor for prototyping. > But this obviously ain't acceptable for most users, doesn't scale to > production work, and fails to provide the consistency checking and > visualization that a proper editor would. > > We are mighty frustrated (and getting worse!) at the state of tool > support. > In particular, Protégé, even with the SKOS plugin, appears to be > fatally flawed. > I've used it from time to time for _viewing_ a concept scheme, but > have never been able to successfully round trip through export/ > import, so it doesn't work as an editor. > Steve is now finding further flaws - see below - e.g. labels > implemented as objectProperty, no literal support or language > attributes. > > This is all very disappointing. > What tools are people people using successfully for development and > management of SKOS instances? > > Simon Cox > > (*) See http://onegeology.org/technical_progress/geosciml.html and http://onegeology.org/participants/graphical_map.html > > ______ > Simon.Cox@csiro.au CSIRO Exploration & Mining > 26 Dick Perry Avenue, Kensington WA 6151 > PO Box 1130, Bentley WA 6102 AUSTRALIA > T: +61 (0)8 6436 8639 Cell: +61 (0) 403 302 672 > Polycom PVX: 130.116.146.28 > <http://www.csiro.au> > > ABN: 41 687 119 230 > > -----Original Message----- > From: stephen richard [mailto:steve.richard@azgs.az.gov] > Sent: Thursday, 18 June 2009 9:31 AM > To: Cox, Simon (E&M, Kensington) > Subject: Re: [Auscope-geosciml] Simple lithology vocabulary in MMI > repository > > Right now I'm mostly frustrated- > the new version of Protege (v4, released today) doesn't preserve > language attributes on prefLabel elements, and the SKOS tool models > prefLabel as an ObjectProperty, so you can't populate it with a > literal, and it doesn't appear to be consistent with the current > SKOS spec. > What I started out to do was clean up the hierarchy in > standardLithology, which is a mess. The owl/SKOS tools looked like a > possible way to do it. Instead I've spun my wheels for 3 days. The > idea is simply to be able to round trip between GeologicVocabulary > and some brand of SKOS, for which there is a functional tool, build > and fix hierarchies in SKOS, and convert back to GeologicVocabulary > to update in the BRGM repository. Meanwhile there are the > possibilities of vocabulary services that could assist with document > validation and better yet query resolution with hierarchical > properties... > > What's AuScope using for SKOS tools? > > steve > > Simon.Cox@csiro.au wrote: >> Steve >> Good hunting. >> >> A few comments and a bit of an update about where the AuScope >> vocabs/vocab-server work is at: >> >> >> i. Terms and Labels - >> skos:prefLabel, skos:altLabel, skos:hiddenLabel and skos:notation >> can and should be used to support the assignment of multi-lingual >> terms, synonyms, misspellings (!) and symbols to concepts, >> regardless of the encoding (OWL, SKOS, other RDF languages). The >> semantics of these are clear and relevant to our needs, and the >> rdfs:domain of all of these is unrestricted so they can be applied >> to any rdf resource. >> >> > ... > > -- > Stephen M. Richard > Section Chief, Geoinformatics > Arizona Geological Survey > 416 W. Congress St., #100 > Tucson, Arizona, 85701 USA > > Phone: > Office: (520) 209-4127 > Reception: (520) 770-3500 > FAX: (520) 770-3505 > > email: steve.richard@azgs.az.gov > > Simon Jupp simon.jupp@manchester.ac.uk http://www.cs.man.ac.uk/~sjupp/
Received on Thursday, 18 June 2009 10:08:57 UTC