[oslc-core] Rethinking link labels without reified statements

[Steve K Speicher]

In looking at what is on the roadmap for the W3C RDF Working Group in 
considering deprecating reified statements [1] I took the action to 
explore the way we currently do things like "link labels" [2] using the 
recommended alternative of named graphs[3].  I'm sending this note out to 
see if anyone else has any interesting insight on how this can be 
accomplished.  I plan to send a note to the RDF WG as well.

To be honest, I struggle to find a clean way to do this with named graphs. 
 Added to some of the challenges is how to define a simple PATCH format 
that can be used to patch these reified statements.

Take for example this simple change request:
@prefix ex: <http://example.com/bugtracker> .
@prefix oslc: <http://open-services.net/ns/core#> .
@prefix oslc_cm: <http://open-services.net/ns/cm#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix dcterms: <http://purl.org/dc/terms/> .

<http://example.com/bugs/2314>
   a oslc_cm:ChangeRequest ;
   oslc_cm:relatedChangeRequest <http://myserver/mycmapp/bugs/1235> ,
      <http://remoteserver/mycmapp/defects/abc123> .

_:b1 
        a rdf:Statement;
        rdf:subject <http://example.com/bugs/2314>;
        rdf:predicate oslc_cm:relatedChangeRequest;
        rdf:object <http://myserver/mycmapp/bugs/1235>;
        dcterms:title "My special link title".

So if I want to NOT use reified statements I'd have to model this 
relationship a bit differently.  One idea would be to use a named graph 
for the link statements. 
The questions that need to be answered with this approach are:

1. Simply how to form that graph and/or how to relate the graph with the 
right "relationship" triple?

In thinking through this, it feels like I'm inventing reification and 
doesn't seem like the desired outcome.  Let's try to force it for a moment 
and say we can "compute" the graph name based on the relationship triple. 
So for my example above, we have something horrible like (not encoding):
Graph name = <http://example.com/bugs/2314|http://open-services.net/ns/cm#
relatedChangeRequest|http://myserver/mycmapp/bugs/1235>

2. What is the subject of the triples within this new named graph?
The subject and object of the relationship triple don't appear to be the 
right choice.  Though, since we have this special private graph, perhaps 
we can just use the object to pick one since we shouldn't have any 
conflicts.

So the example becomes:

@prefix ex: <http://example.com/bugtracker> .
@prefix oslc: <http://open-services.net/ns/core#> .
@prefix oslc_cm: <http://open-services.net/ns/cm#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix dcterms: <http://purl.org/dc/terms/> .

<http://example.com/bugs/2314>
   a oslc_cm:ChangeRequest ;
   oslc_cm:relatedChangeRequest <http://myserver/mycmapp/bugs/1235> ,
      <http://remoteserver/mycmapp/defects/abc123> .

:<http://example.com/bugs/2314|http://open-services.net/ns/cm#
relatedChangeRequest|http://myserver/mycmapp/bugs/1235> = {
   <http://myserver/mycmapp/bugs/1235> dcterms:title "My special link 
title".     # This is a lie, not right subject
}

This seems like a complete non-obvious abuse of this.   Hopefully someone 
sees a more clear way to leverage named graphs and why I'm taking this 
discussion to the mailing list.  If not, we can provide this feedback to 
RDF WG and see if they have a proper solution or will justify keeping 
reification or some subset.

[1] - http://www.w3.org/2011/rdf-wg/track/issues/25 , 
http://open-services.net/pipermail/oslc-core_open-services.net/2012-February/001229.html
[2] - 
http://open-services.net/bin/view/Main/OslcCoreSpecAppendixLinks#2_Anchor
[3] - 
http://www.w3.org/TR/2012/WD-rdf11-concepts-20120605/#section-dataset

Thanks,
Steve Speicher | IBM Rational Software | (919) 254-0645