Topic
  • 5 replies
  • Latest Post - ‏2014-02-27T19:00:55Z by schneim
GoodGulf
GoodGulf
610 Posts

Pinned topic OSLC CM V2: GETting a record does not return all the cq fields

‏2013-02-13T19:35:20Z |
If I do a fetch on a record url
e.g.

http:
//cqwebtest1/cqweb/oslc/repo/8.0.0/db/fotst/record/16777242-33555249

I am using JSON here because it's easier to read but the same is true for RDF/XML.
Some of the returned values look like this...

dcterms:type
": "Defect
", ... dcterms:contributor
": { 
"rdf:resource": 
"http://cqwebtest1/cqweb/oslc/repo/8.0.0/db/fotst/user/moe" 
}, 
"dcterms:creator": 
{ 
"rdf:resource": 
"http://cqwebtest1/cqweb/oslc/repo/8.0.0/db/fotst/user/larry" 
}, 
"dcterms:description": 
"Blah Blah", 
"dcterms:identifier": 
"33555249", 
"dcterms:title": 
"Yada Yada", 
"oslc:shortTitle": 
"fotst00000817", 
"oslc_cm:status": 
"Submitted",


The problem with the above entries is that the corresponding "CQ" are not there.
In the order listed above...
The cq:record_type, cq:Owner, cq:Submitter, cq:Description, cq:dbid, cq:Headline and cq:State fields do not exist in the returned values.
Nor is there anything indicating those fields have been replaced by their Dublin Core counterparts.

The oslc:shortTitle value does have the cq:id field in the results.

The missing fields are also defined in the record shape.

I can force a GET to retrieve the missing fields if I include the field name(s) in oslc.properties.

e.g. &oslc.properties=cq:State

