[oslc-core] Delegated dialog oslc:results ambiguity

[John Arwe]

If 3.0 says that the content *is* RDF, that's fine.  Then JSON-LD is just 
one serialization (the one required for broad interop), but there's 
clarity that the metamodel is RDF's along with all that brings via 
Core/LDP.  If it happens that JSON-LD/compact allows **an RDF client** to 
run it through JSON tools, that doesn't change the global constraints on 
client consumption of RDF content.

If 3.0 says that clients can still process it **as** JSON (sic, not 
JSON-LD), then there's more wiggle room (the existing constraints can  be 
read to not obviously apply) and I'd lean towards making the explicit MUST 
at least.


Best Regards, John

Voice US 845-435-9470  BluePages
Tivoli OSLC Lead - Show me the Scenario




From:   Samuel Padgett/Durham/IBM
To:     John Arwe/Poughkeepsie/IBM at IBMUS, 
Cc:     oslc-core at open-services.net, "Oslc-Core" 
<oslc-core-bounces at open-services.net>
Date:   11/14/2013 09:18 AM
Subject:        Re: [oslc-core] Delegated dialog oslc:results ambiguity


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/20131118/3329015e/attachment-0003.html>