Item end-point returns incorrect result when resource description contains bNodes

[GoogleCodeExporter]

In the cube vocabulary, a DSD (DataSetDescription) is a resource with a set of 
qb:component properties, each value of which is a bNode. Eg.:

<http://finance.data.gov.uk/dsd/coins>
    a qb:DataStructureDefinition;
    qb:component [qb:componentProperty sdmx-dimension:refPeriod; qb:order 0];
    qb:component [qb:componentProperty coins-dimension:dataType; qb:order 1];
    qb:component [qb:componentProperty coins-dimension:dataSubtype; qb:order 2];
    ...

An item endpoint for this resource fails to deal correctly with the bNodes.

My API spec contains:

spec:coins-dsd
    a lda:ItemEndpoint;
    lda:uriTemplate "/dsd/coins";
    lda:itemTemplate "http://finance.data.gov.uk/dsd/coins";
    .

When I do a get on http://localhost/dsd/coins.json I get:

{
    "format": "linked-data-api",
    "version": "0.2",
    "result": {
        "_about": "http:\/\/localhost\/dsd\/coins.json",
        "format": [{ ... elided for brevity ...}]
       "primaryTopic": {
            "_about": "http:\/\/finance.data.gov.uk\/dsd\/coins",
            "component": [{},
            {},
            {},
            {},
            {},
            {},
            {}, ... etc ... ,
            {}],
            "type": "http:\/\/purl.org\/linked-data\/cube#DataStructureDefinition",
            "isPrimaryTopicOf": "http:\/\/localhost\/dsd\/coins.json"
        }
    }
}

Original issue reported on code.google.com by i.j.dick...@gmail.com on 3 Dec 2010 at 11:00

[GoogleCodeExporter]

Hi,

Is this only in the simple json/xml formats, or also in the turtle output ?

Can you share your config ?

Original comment by K.J.W.Al...@gmail.com on 4 Dec 2010 at 12:09

[GoogleCodeExporter]

Original comment by K.J.W.Al...@gmail.com on 4 Dec 2010 at 12:09

• Changed state: Accepted

[GoogleCodeExporter]

Hi Keith,
In attempting to answer your question, I discovered a different problem with 
the Turtle output. I'll make that a separate issue. But, afaict, the turtle is 
reporting bNodes accurately.

Config attached.

Original comment by i.j.dick...@gmail.com on 4 Dec 2010 at 1:38

Attachments:

• coins-lda.ttl

[GoogleCodeExporter]

Hi Ian,

Not sure what to do here. In the turtle, it just gives the bnode ID, because 
the CONSTRUCT query is basically just doing  construct s p o
I could add construct {  <s> ?p ?o  .  ?o  ?y  ?z  }   where {  <s> ?p ?o .  
optional {  filter(isBlank(?o)) ?o ?y ?z  } }
(I can tell this is going to get hairy with viewers and _properties .... )

or you could extend the property path of the viewer to include  component.*

Original comment by K.J.W.Al...@gmail.com on 19 Dec 2010 at 8:46

[GoogleCodeExporter]

Hi Keith,
It's a given that RDF in-the-wild will contain bNodes, so any general-purpose 
tool will have to be able to cope with them, or at least have a defined policy. 
The question, I suppose, is what the spec says on this question. If, as I 
suspect, the spec is currently silent, then I think that the resolution is to 
bump this issue "upstairs" to linked-data-api@googlecode and get some 
bNode-based test cases added to the conformation test suite.

Once it's clear what the right answer is, then users of the API will know what 
to expect from conformant implementations. As an API user, I personally would 
expect the right answer to be some form of CBD. Just adding a second tier of 
properties only moves the problem along, it doesn't actually solve it.

Original comment by i.j.dick...@gmail.com on 19 Dec 2010 at 10:23

[GoogleCodeExporter]

Hi Ian,

I just doubled checked the spec to see if I should have added ids to the nodes, 
but spec says only if they are the object of more than one statement. Not that 
ids help at all, just maybe look a little less odd than {}

Yeah, there isn't really a way to solve it completely - wherever you stop, 
there could always be a dangling undescribed blank node. Blank nodes are 
rubbish! gonnae put some URIs in there instead ? ;)

Original comment by K.J.W.Al...@gmail.com on 19 Dec 2010 at 5:10