[PORT] FW: SKOS XML syntax?

Forwarded copy of discussion between myself and Phil re a schema constrained XML syntax for SKOS (thanks Phil :) ...

----------------

I've had requests from several quarters for a schema-constrained XML syntax
for SKOS Core.  I had a think about this, and it's quite difficult to come
up with a schema for an XML syntax that can capture the full SKOS Core
model, that is extensible, and that isn't too verbose or complicated.
Anyway, as an experiment I had a first go, see:

http://isegserv.itd.rl.ac.uk/cvs-public/~checkout~/skos/sxs/sxs-a/schema.rnc

http://isegserv.itd.rl.ac.uk/cvs-public/~checkout~/skos/sxs/sxs-a/instance.xml

http://isegserv.itd.rl.ac.uk/cvs-public/~checkout~/skos/sxs/sxs-a/2rdfxml.xslt


... all a bit scruffy.  The schema is a relaxng schema in the compact
syntax (supports a more flexible content model, good for the three patterns
we allow for documentation properties) and the transformation is an XSLT
2.0 stylesheet (needed for functions on QNames and namespace prefixes).


-----Original Message-----
From: Phil Tetlow [mailto:philip.tetlow@uk.ibm.com]
Sent: 17 June 2005 08:31
To: Miles, AJ (Alistair)
Subject: SKOS XML
Importance: High

Alistair

I am, of course willing to help in any way that I can with an XML version
of SKOS, but I would question the validity of the use case behind an XML
version, especially in relation to e-government. As you know I have done a
lot of this type of work in the past and have come across the 'we would
rather express this in XML for integration reason' position a number of
times. In my experience what most developers are actually saying is 'I just
about understand XML, but have never been able to get my head around this
Sem Web stuff - help me out here because I cant be bothered to make the
effort'. Furthermore this tends to come back to the fact that the Sem Web
is extremely abstract. Most techies have a problem dealing with the
definition of raw data, let alone metadata, and their head explodes when
you quickly try to explain the difference between hierarchy, taxonomy,
topology and ontology. This is a real problem for the Sem Web, but on every
occasion I have personally fought against 'lowering the Sem Web bar'.
Instead I have invested more time with the organisations and individuals
involved, explaining that there are already great technologies out in the
big wide world to handle abstract knowledge organisation properly (of which
RDF and SKOS are fine examples). On every occasion I believe that this
additional effort was worth while. Additionally I might point out that
e-government technology standard for web-based sememantic type stiff  is
RDF, as listed in the eGIF standards paper, so by using SKOS e-government
projects would actually be demonstrating compliance with UK government
guidelines.


-----Original Message-----
From: Miles, AJ (Alistair)
Sent: 20 June 2005 12:42
To: 'Phil Tetlow'
Subject: RE: XML SKOS


Hi Phil,

I've actually come up with what I think is a reasonable solution for a
schema-constrained XML syntax for SKOS that has a GRDDL transform, check
out an instance ...

http://isegserv.itd.rl.ac.uk/cvs-public/~checkout~/skos/sxs/sxs-a/instance.xml


... a schema ...

http://isegserv.itd.rl.ac.uk/cvs-public/~checkout~/skos/sxs/sxs-a/schema.rnc


... an XSLT transform ...

http://isegserv.itd.rl.ac.uk/cvs-public/~checkout~/skos/sxs/sxs-a/2rdfxml.xslt


... and the transformation output ...

http://isegserv.itd.rl.ac.uk/cvs-public/~checkout~/skos/sxs/sxs-a/transformed.rdf.xml


... what do you think?  It supports property refinement extensions, an
simple versus structured note types.

Al.

-----Original Message-----
From: Phil Tetlow [mailto:philip.tetlow@uk.ibm.com]
Sent: 20 June 2005 13:55
To: Miles, AJ (Alistair)
Subject: RE: XML SKOS
Importance: High

Alistair

All really cool stuff, but unfortunately I still do not get the point -
sorry. Why flatten out SKOS in this way? Is is it because you want to
remove the need for multiple namespaces as a result or parser limitations?

So here is my problem.... RDF and SKOS are XML anyway, so why look for
another XML format for representation. I actually had a similar debate
about 18 months ago and unfortunately lost the battle. On one of my recent
projects
we had a need to model some very complex concepts and I wanted to do this
using OWL because of the increased constraints and formality the
language/schema provided. In the end I lost and we are still not using any
real Sem Web languages. This was because the powers that be stated that any
flavour of XML could be used to describe the ontologies required, so long
as the constituent parts were named, qualified, constrained and associated
properly....!!! They were of course correct, but I argued the inference,
knowledge integration and fledgling standards until I was blue in the face.

My standpoint is still that RDF and OWL are better because...
      1. There are already large communities working on these standards
with some very bright minds amongst them - chances are that they will get
it right whereas we (the project team) will get it wrong
      2. Minimisation of information structure (ie triples) is a good thing
- trust me I a Buddhist ;0)
      3. If there are already standards in this area then lets use them to
standardise - diversification will not add any real benefit and points the
way to sure ruin!

-----Original Message-----
From: Miles, AJ (Alistair)
Sent: 20 June 2005 19:22
To: 'Phil Tetlow'
Subject: RE: XML SKOS


Hey Phil,

Actually what I am suggesting is to offer something like SXS-A as an
alternative to *RDF/XML*, not to RDF or OWL themselves.  I.e. SXS-A is just
an alternative transport container.  It is rooted in the RDF model, because
its semantics are entirely determined by the transformation that generates
RDF triples.

Why bother? e.g. ...

 - so B2B transactions involving SKOS data could do simple message
validation using XML tools ...
 - so XML driven web applications that use XSLT, XPATH ... could run on
SXS-A ...
 - so you could implement doc-lit web services that pass SKOS data around
...

There is another benefit to using XML tools, e.g. where you want to grok a
small bit of data out of a big data set, and you don't want to load the
whole thing into memory or a database before you can process it.  A schema
constrained XML format allows streaming.

An (imagined) real-world example of this ... say I'm authoring a SKOS
concept scheme in my SKOS author tool, and I want to import a few concepts
from the Art and Architecutre thesaurus.  I point my tool to the AAT data,
and have to sit there and wait for a good while before the thing presents
me with a list of the concepts I want to import.

... and SXS-A has a GRDDL transform that generates pure RDF/XML, so if you
want to parse it as RDF you can.  XML-heads can use XML tools, and
RDF-heads can use RDF tools.

Can we note have our cake and eat it? :)

Cheers,

Al.

-----Original Message-----
From: Phil Tetlow [mailto:philip.tetlow@uk.ibm.com]
Sent: 21 June 2005 08:56
To: Miles, AJ (Alistair)
Subject: RE: XML SKOS

Alistair

All fine, well and good but I still worry about standards dilution. At the
end of the day RDF and OWL are just 'alternative transport containers' as
well but at least they have standards consensus on their side. Its not that
I have a problem with SXS-A (and I will of course help you with the schema
if you like), it is more that I have a problem with 'alternatives'.

In response to your examples...

 - so B2B transactions involving SKOS data could do simple message
validation using XML tools ...
      a) In my experience eCommerce applications are typically only
interested in passing raw data. They already fully understand the context
and reasoning behind a relevant transaction before it is instigated. SKOS,
for me, comes into its own by 'adding value'in a KR sense. Amongst this
class of application, in most cases all understanding is already built into
the sending and receiving software. Even so message validation with RDF and
OWL is not so hard, the last time I did any work like this I seem to recall
a number of parsers capable of chewing such XML forms and returning
something useful.

 - so XML driven web applications that use XSLT, XPATH ... could run on
SXS-A ...

Not so sure bout XPath and SXS-A/RDF/OWL. If I remember correctly the DAWG
fought hard against XPath in favour of SPARQL. I remember having a number
of conversations with EricP and Bob Lojek on this subject and the consensus
was that XPath was a somewhat incomplete view of the world with
insufficient navigational capability - you cannot traverse across documents
for example...As for XSLT, why can you not use it properly on any compliant
for of XML (of which RDF and OWL are)?

 - so you could implement doc-lit web services that pass SKOS data around
...

Here I actually definitely stand in favour of RDF and OWL. For me web
service standards are still way too immature so the work on Semantic Web
Services (OWL-S) looks really cool to me. Hence, for the web service world,
it makes sense to me to transport data using similar frameworks to those
used for describing the services in the first place. hence, in a perfect
world, I would love to see OWL extensions to SOAP for example, but I dont
realistically think that it will ever happen.

Kind regards

Phil Tetlow


-----Original Message-----
From: Miles, AJ (Alistair)
Sent: 21 June 2005 11:52
To: 'Phil Tetlow'
Subject: RE: XML SKOS


Hey Phil,

> Not so sure bout XPath and SXS-A/RDF/OWL. If I remember
> correctly the DAWG
> fought hard against XPath in favour of SPARQL. I remember
> having a number
> of conversations with EricP and Bob Lojek on this subject and
> the consensus
> was that XPath was a somewhat incomplete view of the world with
> insufficient navigational capability - you cannot traverse
> across documents
> for example...As for XSLT, why can you not use it properly on
> any compliant
> for of XML (of which RDF and OWL are)?

The problem is the inherent variability of RDF/XML - which from one point
of view is a great thing, but makes it very hard to write XSLT stylesheets
for RDF/XML instances.

For instance, one of the first demos of an application running on top of
SKOS data is ...

http://www.comp.glam.ac.uk/~facet/formats/skos/skos_search.htm

... which only works because the underlying RDF/XML is in a particular
form.  If the same RDF data were serialised as RDF/XML a bit differently it
would break.  This example illustrates that XPath and XSLT are not the
right tools for working with RDF/XML.

You have to understand the primary community I'm trying to support.  These
are digital librarians and thesaurus developers, who are usually state
funded and are not expert hackers.  They have a small amount of effort, and
a small amount of funding, and anything I can do to make their life easier
goes a long way.  This community is just getting into XML, and they had a
schema constrained XML syntax they could be off the ground much faster than
with RDF alone.  It's about lowering the entry barrier.  They get an XML
syntax they can work with, they start to do things with it using XML tools,
realise the limitations, then get interested in what RDF technologies can
do.

Am I making sense?

Cheers,

Al.


-----Original Message-----
From: Phil Tetlow [mailto:philip.tetlow@uk.ibm.com]
Sent: 21 June 2005 13:04
To: Miles, AJ (Alistair)
Subject: RE: XML SKOS

Alistair

No problem at all with going on record and please feel free to call me
later this afternoon.

I fully understand your point on community but I also think that this is a
significant weakness of  Sem Web technologies - they are not not overly
friendly for novice users....This has concerned me from day one, but there
are arguments both in favour and against lowering the bar, as it were.


Regards

Phil Tetlow
Senior Consultant
IBM Business Consulting Services

Received on Monday, 27 June 2005 18:15:52 UTC