Steve, I don't see how named graphs would work for us. We are making the assumption that resources have RDF representations. RDF is just triples. Named graphs are quads. Named graphs are not part of RDF (yet?). They are a storage concept. We'd need a new media type to describe them, e.g. use TriG with application/x-trig.
Sending named graphs would also mess up our indexing story since we create a named graph for each resource. But if a resource contains named graphs, how would be store them? Maybe we'd need a quintuple store :-) Regards, ___________________________________________________________________________ Arthur Ryman DE, Chief Architect, Reporting & Portfolio Strategy and Management IBM Software, Rational Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) From: Steve K Speicher <[email protected]> To: [email protected] Date: 06/12/2012 03:05 PM Subject: [oslc-core] Rethinking link labels without reified statements Sent by: [email protected] 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 _______________________________________________ Oslc-Core mailing list [email protected] http://open-services.net/mailman/listinfo/oslc-core_open-services.net