Not sure if this is a bug but I would think if you are fetching all the fields on a CQ record, you might want actually get all of them.
  • SystemAdmin
    SystemAdmin
    24948 Posts

    Re: OSLC CM V2: GETting a record does not return all the cq fields

    ‏2013-02-19T18:34:09Z  
    GoodGulf,
    It does appear odd that some of the "CQ" fields aren't being returned, but this behavior is consistent with other CLM providers.

    The fields are provided under their generic form to make it easier for product integration. For example, another product integrating with CQ might know what to do with a dcterms:description from a CM provider, but wouldn't know what to do with a cq:description.

    Off the top of my head, I can think of two reasons why the desired behavior would not be to return both cq:description and dcterms:description. First, and least important, the size of the record increases. Second, you still have to know that dcterms:description==cq:description so that you can set both fields to the same value if you're attempting to update that value.

    This seems like something that could be addressed at the OSLC specification level instead of trying to solve it in a ClearQuest specific way. Perhaps something that could be expressed to the provider that would indicate that mapped values should be returned in their un-mapped form? Or some other expression that would allow you to know that the field you're looking for is really mapped somewhere else.

    Do you have other thoughts on what changes might make it easier for you to do what you're trying to do without making it more difficult for product integrations?
  • GoodGulf
    GoodGulf
    610 Posts

    Re: OSLC CM V2: GETting a record does not return all the cq fields

    ‏2013-02-19T23:02:58Z  
    GoodGulf,
    It does appear odd that some of the "CQ" fields aren't being returned, but this behavior is consistent with other CLM providers.

    The fields are provided under their generic form to make it easier for product integration. For example, another product integrating with CQ might know what to do with a dcterms:description from a CM provider, but wouldn't know what to do with a cq:description.

    Off the top of my head, I can think of two reasons why the desired behavior would not be to return both cq:description and dcterms:description. First, and least important, the size of the record increases. Second, you still have to know that dcterms:description==cq:description so that you can set both fields to the same value if you're attempting to update that value.

    This seems like something that could be addressed at the OSLC specification level instead of trying to solve it in a ClearQuest specific way. Perhaps something that could be expressed to the provider that would indicate that mapped values should be returned in their un-mapped form? Or some other expression that would allow you to know that the field you're looking for is really mapped somewhere else.

    Do you have other thoughts on what changes might make it easier for you to do what you're trying to do without making it more difficult for product integrations?
    RDF mentions something about blank node descriptors.
    Possibly using them on these fields to point to the dcterms field but returning nothing isn't very nice.

    I tore this apart using Perl and JSON because I didn't want to go through the process of doing it in java.

    The underlying approach is still the same from an RDF standpoint though.
    It's an application talking to your server.

    One thing I can say up front though is it appears you are making the application do all the work.
    Relational databases have evolved into extremely efficient engines.
    By making the application do call after call to resolve "Resource" fields, your server must get pretty bogged down as the number of users goes up.
    I will be shocked if that isn't the case.

    I am well aware of subrecord "{}" notation for oslc.select and oslc.properties.
    It appears that you can only put "cq:<fieldname>" namespaced fields in a subrecord call.
    Unless you know the field in the subrecord (thank goodness for CQ's dbid field), you either have to use {*} (not very efficient) and get everything back or you make another call to the server via that resource.
    All that just to get (in my case) the oslc:shortTitle (unique key value) back.

    I'll write up something organized with more detail.
  • schneim
    schneim
    2 Posts

    Re: OSLC CM V2: GETting a record does not return all the cq fields

    ‏2014-02-26T19:04:46Z  
    • GoodGulf
    • ‏2013-02-19T23:02:58Z
    RDF mentions something about blank node descriptors.
    Possibly using them on these fields to point to the dcterms field but returning nothing isn't very nice.

    I tore this apart using Perl and JSON because I didn't want to go through the process of doing it in java.

    The underlying approach is still the same from an RDF standpoint though.
    It's an application talking to your server.

    One thing I can say up front though is it appears you are making the application do all the work.
    Relational databases have evolved into extremely efficient engines.
    By making the application do call after call to resolve "Resource" fields, your server must get pretty bogged down as the number of users goes up.
    I will be shocked if that isn't the case.

    I am well aware of subrecord "{}" notation for oslc.select and oslc.properties.
    It appears that you can only put "cq:<fieldname>" namespaced fields in a subrecord call.
    Unless you know the field in the subrecord (thank goodness for CQ's dbid field), you either have to use {*} (not very efficient) and get everything back or you make another call to the server via that resource.
    All that just to get (in my case) the oslc:shortTitle (unique key value) back.

    I'll write up something organized with more detail.

    Hi,

    I have seen this old thread about my issue. 

    I am using nested property syntax in the oslc.select statement. However, as you wrote, I can only read the cq:<field> of the referenced resource. All oslc: and dcterms: are not returned. 

    Using {*} is not an option for me, because of our huge dataset. 

    How can I use the dbid to read the nested property?

    thanx,

    m.

  • DonaldN
    DonaldN
    287 Posts

    Re: OSLC CM V2: GETting a record does not return all the cq fields

    ‏2014-02-27T04:49:10Z  
    • schneim
    • ‏2014-02-26T19:04:46Z

    Hi,

    I have seen this old thread about my issue. 

    I am using nested property syntax in the oslc.select statement. However, as you wrote, I can only read the cq:<field> of the referenced resource. All oslc: and dcterms: are not returned. 

    Using {*} is not an option for me, because of our huge dataset. 

    How can I use the dbid to read the nested property?

    thanx,

    m.

    The official specification is the really helpful reference that you should use.

    https://jazz.net/wiki/bin/view/Main/CqOslcV2

    Since you are using nested properties, you have to use the "cq" namespace. And because of this, you can use "cq:dbid". Simple. Here is an example.

    http://192.168.112.195/cqweb/oslc/repo/7.0.0/db/SAMPL/simpleQuery/16777224?oslc.where=cq:Project{cq:Name="Classics"}&oslc.select=cq:dbid,cq:Headline,cq:Severity,cq:Project{cq:dbid,cq:Name}&oslc.prefix=cq=<http://www.ibm.com/xmlns/prod/rational/clearquest/1.0/>

  • schneim
    schneim
    2 Posts

    Re: OSLC CM V2: GETting a record does not return all the cq fields

    ‏2014-02-27T19:00:55Z  
    • DonaldN
    • ‏2014-02-27T04:49:10Z

    The official specification is the really helpful reference that you should use.

    https://jazz.net/wiki/bin/view/Main/CqOslcV2

    Since you are using nested properties, you have to use the "cq" namespace. And because of this, you can use "cq:dbid". Simple. Here is an example.

    http://192.168.112.195/cqweb/oslc/repo/7.0.0/db/SAMPL/simpleQuery/16777224?oslc.where=cq:Project{cq:Name="Classics"}&oslc.select=cq:dbid,cq:Headline,cq:Severity,cq:Project{cq:dbid,cq:Name}&oslc.prefix=cq=<http://www.ibm.com/xmlns/prod/rational/clearquest/1.0/>

    I was missing the constraint, that qc namespace can be used only for nested properties.

    I found the corresponding property for dcterms:title in the qc namespace and I can read all data what I need.

    Thanks.