Supported media types?

[jensscheerlinck]

Willen we in de specificatie iets zeggen over minimaal te ondersteunen media types?

• application/json
• application/ld+json
• text/turtle
• application/xml
• ...

[pietercolpaert]

In het open-data-charter (apart van deze standardisatie) zouden we opnemen dat voor elke nieuwe API een Linked Data content-type moet beschikbaar zijn.

Ik zou in deze standaard echter geen restrictie zetten op serialisaties.

[rubensworks]

Ik stel voor om de media types te sorteren volgens expressiviteit en prioriteit. Bijvoorbeeld:

• Trig (streaming + graphs + prefixing)
• JSON-LD (graphs + prefixing)
• N-Quads (streaming + graphs)
• Turtle (streaming + prefixing)
• N-Triples (streaming)
• RDF/XML (prefixing)

Een matrix volgens features kan ook nuttig zijn.

[pietercolpaert]

Interessant! Zou daar ook HTML aan toevoegen met RDFa of JSON-LD snippets.

Ben wel niet akkoord met streaming als feature. Je moet sowieso de specificatie uitbreiden bij bijvoorbeeld Turtle om turtle over een stream te verzenden en te weten wanneer een chunk kan worden geprocesst. JSON-LD kan je beargumenteren dat die ook streaming werkt.

Voorstel:

Elke API moet 1 of meerdere linked data serialisaties ondersteunen. De prioriteiten-lijst, die ook mag (hangt sterk af van uw API/website) gebruikt worden als prioriteiten-lijst op server-side bij implementatie van content-negotiation is alsvolgt:

q	serialisatie	Linked Data?	Quads
1	application/ld+json	Ja	Ja
1	application/trig	Ja	Ja
1	application/n-quads	Ja	Ja
0.9	text/html	Kan (RDFa of JSON-LD snippets)	kan (JSON-LD snippets)
0.7	application/n-triples	Ja	Nee
0.7	text/turtle	Ja	Nee
0.7	application/rdf+xml	Ja (weinig gebruikt)	Nee
0.6	non-linked data specificatie	Nee	Nee

[CumpsD]

Forgive my ignorance, wat betekend Quads: Ja bij application/ld+json?

Als wij JSON-LD implementeren, krijg je dan automatisch die Quads, of moet je dan nog iets extra doen?

[pietercolpaert]

Vanaf je @graph gebruikt in JSON-LD vallen de triples verder onder de named graph die eerder beschreven was.

bvb:

{ 
  "@id" : "graaf1",
 "@graph" :[ {
    "@id": "subject",
    "predicate": "object",
  }]
}

Dit zal zich vertalen in een quad alsvolgt:

<subject> <predicate> <object> <graaf1> .

Een quad laat toe om zo een context te creëren bij triples. Een context zou bijvoorbeeld kunnen zijn in kader van #13, dat een triple (bvb 'het is 25°C') valt onder de context van een graaf, waarvan de graaf verder gedefinieerd is als een meting door een sensor op een bepaald moment.

RDF had initieel geen quads en enkel triples, waardoor sommige serialisaties deze quads niet ondersteunen, en dus hun triples niet binnen een bepaalde context zetten. Daar kan je dan wel bijvoorbeeld file-gebaseerd werken en zeggen: de triples binnen deze file zijn een observatie van een sensor op een bepaald moment, maar dat werkt uiteraard beperkend. Andere creatieve oplossingen binnen triple-representaties zonder quads werden dan gezocht binnen het domein van reification, wat vooral bestond uit lapmiddeltjes :)

[CumpsD]

In je tabel is Quads: Ja dan een verplichting, of gewoon een vaststelling dat JSON-LD overweg kan met quads?

[bertvannuffelen]

voor vocabularia, in het bijzonder OWL ontologien, is de XML representatie nog de meest voorkomende serialisatie. Dus "weinig gebruikt" slaat waarschijnlijk op "grote datasets".

[bertvannuffelen]

Elke API moet 1 of meerdere linked data serialisaties ondersteunen.

hiermee ga je ervan uit dat de generieke hypermedia driven API gekoppeld is aan linked data.
Ik zou graag dit niet als premisse maken.

Volgens mij legt hypermedia niet op dat de payload Linked Data moet zijn. We kunnen toch ook niet semantisch geannoteerde data uitwisselen waarbij enkel de hypermedia links, semantisch zijn beschreven.

Daarnaast het zal zo zijn voor de basisregisters dat de Linked Data ontsluiting voorzien wordt door een andere dienst is dan de REST API. Als we het geheel van alle ontsluitingsvormen nemen dan is er een Linked Data ontsluiting, maar ook een SOAP service, een WMS, een geolocation-services, enz.... Sommige van deze services zullen voldoen aan REST principes, maar zullen zelf niet voor de Linked Data ontsluiting voorzien.

[pietercolpaert]

@CumpsD Eerder een vaststelling en een voordeel om mooier bvb #13 te ondersteunen

@bertvannuffelen Goed punt. Lijkt het je een betere formulering als we zeggen dat het “zou moeten” 1 of meer Linked Data representatie ondersteunen? Afhankelijk van de verdere issues (bvb. graph queries ==> moet) kunnen we dan veronderstellen dat die dit kunnen verstrengen.

[pietercolpaert]

Hoe nu elke documentatie is aangepakt: met een extra optie met instructie hoe het ook met Linked Data te doen!