Jeni's Musings

Thanks Richard,

I get the argument for naming graphs based on where they’re retrieved from as a means of establishing provenance. I thought about responding that the source of a particular graph could be recorded against the graph, but of course if you have multiple sources of the same graph, you can’t distinguish between the triples from different sources.

So instead, I take this as an argument for limiting the method of naming graphs to fragments within the page (ie use something like the id attribute or something with the same lexical space).

(By the way, do you honour the <base> element in RDFa (or xml:base in RDF/XML) when you name a graph based on a retrieved document, or use the retrieval URI? I ask because obviously the <base> or xml:base could point to any URI, raising the same issues, but I would have thought that they’d be honoured because they usually are when working out the base URI of a document.)

The Property Reification Vocabulary is interesting. To continue the example I used in the post, I think it would mean using:

:membership a partnerships:Membership ;
  partnerships:hasMember :JikoaChiweteMonu ;
  partnerships:hasPartnership :JohnAndCoSolicitors ;
  dc:temporal [
    g:endDate "2009-01-30"^^xsd:date 
  ] .

:occupation a organisation:Occupation ;
  organisation:isOccupiedBy :JohnAndCoSolicitors ;
  organisation:hasAddress [
    a vcard:Address ;
    vcard:street-address "135-143 Stockwell Road" ;
    vcard:locality "London" ;
    vcard:postal-code "SW9 9TN"
  ] ;
  dc:temporal [
    g:includesDate "2009-02-10"^^xsd:date
  ] .

and then in the ontology having something like:

partnerships:isMemberOf a rei:ReifiedProperty ;
  rei:reificationClass partnerships:Membership ;
  rei:subjectProperty partnerships:hasMember ;
  rei:objectProperty partnerships:hasPartnership .

organisation:hasOffice a rei:ReifiedProperty ;
  rei:reificationClass organisation:Occupation ;
  rei:subjectProperty organisation:isOccupiedBy ;
  rei:objectProperty organisation:hasAddress .

(I’ve changed the reified property name from organisation:hasAddress to organisation:hasOffice to prevent something horribly recursive from happening.)

The only thing I wonder is whether it would ever actually be implemented. Statement reification doesn’t seem to be supported in triple stores despite being baked right into the specs. Property reification requires the same kind of dual-view of any triple that uses a reified property as is required in statement reification, and, as far as I can tell, an ontology like that above requires OWL Full (because the reified property is being treated as a class as well as a property).

Conversely (in favour of named graphs), triple stores are already actually quad stores, and SPARQL can be used over them without the requirement for any level of reasoning capability.

I’m not particularly advocating using named graphs, by the way, just trying to work out the best practical way of addressing this real-world (and pressing!) problem.