Re: Serialization skos:Concept vs owl:Thing vs rdf..

40 views
Skip to first unread message

smrAZGS

unread,
Aug 18, 2009, 9:26:30 PM8/18/09
to skos-dev
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

Simon Jupp

unread,
Aug 19, 2009, 6:48:45 AM8/19/09
to skos-dev
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

apb

unread,
Aug 24, 2009, 11:14:45 AM8/24/09
to skos-dev
My solution was to save as RDF and write the XSLT below to make all
entries skos:Concept.

An alternative that I am also using is to run Joseki. This provides a
simple Sparql web endpoint for my files . This gives me a consistant
xml format and allows some SKOS type reasoning. Eg if the SKOS has
isNarrower I can query on isBroader.

I am sure Simon would approve more of this route ;-)

/Andy

<?xml version="1.0"?>
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:skos="http://
www.w3.org/2004/02/skos/core#"
xmlns:owl="http://www.w3.org/2002/07/owl#"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<xsl:output method="xml" indent="yes" />
<!-- convert owl thing to skos concept -->
<xsl:template
match="owl:Thing[rdf:type/@rdf:resource='http://www.w3.org/2004/02/
skos/core#Concept']">
<skos:Concept rdf:about="{@rdf:about}">
<xsl:apply-templates />
</skos:Concept>
</xsl:template>
<!-- remove -->
<xsl:template
match="rdf:type[
@rdf:resource='http://www.w3.org/2004/02/skos/core#Concept'
and parent::owl:Thing]"/>

<xsl:template match="@* | node()">
<xsl:copy>
<xsl:apply-templates select="@* | node()" />
</xsl:copy>
</xsl:template>
</xsl:stylesheet>
> > steve- Hide quoted text -
>
> - Show quoted text -

smrAZGS

unread,
Sep 14, 2009, 11:46:44 PM9/14/09
to skos-dev
For interoperability with various tools that are being developed for
vocabulary services (see https://twiki.auscope.org/twiki/bin/view/Grid/VocabularyService;
http://www.r020.com.ar/tematres/index.en.html) and for maintenance of
vocabularies in SKOS (e.g. ThManager http://thmanager.sourceforge.net/
), it would be nice if Protege SKOS plugin didn't mix in owl, and
stuck to a skos core encoding like that described at
https://twiki.auscope.org/twiki/bin/view/Grid/VocabularyFormalization.
Then there would be another tool available for maintaining SKOS docs.

steve

Simon Jupp

unread,
Sep 15, 2009, 9:18:26 AM9/15/09
to skos...@googlegroups.com
Are you saying that those two vocabulary services can't read SKOS
files generated with Protege? I would be interested to know why, as
far as I am concerned the RDF/XML generated is valid SKOS, the fact it
contains a few extra triples that uses some OWL vocabulary shouldn't
matter right, they could simply be ignored.

If this turns out to really be a problem, then I would look into
having an export feature for the SKOSEd plugin that was stricter about
the RDF/XML it generated.

Cheers
Simon
Simon Jupp
simon...@manchester.ac.uk
http://www.cs.man.ac.uk/~sjupp/




Reply all
Reply to author
Forward
0 new messages