- From: <aisaac@few.vu.nl>
- Date: Fri, 22 Jun 2007 08:17:14 +0200
- To: Kjetil Kjernsmo <kjetilk@opera.com>
- Cc: public-swd-wg@w3.org, Public POWDER <public-powderwg@w3.org>
Hi, > >> 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 things. 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 exists. 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. Cheers, Antoine
Received on Friday, 22 June 2007 06:17:45 UTC