- From: Simon Cox <simon.cox@jrc.ec.europa.eu>
- Date: Wed, 16 Sep 2009 17:44:08 +0200
- To: "'Simon Jupp'" <simon.jupp@manchester.ac.uk>
- Cc: <steve.richard@azgs.az.gov>, "'Guillame Duclaux'" <Guillaume.Duclaux@csiro.au>, <public-esw-thes@w3.org>, <Jacqueline.Githaiga@csiro.au>
- Message-ID: <B24174A74D1B4A06973B4EA856C70C0D@H07.jrc.it>
OK - I've just checked the SKOS Reference Recommendation, and see that the relationship between SKOS and OWL is normative, so you are correct. I thought I recalled that SKOS was defined only in terms of RDF and RDFS, with the links to OWL being non-normative, but maybe that was an earlier version, or maybe I'm mistaken. Nevertheless, it does somewhat undermine the rationale for SKOS to convert an ontology into OWL terminology when it had been formalized using only RDF and SKOS. SKOS is intended to be a bridge for communities whose requirements do not require OWL. I'm currently trying to convince a couple of communities (GeoSciML, GML) that they should replace their bespoke vocabulary encodings with SKOS, since SKOS appears to satisfy almost all the requirements from those communities. The target audience comes from an XML/XSD background, so there is an initial challenge in getting over the RDF data-model humps (e.g. the fact that many serializations are fully equivalent). This would be easier if the tools did not all-of-a-sudden munge the resource types (even if the munging is correct according to RDF/OWL model). But perhaps I've just got to get over that. --- Meanwhile, the goal we are pursuing a 'simple' vocabulary service interface, to complement the first S in SKOS. i.e. given a basic vocabulary model (SKOS), with a limited gamut of resource and property types, to provide a small set of queries optimised to these. Our approach is to implement this on top of SPARQL, so the queries must be expressible in SPARQL. I just checked the documentation prepared by my developer, mapping the queries to SPARQL (https://twiki.auscope.org/twiki/bin/view/Grid/VocabularyService02). It turns out that all the queries we have implemented so far rely only on the SKOS properties, and are independent of the resource type. So it turns out that it does not matter to the query engine whether the resources are skos:Concepts, rdf:Descriptions, owl:Things, or foo:Bars. It does matter to some XSLT processing tools that we have developed, but I guess that points to the fact that SPARQL etc is the appropriate interface for processing RDF, not XSLT. -------------------------------------------------------- Simon Cox European Commission, Joint Research Centre Institute for Environment and Sustainability Spatial Data Infrastructures Unit, TP 262 Via E. Fermi, 2749, I-21027 Ispra (VA), Italy Tel: +39 0332 78 3652 Fax: +39 0332 78 6325 <mailto:simon.cox@jrc.ec.europa.eu> mailto:simon.cox@jrc.ec.europa.eu <http://ies.jrc.ec.europa.eu/simon-cox> http://ies.jrc.ec.europa.eu/simon-cox SDI Unit: <http://sdi.jrc.ec.europa.eu/> http://sdi.jrc.ec.europa.eu/ IES Institute: <http://ies.jrc.ec.europa.eu/> http://ies.jrc.ec.europa.eu/ JRC: <http://www.jrc.ec.europa.eu/> http://www.jrc.ec.europa.eu/ -------------------------------------------------------- _____ From: Simon Jupp [mailto:simon.jupp@manchester.ac.uk] Sent: Wednesday, 16 September 2009 15:24 To: Simon Cox Cc: steve.richard@azgs.az.gov; 'Guillame Duclaux'; public-esw-thes@w3.org Subject: Re: [Fwd: Re: Serialization skos:Concept vs owl:Thing vs rdf..] Protege and the SKOSEd plugin don't "promote" SKOS to OWL. The SKOS concepts and relationships are defined as an OWL vocabulary. When you load SKOS files into Protege you simply get a representation of what was asserted (which may include additional triples that are inferred, such as those asserting rdf:type owl:Thing). Any SKOS exported from Protege as RDF/XML is likely to contain these triples that use the OWL vocabulary, but why should this matter to any tool that consumes RDF? Any constructs they don't handle should just get ignored. If a service can't handle the RDF (and SKOS) generated by Protege then I would be interested to know why, it is after all just RDF, nothing special about it because it has some additional OWL vocabulary in there. On the point of consistent serialisation, I can sort of see a case for being consistent, but RDF can be serialised to XML in multiple ways, so I wouldn't expect any tool to rely on particular style. SKOS was designed to be flexible and extensible, this means it's quite hard to define what pure SKOS is, any standalone SKOS editor will have limits on what can be expressed. To provide ultimate flexibility you would need an OWL full or RDF editor, but this is possibly the wrong level of abstraction for most people working with SKOS. Cheers Simon On 15 Sep 2009, at 07:51, Simon Cox wrote: I guess Protege uses OWL as its internal model, so this kind of behaviour, though annoying, is to be expected. What this points to is that the world needs a RDF or SKOS editor that does not gratuitously promote everything up to OWL. Promoting everything to OWL kinda misses the point of having SKOS, which is explicitly for applications that do not need to go all the way to OWL. I'll forward this to the W3C SKOS list, since it is a follow-up to the discussion we triggered in June. -------------------------------------------------------- Simon Cox European Commission, Joint Research Centre Institute for Environment and Sustainability Spatial Data Infrastructures Unit, TP 262 Via E. Fermi, 2749, I-21027 Ispra (VA), Italy Tel: +39 0332 78 3652 Fax: +39 0332 78 6325 <mailto:simon.cox@jrc.ec.europa.eu> mailto:simon.cox@jrc.ec.europa.eu <http://ies.jrc.ec.europa.eu/simon-cox> http://ies.jrc.ec.europa.eu/simon-cox SDI Unit: <http://sdi.jrc.ec.europa.eu/> http://sdi.jrc.ec.europa.eu/ IES Institute: <http://ies.jrc.ec.europa.eu/> http://ies.jrc.ec.europa.eu/ JRC: <http://www.jrc.ec.europa.eu/> http://www.jrc.ec.europa.eu/ -------------------------------------------------------- _____ From: Stephen M Richard [mailto:steve.richard@azgs.az.gov] Sent: Monday, 14 September 2009 19:30 To: Simon Cox; Guillame Duclaux Subject: [Fwd: Re: Serialization skos:Concept vs owl:Thing vs rdf..] Simon, Gilly-- I noticed that Protege is randomly encoding as either skos:concept or owl:thing with rdf:type=&skos;Concept. I posted a question on the skos-dev list, here's simon's response (full discussion at http://groups.google.com/group/skos-dev/browse_thread/thread/1b37afd209da564 d?hl=en). Someone posted an xslt to get rid of the owl:things. Basically its a Protege issue--what I started with is all skos. steve -------- Original Message -------- Subject: Re: Serialization skos:Concept vs owl:Thing vs rdf.. Date: Wed, 19 Aug 2009 03:48:45 -0700 (PDT) From: Simon Jupp <mailto:simon.jupp@gmail.com> <simon.jupp@gmail.com> Reply-To: skos-dev@googlegroups.com To: skos-dev <mailto:skos-dev@googlegroups.com> <skos-dev@googlegroups.com> References: <mailto:d8e4f408-dc49-49e9-be28-e2c4ad9c11cf@i18g2000pro.googlegroups.com> <d8e4f408-dc49-49e9-be28-e2c4ad9c11cf@i18g2000pro.googlegroups.com> I don't see why it matters, when you say unclean, do you mean for the human eye? Can you give an example where this might be a problem? It is a little redundant, but it shouldn't be a problem for any tools that consume RDF/XML. Looking at your files I do see that the RDF/XML rendering seems to be a little inconsistent. I will speak to the OWL API developer to find out why this is. Cheers Simon On Aug 19, 2:26 am, smrAZGS <mailto:steve.rich...@azgs.az.gov> <steve.rich...@azgs.az.gov> wrote: > I've noticed the same issue. Converting to OWL doesn't seem like a > solution, since the point of a SKOS encoding is to use elements in > the SKOS namespace. I recognize that skos:concept and owl:thing with > rdf:type=&skos;Concept are logically equivalent, but isn't is > problematic if you're trying to automate use of the document if the > encoding might use one of two equivalent syntax approaches in the same > document- it just doesn't seem 'clean'. If a document is supposed to > be a SKOS encoding it seems like there should be some way to ensure > that it uses SKOS elements, not owl? > > steve --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "skos-dev" group. To post to this group, send email to skos-dev@googlegroups.com To unsubscribe from this group, send email to skos-dev+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/skos-dev?hl=en -~----------~----~----~----~------~----~------~--~--- -- 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 Wednesday, 16 September 2009 15:59:53 UTC