Skip to content

Framing should use embedded contexts for compaction #315

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
gkellogg opened this issue Feb 1, 2014 · 3 comments
Closed

Framing should use embedded contexts for compaction #315

gkellogg opened this issue Feb 1, 2014 · 3 comments

Comments

@gkellogg
Copy link
Member

gkellogg commented Feb 1, 2014

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:

{
"@context": {
  "foaf": "http://xmlns.com/foaf/0.1/",
  "doap": "http://usefulinc.com/ns/doap#",
  "doap_developer": {"@id": "doap:developer", "@type": "@id"},
  "doap_id": "@id",
  "doap_name": "doap:name",
  "foaf_name": "foaf:name"
 },
  "doap:name": null,
  "doap_developer": {
  "@context": {
    "foaf_id": "@id",
    "foaf_name": "foaf:name"
  }
  }
}

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:

{
  "@context": {
    "foaf": "http://xmlns.com/foaf/0.1/",
    "doap": "http://usefulinc.com/ns/doap#",
    "doap_developer": {"@id": "doap:developer", "@type": "@id"},
    "doap_id": "@id",
    "doap_name": "doap:name"
    "foaf_id": "@id",
    "foaf_name": "foaf:name"
  },
  "@graph": [{
    "doap_id": "http://rubygems.org/gems/json-ld",
    "doap_developer": {
      "doap_id": "http://greggkellogg.net/foaf#me",
      "foaf_name": "Gregg Kellogg"
    },
    "doap_name": "JSON::LD"
  }, {
    "doap_id": "http://rubygems.org/gems/rdf",
    "doap_developer": [
      {"foaf_id": "http://ar.to/#self", "foaf_name": "Arto Bendiken"},
      {"foaf_id": "http://bhuga.net/#ben", "foaf_name": "Ben Lavender"},
      {"foaf_id": "http://greggkellogg.net/foaf#me", "foaf_name": "Gregg Kellogg"}
    ],
    "doap_name": "RDF.rb"
  }, {
    "doap_id": "http://rubygems.org/gems/rdf-aggregate-repo",
    "doap_developer": {"foaf_id": "http://greggkellogg.net/foaf#me", "foaf_name": "Gregg Kellogg"},
    "doap_name": "RDF::AggregateRepo"
  }, {
    "doap_id": "http://rubygems.org/gems/rdf-json",
    "doap_developer": {"foaf_id": "http://ar.to/#self", "foaf_name": "Arto Bendiken"},
    "doap_name": "RDF::JSON"
  }, {
    "doap_id": "http://rubygems.org/gems/rdf-microdata",
    "doap_developer": {"foaf_id": "http://greggkellogg.net/foaf#me", "foaf_name": "Gregg Kellogg"},
    "doap_name": "RDF::Microdata"
  }, {
    "doap_id": "http://rubygems.org/gems/rdf-n3",
    "doap_developer": {"foaf_id": "http://greggkellogg.net/foaf#me", "foaf_name": "Gregg Kellogg"},
    "doap_name": "RDF::N3"
  }, {
    "doap_id": "http://rubygems.org/gems/rdf-rdfa",
    "doap_developer": {"foaf_id": "http://greggkellogg.net/foaf#me", "foaf_name": "Gregg Kellogg"},
    "doap_name": "RDF::RDFa"
  }, {
    "doap_id": "http://rubygems.org/gems/rdf-rdfxml",
    "doap_developer": {"foaf_id": "http://greggkellogg.net/foaf#me", "foaf_name": "Gregg Kellogg"},
    "doap_name": "RDF::RDFXML"
  }]
}

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:

PREFIX doap: <http://usefulinc.com/ns/doap#>
PREFIX foaf: <http://xmlns.com/foaf/0.1/>
SELECT *
WHERE {
  ?doap_id a doap:Project; doap:name ?doap_name; doap:developer ?foaf_id .
  ?foaf_id foaf:name ?foaf_name .
}
@seralf
Copy link

seralf commented Feb 1, 2014

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.

@gkellogg
Copy link
Member Author

gkellogg commented Feb 1, 2014

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.

@gkellogg
Copy link
Member Author

gkellogg commented Jan 7, 2017

This is satisfied by PR #445 and issues #247, #262, and #369.

@gkellogg gkellogg closed this as completed Jan 7, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants