There aren't documents with the triples in them. They're being asserted individually.
I agree that RDF's reification mechanism is awkward, but it is part of the spec. It would be nice to have some aspect of RDFa that address that part of RDF other than the brute-force enumeration of each of the reification triples.
If named graphs were part of RDF, I'd be happy to use them instead. But we're trying to stay within RDF and RDFa.
Brian
On Jul 9, 2009, Dan Brickley <dan...@danbri.org> wrote:
On 9/7/09 18:28, publicay...@verizon.net wrote:
> I need to associate a triple with its reification id, then make triples
> on that id (for things like creator and created). The only way I can
> figure out to do this in RDFa is to make the triple in the usual way
> (with about/rel/resource), but also assert the reification triples on
> the subject, predicate, and object. I was planning on putting the
> reification triples in the head.
RDF's subject/predicate/object reification mechanism is pretty awkward
to use.
If you can find a way to associate creator/date/etc another way, I
recommend doing so. How about providing them as metadata about the
document that carries the RDF?
> It seems unfortunate to add 3 triples and their elements in the head for
> each triple in the body just to represent the mapping from reification
> id to a triple's subject, predicate, and object. The only other option I
> can come up with is to extend RDFa with a new attribute to give the
> reification id and have it expand into the 3 triples, something like
>
> <meta about="s" rel="p" resource="o" reification="id" />
>
> Since there isn't any special handling for reification in RDFa, I was
> wondering if it was discussed and rejected, and if so, what were the
> problems. Also, is there any inclination to expand RDFa sometime in the
> future for convenient handling of reification?
I wouldn't encourage this. Instead, I'd rather see work on documenting
deployment patterns that use named graphs, and integration with SPARQL's
named graph mechanism.
cheers,
Dan
