You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As specified, framing uses a single context to perform compaction, however, there are cases where specific sub-frames may want to use their own context. For example, consider the following frame:
This defines aliases for @id and foaf:name exclusive to the values of doap:developer. The desired output would use the embedded context definition for compacting the portions of that frame; example output from doing this might be the following:
The use case for this is to allow an easy way to map JSON-LD with embedding to a CSV format. The CSV transformation would just take the property definitions and flatten into a single table, such as the following:
doap_id
doap_name
foaf_id
foaf_name
<http://rubygems.org/gems/json-ld>
JSON::LD
<http://greggkellogg.net/foaf#me>
Gregg Kellogg
<http://rubygems.org/gems/rdf>
RDF.rb
<http://ar.to/#self>
Arto Bendiken
<http://rubygems.org/gems/rdf>
RDF.rb
<http://bhuga.net/#ben>
Ben Lavender
<http://rubygems.org/gems/rdf>
RDF.rb
<http://greggkellogg.net/foaf#me>
Gregg Kellogg
<http://rubygems.org/gems/rdf-aggregate-repo>
RDF::AggregateRepo
<http://greggkellogg.net/foaf#me>
Gregg Kellogg
<http://rubygems.org/gems/rdf-json>
RDF::JSON
<http://ar.to/#self>
Arto Bendiken
<http://rubygems.org/gems/rdf-microdata>
RDF::Microdata
<http://greggkellogg.net/foaf#me>
Gregg Kellogg
<http://rubygems.org/gems/rdf-n3>
RDF::N3
<http://greggkellogg.net/foaf#me>
Gregg Kellogg
<http://rubygems.org/gems/rdf-rdfa>
RDF::RDFa
<http://greggkellogg.net/foaf#me>
Gregg Kellogg
<http://rubygems.org/gems/rdf-rdfxml>
RDF::RDFXML
<http://greggkellogg.net/foaf#me>
Gregg Kellogg
This is also consistent with how an HTML representation of SPARQL results might look from the following query:
Yes, i also think the csv representation whould be coherent to the html one, which uses tables.
On the other hand the process could be seen in the opposite direction: for example if the CSV-LD needs to introduce specific columns or rows in the format to track things like context, linking on other csv files or whatever, I think those features could be seen as an input to provide suggestions for the a review of the HTML result format.
You can see the CSV-LD proposal here, comments are welcome at [email protected] and/or here on [email protected]. It's just a start, and it's not intended to allow any JSON-LD to be transformed to CSV, but it does use the framing mechanism to allow two-way transformation between CSV and JSON-LD. There is also a proposal for describing @context information in CSV but I don't consider this to be a primary use-case.
As specified, framing uses a single context to perform compaction, however, there are cases where specific sub-frames may want to use their own context. For example, consider the following frame:
This defines aliases for @id and foaf:name exclusive to the values of doap:developer. The desired output would use the embedded context definition for compacting the portions of that frame; example output from doing this might be the following:
The use case for this is to allow an easy way to map JSON-LD with embedding to a CSV format. The CSV transformation would just take the property definitions and flatten into a single table, such as the following:
This is also consistent with how an HTML representation of SPARQL results might look from the following query:
The text was updated successfully, but these errors were encountered: