I only use RDF triples as a storage format for edges. I don't normally take advantage of triple stores (e.g. apache Jena), sparql query engines, etc.
It's just a simple format and it's easy to build different types of query/analysis capabilities around.
The only thing that's a little awkward is applying types to items in an rdf triple (in a way that's computationally cheap). Typing is a general problem, though.
I strongly agree with this - RDF is fine and there are some great concepts in the SemWeb world (IRIs for example), but OWL and SPARQL are confusing and can be off-putting, especially when it is all rolled together. The latest iteration of our triple store actually moves radically towards linked-document or a 'document graph' to make it more understandable while keeping RDF at the base.
To find calls between person A and person B, then you can add a variable binding on the exact node you're interested in (eg call_session) to extract/aggregate attributes.
You could do it, but a triple wouldn't be the best choice of data structure. I would just add a new numerical column called "weight" to each relation in your RDF store:
"Harry Potter and the Philosopher's Stone","author","Jane Doe",0.005
"Harry Potter and the Philosopher's Stone","author","J.K. Rowling",1.0
...
You could easily export RDF triples from this if you needed to using rules like "The author for each book is determined by the '<book>-author-<name>' relation of highest weight".
Edit: Sorry I didn't answer your question about "10 minute phone call at time t between person A and person B".
The best way I can think of to model this with triples is:
It's just a simple format and it's easy to build different types of query/analysis capabilities around.
The only thing that's a little awkward is applying types to items in an rdf triple (in a way that's computationally cheap). Typing is a general problem, though.