Re: [oslc-core] JSON-LD of compact resources

[Martin P Pain <martinpain@uk.ibm.com>]

In the interests of the "doing it
right first time" approach (if I understood you John), and your suggestion
of using concrete examples, I believe this example shows one way of using
a plain JSON structure for the icon resource (using a nested object) and
a JSON-LD context that maps this to the "pretty trivial" RDF
approach that John suggested.

This JSON structure:
{
  "icon": {
    "url": "http://example.com/icon.png",
    "title": "Icon"
  }
}

with this context:
{
  "@context": {
    "icon": "http://open-services.net/ns/core#icon",
    "url": "@id",
    "title": "http://purl.org/dc/terms/title"
  }
}

results in these triples:
_:b0 <http://open-services.net/ns/core#icon>
<http://example.com/icon.png>
.
<http://example.com/icon.png>
<http://purl.org/dc/terms/title>
"Icon" .

However, this doesn't attempt to allow
a JSON structure that is backwards-compatible with the XML/conceptual approach
in 2.0. I don't think there's a way to do that (that is, create those triples
without a nested JSON object, without any JSON-LD keywords in the JSON
structure), at least not from my knowledge of JSON-LD.

Martin Pain
Software Developer - Green Hat
Rational Test Virtualization Server, Rational Test Control Panel
OASIS Open Services for Lifecycle Collaboration - Automation technical
committee chair

E-mail: martinpain@uk.ibm.com Find me on:  and within IBM on:

IBM United Kingdom Limited
Registered in England and Wales with number 741598
Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU

<oslc-core@lists.oasis-open.org> wrote on 05/05/2014
19:51:05:

> From: John Arwe <johnarwe@us.ibm.com>
> To: oslc-core@lists.oasis-open.org, 
> Date: 05/05/2014 19:51
> Subject: Re: [oslc-core] JSON-LD of compact resources
> Sent by: <oslc-core@lists.oasis-open.org>
> 
> As long as we're in RDF space (as the subject's use of "JSON-LD"
> could be read to imply), one should not require any new properties.
> Things get murkier if we also have to stay in "generic JSON (no
...-
> LD) space" (as the subject's use of "compact resources"
could be 
> read to imply when considering other threads).
> 
> As long as the content is RDF, it's pretty trivial to make 
> assertions about properties of the image file: 
> <>, oslc:icon, <...defect.jpg>  
=> unchanged 
> <>, oslc:iconTitle, "Defect"
=> <...defect.jpg>, dcterms:title, "Defect" 
> and so on.  An implementation that cared
to serve a single 
> representation to both Core 2.0 and Core 3.0 clients could simply
> union the triples. 
> If we have or develop a "pure JSON"
convention for doing the same 
> thing in 3.0, done. 
> If we need to "get it right the first time"
(at model definition 
> time) to have a single JSON/JSON-LD-compatible representation of the
> same thing (because we lack that "pure JSON" convention),
then we 
> likely have a larger problem at that JSON/JSON-LD level and that 
> might lead us to re-examine other decisions.  This spec provides
a 
> convenient venue for flushing those practicalities out I hope. 
> A separate issue perhaps is whether the restrictions
on oslc:icon as
> a vocabulary term are desirable.  In the 2.0 generation of specs,
> because we had a fuzzy boundary between what's part of the base 
> vocabulary and what's part of the resource shape (which is a 
> separate layer of requirement specific to a certain usage context),
> I've seen cases where things seemed to bleed across the boundary in
> ways that I wasn't crazy about.  The mention of 'provider' in
the 
> definition demonstrates that - if we believe that's a restriction
on
> the terms usage, does its use in Publisher actually fall within it?
> The favicon format and 16x16 statements would be completely 
> appropriate for a resource shape, I'm less sanguine about them in
a 
> vocabulary document.  OTOH they're a should not a must, so any
> client depending upon them is, in theory, already broken in the 
> general case.  In more recent vocabulary documents I've generally
> argued for generality at that level in the formal definition, and
> inclusion of a *clearly marked* example usage that is more specific,
> in the vocab term comment. 
> If the Core TC decided to accept them as limiting
(presumably in the
> name of better compatibility with 2.0's ecosystem) and use something
> different in 3.0, then there are other vocabularies to choose from,
> and if none are to our liking the fallback to defining-new is always
> available.  A quick search of LOV shows a general (unrestricted
to 
> favicon format) http://open.vocab.org/terms/icon
(at http://
> open.vocab.org/terms.ttl) and FOAF (with some inconvenient RDFS 
> assertions) terms like http://xmlns.com/foaf/spec/#term_img
, 
> http://xmlns.com/foaf/spec/#term_thumbnail
, and http://xmlns.com/
> foaf/spec/#term_Image float to the top. 
> When I was doing this sort of thing for Actions
(how to handle the 
> blizzard of options for serializing http requests, with and without
> parameters of various sorts), I made progress by just stamping out
> concrete examples and showing them around.  Seems like that pattern
> would be useful here.  Even if they never make it into a spec
(most 
> of mine did not survive even my own eyeballs' opinions, let alone
> others'), they do tend to communicate your intent better than prose.
> If you prune one yourself but still save it, and then someone later
> says "what about X", it's already there to show why it was
pruned, 
> or it's new and should be examined. 
> Best Regards, John
> 
> Voice US 845-435-9470  BluePages
> Tivoli OSLC Lead - Show me the Scenario
> 
> 
> [image removed] Samuel Padgett---05/01/2014 01:52:24 PM---Hey, John.
> Steve and I had discussed this, and I agree. One problem is that we
> might need a need pro
> 
> From: Samuel Padgett/Durham/IBM
> To: John Arwe/Poughkeepsie/IBM@IBMUS, 
> Cc: oslc-core@lists.oasis-open.org
> Date: 05/01/2014 01:52 PM
> Subject: Re: [oslc-core] JSON-LD of compact resources
> 
> 
> Hey, John. Steve and I had discussed this, and I agree. One problem
> is that we might need a need property or we'd be changing the 
> meaning of an existing property. It's also used by the Publisher in
> the service description document. Would we want to change that too?
> 
> http://open-services.net/ns/core#
> 
>     <rdf:Property rdf:about="http://open-services.net/ns/core#icon">
>         <rdfs:isDefinedBy rdf:resource="http://open-services.net/ns/core#"
/>
>         <rdfs:label>icon</rdfs:label>
>         <rdfs:comment>URL to an icon file
that represents the 
> provider. This icon should be a favicon format and 16x16 pixels in
> size.</rdfs:comment>
>         <rdfs:seeAlso
> rdf:resource="http://open-services.net/bin/view/Main/
> OslcCoreSpecification#Resource_Publisher" />
>     </rdf:Property>
> 
> -- 
> Samuel Padgett | IBM Rational | spadgett@us.ibm.com
> Eclipse Lyo: Enabling tool integration with OSLC
> 
> 
> 
> [image removed] John Arwe---05/01/2014 10:54:20 AM---in  http://
> tools.oasis-open.org/version-control/browse/wsvn/oslc-core/specs/
> resource-preview.html

> 
> [image removed] 
> From:
> 
> [image removed] 
> John Arwe/Poughkeepsie/IBM@IBMUS
> 
> [image removed] 
> To:
> 
> [image removed] 
> oslc-core@lists.oasis-open.org
> 
> [image removed] 
> Date:
> 
> [image removed] 
> 05/01/2014 10:54 AM
> 
> [image removed] 
> Subject:
> 
> [image removed] 
> Re: [oslc-core] JSON-LD of compact resources
> 
> [image removed] 
> Sent by:
> 
> [image removed] 
> <oslc-core@lists.oasis-open.org>
> 
> 
> 
> 
> in http://tools.oasis-open.org/version-control/browse/wsvn/oslc-
> core/specs/resource-preview.html section 4 Compact, I think icon 
> should also be a separate resource ala the previews. 
> The icon has its own properties, like title, and its own URI (the
> icon property shows this), so this seems pretty obvious.  
> Implementations that want to populate the OSLC
2.0 properties as 
> well would still be free to do so, in order to interop with 2.0 clients.
 
> Best Regards, John
> 
> Voice US 845-435-9470  BluePages 
> Tivoli OSLC Lead - Show me the Scenario  
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU