W3C home > Mailing lists > Public > public-powderwg@w3.org > June 2007

Re: [SKOS] ACTION on relating skos:Concept to a foaf:Person

From: <aisaac@few.vu.nl>
Date: Fri, 22 Jun 2007 08:17:14 +0200
Message-ID: <1182493034.467b696abcbcb@www.few.vu.nl>
To: Kjetil Kjernsmo <kjetilk@opera.com>
Cc: public-swd-wg@w3.org, Public POWDER <public-powderwg@w3.org>

>> This problem is not trivial to understand: what does this
>> http://www.fosi.org/rdf/descriptions#just-nude stand for? Why would
>> it be different from the description of a SKOS concept using for
>> instance some SKOS notes and SKOS semantic relationships? In this
>> case you could just use a SKOS mapping link (well we have to define
>> them, so just tell your requirement ;) saying that your
>> http://my.opera.com/username/tag/nude is semantically equivalent to
>> http://www.fosi.org/rdf/descriptions#just-nude , couldn't you?
> Yes, I could, what I want to say in this case is that
http://my.opera.com/username/tag/nude is semantically equivalent to
> http://www.fosi.org/rdf/descriptions#just-nude (or rather
<http://repository.icra.org/generic#nudity> which is a stable URI for exactly
this resource, however, its rdf:type is TBD.)
> However, the problem is that the UI our users see for the case of saying that
the http://my.opera.com/username/tag/nude is semantically equivalent to
http://repository.icra.org/generic#nudity is not different from saying that
http://my.opera.com/username/tag/kjetil is somehow related to the resource me...
> So, that's the problem, I need something generic enough to say both these

Thanks, your mail clarifies a lot. In fact your two problems (concept-concept
linking and concept-object linking) are linked because it is so in your interface...

Unfortunately I guess one could spend weeks finding this "means" common
superproperty of the "semantically equivalent concept" (the tag-concept link)
and "reference" (the tag-object link) properties you need for your app, if it

In the meantime, I would propose as a cheap solution that the UI deals with the
problem it has raised. If you were accepting more than one slot for this 'means'
relationship, you wouldn't need a single modelling primitive for the two links
that can be found behind...
Consider you have a slot 'means' where a user enters what he means by her tag (a
concept more precisely described or an object/person). Your app could just
detect the rdf:type of this resource; if it is a skos:Concept, then you create a
'semantically equivalent concept' triple between the tag and the concept. If it
is something else, then we can assume it belongs to the 'real world' realm and
the app would create a 'reference' triple between the tag and the object.
If you want you can restrict this 'something else' to a controlled list of
classes, to prevent unexpected cases. In the latter case, if a user wants to
fill your "means" slot with some instance which is not a skos:Concept nor an
instance of your controlled classes, then I would say she is a damn expert and
deserves the right to choose herself the type of the property ;-)

I agree that this proposal is not optimal: you could argue that if there is an
interface need, there is some evidence of a modelling need. But given the
complexity of the problem and my limited knowledge, I cannot offer you something
else in one week. Of course I am very curious to know if someone on the list has
a better option at the modelling level.


Received on Friday, 22 June 2007 06:18:01 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:06:03 UTC