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

[John Arwe <johnarwe@us.ibm.com>]

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


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

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

From:	John Arwe/Poughkeepsie/IBM@IBMUS
To:	oslc-core@lists.oasis-open.org
Date:	05/01/2014 10:54 AM
Subject:	Re: [oslc-core] JSON-LD of compact resources
Sent by:	<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