W3C home > Mailing lists > Public > public-esw-thes@w3.org > June 2005

RE: SKOS to RDFS/OWL ontology mapping

From: Miles, AJ \(Alistair\) <A.J.Miles@rl.ac.uk>
Date: Wed, 15 Jun 2005 15:46:42 +0100
Message-ID: <F5839D944C66C049BDB45F4C1E3DF89DEE9DCD@exchange31.fed.cclrc.ac.uk>
To: "Bernard Vatant" <bernard.vatant@mondeca.com>, "Mikael Nilsson" <mini@nada.kth.se>
Cc: <public-esw-thes@w3.org>, "Dan Brickley \(E-mail\)" <danbri@w3.org>

Hi all,

I think we need to stay practical here and focus on the use cases (or we'll be here until the end of existence :).

Danbri's original use case is something like this (Danbri please correct me if I'm wrong):

Blogger A uses some category C to categorise blog items. 
Blogger B uses some category D to categorise blog items.

Blogger's A and B realise that categories C and D are really about the same thing, and want to express that so that both their blog feeds can be harvested and sensibly merged.

The inverse property pair 'skos:it' and 'skos:as' were originally proposed in response to this use case.

I.e. blogger A says 'C skos:it X' and blogger B says 'D skos:it X' and they both live happily every after.

Sensible? Alternatives?
Regarding ...

eg:People a skos:Concept;
	owl:sameAs foaf:Person.

The problem here is practical, to do with the merging of graphs.  If another party comes along and says ...

eg2:People a skos:Concept;
	owl:sameAs foaf:Person.

... then you get ...

eg2:People owl:sameAs eg:People.

... and all the properties get jumbled up.  Two preferred labels, two definitions, lots of alternative labels, two dates of creation, two dates of last modification, and hard to find out which belongs to which etc.

That was the motivation behind a mapping vocabulary, so that you could say ...

eg2:People map:exactMatch eg:People.

... which tells everyone they carry the same meaning, but prevents the nodes from getting merged in a graph.

Further thoughts?


Alistair Miles
Research Associate
CCLRC - Rutherford Appleton Laboratory
Building R1 Room 1.60
Fermi Avenue
Oxfordshire OX11 0QX
United Kingdom
Email:        a.j.miles@rl.ac.uk
Tel: +44 (0)1235 445440

> -----Original Message-----
> From: public-esw-thes-request@w3.org
> [mailto:public-esw-thes-request@w3.org]On Behalf Of Bernard Vatant
> Sent: 15 June 2005 15:02
> To: Mikael Nilsson
> Cc: public-esw-thes@w3.org
> Subject: RE: SKOS to RDFS/OWL ontology mapping
> Hi Michael
> > Let me try to add some comments...
> You're welcome :))
> > Bernard Vatant wrote:
> > > ... blank nodes are the best way to "capture" implicitly
> > > this subject without identifying it to a resource, which,
> > > I agree with what you wrote a few posts ago, would lead 
> us to recursive definitions.
> > Well, I think there are several issues with this argument.
> >
> > First, Alistair might define A skos:it B to mean:
> >    "B is the RDFS representation of the 'subject' that has A as SKOS
> >     representation".
> Sure it might. And keep agnostic about what this subject is. 
> Although this declaration is
> not symetric.
> Is it made from eg: or foaf: namespaces' publishers viewpoint?
> > This shows that even though you might not perceive a direct 
> relationship
> > between the two, I can come up with a perfectly valid property to
> > "shortcut" any indirect relation.
> Agreed
> > Put another way, the existence of an
> > intermediate node does not preclude the use a direct property to
> > describe this relationship. Such a relationship can even be 
> expressed in
> > OWL and so inferred automatically...
> Well, that sets another issue: What do we want this kind of 
> assertion for? To make some
> kind of inference, and if so, which kind? My view was that 
> what we want to capture here is
> at a level on which any inference would be risky.
> > See below, however, for reasons for
> > not wanting to do it using direct properties anyway.
> We'll see :))
> > Second, you say "subjects have no identity". Unfortunately you
> > contradict this by giving the (admittedly blank) subject node the
> > (locally valid) identifier _:node1.
> I don't see any contradiction. The subject is not the node. 
> The node is identified OK,
> although only locally, but not the subject itself which is 
> only implicitely defined.
> Otherwise I won't use a blank node, I would define a 
> resource, and assign an URI, and go a
> stage further in recursivity trap : what is the type of this 
> resource, what are its
> properties etc. All the point is indeed to have the subject 
> not identified to/by any
> resource, or any identifier of this resource. The node *is* 
> not the subject.
> > You must look closer at the definition of "having identity".
> Hmm. Let's say I can claim this is something I have looked at 
> quite closely for a certain
> number of years now - maybe to the point of blindness, though :)) See
> http://universimmedia.blogspot.com/
> > I believe one good definition is "being separable from 
> other things".
> I buy it. But separation in things is only possible in 
> representations, because things
> exist only in representations. What I claim is that our 
> "subject of conversation" is never
> identified as such, its'not an owl:Thing. We identify 
> representations, and at some point
> we want to link two representations. Note that each 
> representation taken standalone is
> built on specific logic rules. So logical integration of two 
> different representation
> spaces is most of the time impossible if they are built on 
> different logical frameworks.
> > So if you are giving your subject a blank node, it is very 
> much separable from
> > other things. Indeed that is the very reason you create 
> this blank node
> > - to be able to *identify* the subject of your properties...
> "The node is separable from other nodes" does not mean "the 
> subject is separable from
> other subjects". In Quantum Mechanics, there are a lot of 
> situations of that kind ... I
> can define another node including e.g.  b:Human and  
> eg:People. As a node, it will be
> distinct from the previous one, but the fact that they are 
> about the same or different
> subject is undecidable, basically.
> Look at Google News, and tell me what is a News subject, and 
> how it's identified ...
> > If something does not have an identity, you cannot even use 
> a blank node
> > to refer to it (because that shows it has an identity!).
> Nope. I have a Welfare number, an E-mail, a few Web Pages ... 
> all of those identify some
> representation of me in a certain context. Every context has 
> its own logic. You can grab
> an arbitrary number of those resources together in a node, 
> that does not mean you captued
> my identity.
> > > Moreover, the blank node option allows you to gather as 
> many resources as you want, be
> > > they in a formal scheme or not.
> > >
> > > _:node1  	a:SKOS_representation		eg:People
> > > _:node1	     a:RDFS_representation		foaf:Person
> > > _:node1	     a:Wikipedia_definition	

> Now, this is an argument for using a separate node (blank or not). This
> is of course not doable using skos:it.

This actually is very Topic Map-ish. Looks like a TM N-ary association, basically.

> However, is this needed? are there really N different paradigms?
> Is not the Wiki node compatible with SKOS concepts?
> So we would have only two domains.

Yes, I think a SKOS ConceptScheme, a RDFS or OWL ontology, and Wikipedia are really
different representation spaces, or paradigms if you like. You can't merge them.

> And I am still not entirely convinced that foaf:Person and ex:People are
> not identical (sameResource).

You mean really ...

eg:People 	owl:sameAs	foaf:Person

... in that case take your responsibility for all resulting semantic damage. I won't sort
out the mess :)

> What are the arguments that they are different?

Show me a valid argument that they could be the same. For one they have not the same type.
And certainly you can infer properties of the first that will seem very weird when applied
to the other.




Bernard Vatant
Senior Consultant
Knowledge Engineering

"Making Sense of Content" :  http://www.mondeca.com
"Everything is a Subject" :  http://universimmedia.blogspot.com

Received on Wednesday, 15 June 2005 14:46:48 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:45:20 UTC