[oslc-core] Delegated dialog oslc:results ambiguity

[Samuel Padgett]

John,

Since we've gone down the JSON-LD road for UI preview, I would expect in
3.0 to make the dialog results also compact JSON-LD. Then there's no
ambiguity since it's now RDF?

We could add a statement explicitly stating providers MAY add additional
content and consumers MUST ignore unknown content as well.

--
Samuel Padgett | IBM Rational | spadgett at us.ibm.com
Eclipse Lyo: Enabling tool integration with OSLC



                                                                                                                                          
  From:       John Arwe/Poughkeepsie/IBM at IBMUS                                                                                            
                                                                                                                                          
  To:         oslc-core at open-services.net                                                                                                 
                                                                                                                                          
  Date:       11/13/2013 11:51 AM                                                                                                         
                                                                                                                                          
  Subject:    [oslc-core] Delegated dialog oslc:results ambiguity                                                                         
                                                                                                                                          
  Sent by:    "Oslc-Core" <oslc-core-bounces at open-services.net>                                                                           
                                                                                                                                          





Someone sent me this.  Seems like it would be a good candidate for the 3.0
issue list.

I think we need to be clear on this since the existing "clients must
ignore" language is IIRC RDF-centric and this is not an RDF context.


I am reading the OSLC Core Spec Version 2.0
http://open-services.net/bin/view/Main/OslcCoreSpecification

One section I am particularly intrested in is the Resource Selection


    Name: results
    URI: http://open-services.net/ns/core#results




There is texts that states

An example Resource Selection response:

{
    "oslc:results" : [{
            "oslc:label": "Bug 123: Server crash",
            "rdf:resource": "http://example.com/bug123" (
http://example.com/bug123%27)
        }, {
            "oslc:label": "Bug 456: Client hangs on startup",
            "rdf:resource": "http://example.com/bug456" (
http://example.com/bug456%27)
        }
    ]
}

So my question is does the actually results have to look like this
example ?

Basically I am getting extra information such as rdf:type which is
generated automatically


Arwe: generically I would expect the global "clients must ignore
unrecognized content" 'clause' would make that ok, but let me read this
context since it's not RDF

Other: yes, just trying to get my head around alot of it - getting problems
with generating the JSON as in the spec, one of them was the rdf:type just
kept appearing, but I beleive we are using OSLC4J version 1.1 - not sure if
version 2.0 would generate as per specification.

Arwe: while it would not "hold up in court", I'm sure the intent is the
same as if this was rdf - ignore what you don't recognize on the client
side.
... this json is not rdf, despite its appearance.  I will queue this up for
clarification in 3.0 though.
...FYI, you should still fix it over time.  The danger you're exposed to
long term is that the extra info Might someday in the future get assigned a
meaning in this context that conflicts with what your intent is.


Best Regards, John

Voice US 845-435-9470  BluePages
Tivoli OSLC Lead - Show me the Scenario
_______________________________________________
Oslc-Core mailing list
Oslc-Core at open-services.net
http://open-services.net/mailman/listinfo/oslc-core_open-services.net





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20131114/eac957a9/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20131114/eac957a9/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ecblank.gif
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20131114/eac957a9/attachment-0001.gif>