Re: RDF API thoughts

One additional issue/experience with the 'generalized' triples, ie, triples that go beyond what is permitted in RDF. We discussed the literal-as-subject (LaS) one; there is another one, namely the bnode-as-property (BaP) (which is not currently allowed).

These restrictions _may_ be a problem for (special) applications on top of the API, namely rule based reasoners. If you take, conceptually, a forward-chaining reasoner to implement, eg, OWL 2 RL, the obvious way of doing that on top of a triple store is to generate new and new triples based on the rules adding them to the triple store until no new triples are generated. Though not an optimal approach, this simple thing works well with smaller graphs and smaller rule sets (and I do not expect to handle huge triple stores in a Web Application). I believe our Web Applications may need such simple rule based reasoners (in my personal opinion more than, say, OWL reasoners)

However, an artifact of, eg, the OWL RL formalism is, for example, that BaP triples are also generated along the lines. And these triples are necessary to follow some rules to their logical end (even if they are not serialized at the end of the processing as 'pure' RDF). Similar issues arise if one wants to implement datatype reasoning with rules; in this case the rules are such that they do rely on a literal as a subject. It is for these reasons that both OWL and RIF actually refer to 'generalized' triples. Bottom line: such triples _may_ be useful for the development of more complex applications or libraries, even if, say, the resulting serialization would filter out those generalized triples as 'illegal' in terms of RDF.

I have hit this problem myself when implementing another service of mine, namely OWLRL[1]. While RDFLib, as far as I remember now, does accept BaP triples it certainly does not accept LaS ones. What I had to do is to remove all Literal resources from the graph temporarily replacing them with a new BNode, run the rules through this modified graph, and then massage the resulting graph by removing the triples with a subject associated with a Literal and replace the associated Bnodes with the corresponding Literal in the subject position. It would have made my life easier to have a triple store with full generality...

Ivan

[1] http://www.ivan-herman.net/Misc/2008/owlrl/

On Jan 11, 2011, at 22:55 , Toby Inkster wrote:

> On Tue, 11 Jan 2011 15:10:00 +0000
> Nathan <nathan@webr3.org> wrote:
> 
>> they may very well be included in the next revision of RDF,
>> as per the potential RDF WG draft charter
> 
> I don't think it's going to be fruitful to try to cater for
> RDF 1.1 or 2.0 or whatever it ends up being called.
> 
> Even if we recharter the RDFa WG with an extension, the new
> RDF version recs will not be delivered until a good 18 months
> after this group's charter ends - and that's if they're
> delivered on time, which seems pretty unlikely to me.
> 
> Let's deliver an RDF API for RDF as it's defined today and not
> try to guess what the RDF WG will do in the future. If it turns
> out that the RDF API we develop is inadequate to cover the next
> version of RDF, then the RDF WG worry about that.
> 
>> Profiles are required by RDFa processors (default profile etc), may
>> well be adopted by the RDF WG for turtle and RDF, hence the
>> specification - generally the interfaces will need to be supported by
>> one of the two APIs regardless, can't just be dropped afaict.
> 
> I'm sorry, but this is a non-sequitur.
> 
> My RDFa parser is implemented on top of an existing RDF API
> (not *the* RDF API, *an* RDF API - RDF::Trine's API); Ivan's
> is implemented on top of an existing RDF API (rdflib's API).
> Neither of these APIs have built-in profile support, but we
> both managed to implement RDFa 1.1.
> 
> So implementing an RDFa parser does not require profile support
> in the underlying RDF API.
> 
> -- 
> Toby A Inkster
> <mailto:mail@tobyinkster.co.uk>
> <http://tobyinkster.co.uk>
> 
> 


----
Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF: http://www.ivan-herman.net/foaf.rdf