Code Monkey home page Code Monkey logo

Comments (3)

iherman avatar iherman commented on June 20, 2024 2

This issue was discussed in a meeting.

  • RESOLVED: Close framing #31, wontfix, with request for further discussion if they can provide more information to support its inclusion {: #resolution13 .resolution}
  • ACTION: Rob Sanderson to put comment in to #31 requesting more info
View the transcript Provide an option for all terms to get a default "@container"
Rob Sanderson: ref: #31
Gregg Kellogg: I had discussed putting in a default container set unless set otherwise.
… which is less disruptive than the graph id
… not a framing issue, but a compaction issue
Rob Sanderson: just a convenience mechanism
… is the value of this higher enough to warrant a new default?
Gregg Kellogg: can’t be done in framing, must be in compaction.
… is it valuable enough?
Ivan Herman: this is what schema would do. They are very systematic in mapping this.
… this will make schema.org will get there automatically
Gregg Kellogg: currently, list and set are incompatible, though we’ve discussed this.
David Newbury: .. one used to be ordered, and one unordered…but we’ve overridden that already.
Rob Sanderson: for this issue, if you were to set a default container at @language
Gregg Kellogg: that would be scary. Everything would be a language map.
… and you’d have to define that.
Rob Sanderson: if you snuck this away…
Rob Sanderson: how would you undo this if it was @set?
Gregg Kellogg: … empty array? @container: null?
Rob Sanderson: in my opinion, the value is outweighed by the danger
David Newbury: I don’t think that we need better ergonomics for creating contexts…
Rob Sanderson: so we propose that this is valuable, but can they provide more use cases other than it being a bit redundant?
Proposed resolution: push back to original commenter, asking for more use cases. Saving context authors some keystrokes is not a high priority (Rob Sanderson)
David Newbury: +1
Jeff Mixter: +1
Rob Sanderson: +1
Gregg Kellogg: +1
Ivan Herman: +1
Rob Sanderson: …
Proposed resolution: Close framing #31, wontfix, with request for further discussion if they can provide more information to support its inclusion (Rob Sanderson)
David Newbury: +1
Rob Sanderson: +1
Ivan Herman: +1
Jeff Mixter: +1
David I. Lehn: +1
Action #2: Rob Sanderson to put comment in to #31 requesting more info
Gregg Kellogg: +1
Harold Solbrig: +1
Resolution #13: Close framing #31, wontfix, with request for further discussion if they can provide more information to support its inclusion {: #resolution13 .resolution}

from json-ld-framing.

michaelcpuckett avatar michaelcpuckett commented on June 20, 2024

Thanks @iherman for reviewing this.

For my specific case, I want to model my data based on schema.org. I want to keep a generic, reusable frame and have the schema.org @vocab do the heavy lifting of mapping the relationships. Unfortunately I must define every schema.org term I might use in the @context. If these could all be set to a default, I would not need to have complete knowledge of the vocabulary I'm using.

jsonld.frame(json, {
  "@context": {
    "@vocab": "http://schema.org/",
    "agent": {
      "@container": "@set",
      "@type": "@id"
    },
    "participant": {
      "@container": "@set",
      "@type": "@id"
    },
    "recipient": {
      "@container": "@set",
      "@type": "@id"
    },
    "author": {
      "@container": "@set",
      "@type": "@id"
    },
    ...
  },
})

If there is a simpler way to achieve this, please let me know.

from json-ld-framing.

azaroth42 avatar azaroth42 commented on June 20, 2024

Thanks @michaelcpuckett ! There isn't an easier way to do it I'm afraid, as the situation where every term in a vocabulary should always be @container: @set is vanishingly small. It would mean that every relationship was aways one to many or many to many, and never one to one or one to many. (It's also a syntax issue for compaction via setting a context, rather than a framing issue per se, but that's not a big deal)

My understanding of the intent of @vocab is to provide a default mapping from JSON to RDF, rather than a default mapping from RDF into a particular JSON structure. We have heard from several parties that the schema.org approach of just throwing @vocab in there and letting the application sort it out is often insufficient, and it seems like you're in the same boat.

from json-ld-framing.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.