Semantic Overflow

Question

3

1

Please forgive me if I am not using the correct terminology, but i would like some feedback on whether I am solving a problem in the best way possible. I am building a system where users create ideas / concepts, a kind of taxonomy or thesauri from which all users can write stories about. For example a user may create a concept called Football, and then different users can then create their own story about football. Another feature is that when creating a story, users can create links from within the story body text to other concepts in held in the system.

I am using skos:concept for the concepts and am using my own class for the stories.

My main issue lies with the semantics behind the linking of stories as i want users to be able to provide a description for the relationship - for eaxample Hendrix (plays) Guitar and also an inverse for each type of relationship i.e. guitar (played by) Hendrix. The important bit here is that the user creates the descsription for the relationship and there is no limit on types of relationships - they can be anytyhing.

Skos relationships dont offer this so I am thinking that the only way to provide this is to create a unique property each time a relationship between two stories is made, giving the property a unique id and adding it to an rdf+xml file and then also recording it in my triple store. This seems like a lot of unnecessary work / duplication for such a small addition to one of the skos relationships.

Can anyone offer any advice on whether this is indeed the best way to proceed with this or whether there is better solution.

flag	asked Mar 16 at 14:52 Drew 31●1

Simon Reinhardt · Answer 1 · 2010-03-16 20:53:10Z UTC

I'm not sure about best practices but I can offer some alternatives / additions to your approach (which already seems quite sensible).

First of all, the Semantic Web's purpose is mainly data integration and thus you should do everything to support that. It would therefore be good if you can either reduce the amount of unique properties you create or offer more generic ones together with them. If you do create new properties from the user's input then they should be declared as sub-properties of generic ones and those generic ones would preferably be popular ones from other vocabularies so that using inferencing people can still discover triples with "expected" properties. If you do that inferencing in your triple store you take a bit of the burden off the shoulders of others and people are more likely to find useful data.

Then you could implement a feature where users will get suggestions for existing relationships while they're typing their descriptions in. That way the properties are less unique because they get re-used.

An alternative would be to not create new properties at all but use generic properties and attach the user's description of the relationship elsewhere. You could do this through named graphs, through RDF reification (not very popular these days) or by usin n-ary relationships. If you do the latter then I'd suggest you take a look at OWL property chains so that simple binary relationships ("shortcuts") can be inferred from the n-ary ones. That way you can make detailed descriptions of the relationships while still offering links using more generic popular properties in your data.

Drew · Answer 2 · 2010-03-17 20:00:00Z UTC

Hi Simon, thanks for the reply. I had a look at n-ary relationships but I cant see how to get them to fit in with with what im looking for - although it may be because I dont fully understand them.

I have taken your advice and am making all my links subproperties of the dublin core 'relation' property.

Thanks again Drew

Simon Reinhardt · Answer 3 · 2010-03-23 21:12:17Z UTC

Just to give you a simple example:

Schema:

ex:Relationship a owl:Class ;
    rdfs:comment "A reified relationship" .

ex:from1ToRelationship a owl:ObjectProperty ;
    rdfs:range ex:Relationship .

ex:fromRelationshipTo2 a owl:ObjectProperty ;
    rdfs:domain ex:Relationship .

dcterms:relation owl:propertyChainAxiom (ex:from1ToRelationship ex:fromRelationshipTo2) .

Data:

:Hendrix a foaf:Person ;
    ex:from1ToRelationship :HendrixGuitarRelationship .
:HendrixGuitarRelationship a ex:Relationship ;
    rdfs:label "plays" ;
    ex:fromRelationshipTo2 :Guitar .

Not sure about the label on the (n-ary) relationship resource though because it seems to imply that it is to be read in a certain direction (as do the properties to and from it). I think I prefer properties all leading away from a reified relationship instead of "through" it.

Best practice for creating dynamic rdf properties

3 Answers