ISSUE-622: Should PROV-AQ bless use of JSON-LD for service description?

This is the text of Stian's proposal. Mainly, it consists of point 42), but makes reference to a loosely related proposal 43)

Ref: http://lists.w3.org/Archives/Public/public-prov-wg/2013Jan/0121.html

...

42) "this specification does not preclude the use of non-RDF formats"
JSON-LD <http://json-ld.org/spec/latest/json-ld-syntax/> is growing in
popularity, should we perhaps propose a JSON-LD context? I think it
would be quite straight forward, and actually managed to do it in
about 15 minutes (including learning the syntax).

If you try the JSON from https://gist.github.com/4565822 on
http://json-ld.org/playground/

( Obviously the "@context" here should be extracted and provided by us. )

You get the example from 4.1.3:

<http://example.com/service#direct>
<http://www.w3.org/1999/02/22-rdf-syntax-ns#type>
<http://www.w3.org/ns/prov#DirectQueryService> .
<http://example.com/service#direct>
<http://www.w3.org/ns/prov#provenanceUriTemplate> "?target={+uri}" .
<http://example.com/service#sparql>
<http://www.w3.org/1999/02/22-rdf-syntax-ns#type>
<http://www.w3.org/ns/sparql-service-description#Service> .
<http://example.com/service#sparql>
<http://www.w3.org/ns/sparql-service-description#endpoint>
<http://example.com/service/sparql/> .
<http://example.com/service#sparql>
<http://www.w3.org/ns/sparql-service-description#resultFormat>
<http://www.w3.org/ns/formats/RDF_XML> .
<http://example.com/service#sparql>
<http://www.w3.org/ns/sparql-service-description#resultFormat>
<http://www.w3.org/ns/formats/SPARQL_Results_CSV> .
<http://example.com/service#sparql>
<http://www.w3.org/ns/sparql-service-description#resultFormat>
<http://www.w3.org/ns/formats/SPARQL_Results_JSON> .
<http://example.com/service#sparql>
<http://www.w3.org/ns/sparql-service-description#resultFormat>
<http://www.w3.org/ns/formats/SPARQL_Results_TSV> .
<http://example.com/service#sparql>
<http://www.w3.org/ns/sparql-service-description#resultFormat>
<http://www.w3.org/ns/formats/SPARQL_Results_XML> .
<http://example.com/service#sparql>
<http://www.w3.org/ns/sparql-service-description#resultFormat>
<http://www.w3.org/ns/formats/Turtle> .
<http://example.com/service#sparql>
<http://www.w3.org/ns/sparql-service-description#supportedLanguage>
<http://www.w3.org/ns/sparql-service-description#SPARQL11Query> .
<http://example.com/service>
<http://www.w3.org/ns/prov#describesService>
<http://example.com/service#direct> .
<http://example.com/service>
<http://www.w3.org/ns/prov#describesService>
<http://example.com/service#sparql> .


Without the embedded @context the actual description can become very
tiny, and perhaps even skip some "@id"s to say:

{
"@context": "http://www.w3.org/ns/prov-aq.jsonld",
"service": [
{ "@type": "direct",
"uritemplate": "?target={+uri}"
} ,
{ "@type": "sparql",
"endpoint": "http://example.com/service/sparql/"
}
]
}

Note that above I've added a prov:describesService relation to relate
the services with the description, and so that I may make nested JSON.
(see #43 below)



43) As shown in the complete example in 4.1.3, the
ProvenanceQueryService is not connected to the DirectQueryService or
sd:Service. Given that services don't have a general name, it would be
difficult for implementers to know if a node in the graph is a service
or just happens to be further/additional data (for instance details
about the publisher of the service). It also means I can't mention at
all a service, without implying that I am somehow providing it as part
of my service description.

I therefore suggest that the ProvenanceQueryService should link to the
services using a term like prov:describesService - see modified
example:


@prefix prov: <http://www.w3c.org/ns/prov#>
@prefix sd: <http://www.w3.org/ns/sparql-service-description#>

<> a prov:ProvenanceQueryService ;
prov:describesService <#direct>, <#sparql> ;
dcterms:publisher <#us> .

<#us> a foaf:Organization ;
foaf:name "and not a service!" .

<#direct> a prov:DirectQueryService ;
prov:provenanceUriTemplate "?target={+uri}"
.
<#sparql> a sd:Service ;
sd:endpoint </sparql/> ;
sd:supportedLanguage sd:SPARQL11Query .


The added advantage of this is that you can do the bnode shorthand
when you don't know quite know or care what to call your service
entries:

<> a prov:ProvenanceQueryService ;
prov:describesService [
[ a prov:DirectQueryService ;
prov:provenanceUriTemplate "?target={+uri}" ],
[ a sd:Service ;
sd:endpoint "?target={+uri}",
sd:supportedLanguage sd:SPARQL11Query
] .

This was considered in the latest round of edits. The text about service decsription formats is quite permissive, with a recommendation to use standardized formats for interoperability. I don't think it's necessary or helpful to mention JSON-LD explicitly.