W3C home > Mailing lists > Public > semantic-web@w3.org > May 2010

Re: RDF Reification

From: Melvin Carvalho <melvincarvalho@gmail.com>
Date: Mon, 10 May 2010 22:13:41 +0200
Message-ID: <AANLkTil2oinXYcwFQZMPD-Jnw_gS7jXTOXf0XEI9LHyP@mail.gmail.com>
To: Reto Bachmann-Gmuer <reto.bachmann@trialox.org>
Cc: Nuno Luz <nuno.maluz@gmail.com>, semantic-web@w3.org
2010/5/10 Reto Bachmann-Gmuer <reto.bachmann@trialox.org>

> Hi Nuno
> I assume your question is about describing trust relationships with triples
> rather than implementing a triple store.
> Reification is not suitable for quoting but I see no reason not to use it
> to specify qualities of an asserted friendship relationship. Having a class
> :Friendship would be the more explicit approach, your trust property would
> have domain :Friendship rather than rdf:Statement making the ontology easier
> to understand. However having a friendship relationship expressed with a
> single statement, not only makes some sparql queries simpler but also
> potentially (if the individuals have lots of friend) much more performant,
> if the triple store has optimization for reification also accessing the
> additional properties of the friendship is faster than with the
> Friendship-class approach.

Is this any help?


> Reto
> On Mon, May 10, 2010 at 3:32 AM, Nuno Luz <nuno.maluz@gmail.com> wrote:
>> Hi,
>> I am currently implementing a triple store and RDF reification seems to be
>> just the thing i need right now. The problem is that i read that it's bad
>> practice. I haven't found much information about why it's bad practice, so i
>> was wondering if you could enlighten me a bit on the matter :-)
>> Since i need to have trust values for friendship relations i thought of
>> creating a class that represents the statement, like Friendship, but it just
>> seems the same as reification. Besides, SPARQL queries become really ugly.
>> I am still new in the area so i appreciate any help and hints you can
>> give.
>> Regards,
>> Nuno Luz
Received on Monday, 10 May 2010 20:14:14 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 07:42:19 UTC