Skip to content

Content Negotiation for Turtle file #703

New issue
New issue
Closed
Closed
Content Negotiation for Turtle file#703
Labels
site tools + python codeInfrastructural issues around schema.org site. Most can ignore this!

Description

@lavhal
lavhal
opened on Aug 6, 2015

Hi,

Is it possible to implement content negotiation for turtle files with SchemaOrg site, so when user asks for:
curl -L -H "Accept: text/turtle" http://localhost:8080/Person , it will return turtle representation?

P.s. I used schema org for representing documentation of ontology/vocabulary and running it with GAE.

Best.

Activity

  1. unor commented on Aug 6, 2015

    @unor
    unor
    on Aug 6, 2015
    Contributor

    See #317

  2. RichardWallis
    added
    site tools + python codeInfrastructural issues around schema.org site. Most can ignore this!
    on Sep 6, 2016

  3. amiika commented on Oct 14, 2016

    @amiika
    amiika
    on Oct 14, 2016

    Content negotiation should work from "http://schema.org/" and include all supported formats:

    text/turtle (Turtle)
    application/n-quads (Quad)
    application/n-triples (Ntriples)
    application/ld+json (JSON-LD)
    application/xhtml+xml (RDFa)

  4. amiika commented on Oct 14, 2016

    @amiika
    amiika
    on Oct 14, 2016

    curl -L -v -H "Accept: application/ld+json" http://schema.org/ is actually working ... but im not sure if Context-definition is actually what you expect, at least i was expecting RDFS schema with Schema.org extensions.

  5. Dataliberate commented on Oct 14, 2016

    @Dataliberate
    Dataliberate
    on Oct 14, 2016
    Contributor

    This is not live on Schema.org yet - it will be in the next version.

    However it is visible on the prerelease site webschemas.org

    ~Richard

    On 14 Oct 2016, at 11:55, Miika Alonen notifications@github.com wrote:

    curl -L -v -H "Accept: application/ld+json" http://schema.org/ is actually working ... but im not sure if Context-definition is actually what you expect, at least i was expecting RDFS schema with Schema.org extensions.

    —
    You are receiving this because you are subscribed to this thread.
    Reply to this email directly, view it on GitHub, or mute the thread.

  6. danbri commented on Jul 17, 2020

    @danbri
    danbri
    on Jul 17, 2020
    Contributor

    We did this, and then we undid this. The site is now 100% static served, and faster. The JSON-LD context location is published in a JSON-LD 1.1-compliant HTTP header served by the homepage.

  7. danbri
    closed this as completedon Jul 17, 2020

  8. amiika commented on Jan 14, 2021

    @amiika
    amiika
    on Jan 14, 2021

    Does it actually work? Trying to get the json-ld format only gets you some nasty binary ouput. For example: curl -L -H "Accept: application/ld+json" https://schema.org/

  9. RichardWallis commented on Jan 14, 2021

    @RichardWallis
    RichardWallis
    on Jan 14, 2021
    Contributor

    As per @danbri's comment

    The JSON-LD context location is published in a JSON-LD 1.1-compliant HTTP header served by the homepage.

    The reference: https://www.w3.org/2018/jsonld-cg-reports/json-ld/#interpreting-json-as-json-ld

    As served by schema.org:
    curl -v https://schema.org

    ...
< access-control-allow-credentials: true
< access-control-allow-headers: Accept
< access-control-allow-methods: GET
< access-control-allow-origin: *
< access-control-expose-headers: Link
< link: </docs/jsonldcontext.jsonld>; rel="alternate"; type="application/ld+json"
...

  10. amiika commented on Jan 14, 2021

    @amiika
    amiika
    on Jan 14, 2021

    I don't really see or understand how one could get machine readable vocabulary with this solution.

  11. RichardWallis commented on Jan 14, 2021

    @RichardWallis
    RichardWallis
    on Jan 14, 2021
    Contributor

    A consuming application, when accessing the URL for a context document, should check the received http headers for a link header with a rel="alternate" value and a type="application/ld+json". If found it should use the document identified by the link URL instead of the received document.

    This approach is an alternative to content-negotiation, as defined in the JSON-LD 1.1 standard.

  12. amiika commented on Jan 14, 2021

    @amiika
    amiika
    on Jan 14, 2021

    Thanks for your responses. If i understood correctly the consuming application should follow the link tag to: http://schema.org/docs/jsonldcontext.jsonld. This file contains only json-ld context and not the actual vocabulary. Im looking for a way to resolve the schema.org as linked data vocabulary that contains the Class and Property definitions as well as the domainIcludes etc. information in RDF. If we consider - for example - the use case of RDF editor, is there any way to get the machine readable format for the schema.org vocabulary from the https//schema.org/ namespace?

  13. danbri commented on Jan 14, 2021

    @danbri
    danbri
    on Jan 14, 2021 via email
    Contributor

  14. danbri commented on Jan 14, 2021

    @danbri
    danbri
    on Jan 14, 2021 via email
    Contributor

  15. amiika commented on Feb 2, 2021

    @amiika
    amiika
    on Feb 2, 2021

    Thanks for the clarifications. I was really hoping that Schema.org would follow W3C best practice recipes for publishing RDF vocabularies. Even if the RDF vocabularies are huge, i really think that there should be machine readable way to access Schema.org vocabularies from the namespace address. Have you thought about using some sort of minified version? It could also be some sort Resource describing the alternative formats using seeAlso reference or void description.

  16. danbri commented on Feb 2, 2021

    @danbri
    danbri
    on Feb 2, 2021 via email
    Contributor

  17. amiika commented on Feb 2, 2021

    @amiika
    amiika
    on Feb 2, 2021

    No disrespect meant, but I dont see how schemaorg-current comes any near comparison with some large datasets like some SKOS schemes. Seems like relatively small vocabulary, which could be served statically with some redirect rules to different RDF formats.

    I might not see the reasoning behind the current solution. However - in my opinion - creating a new machine accessible convention is better than nothing. In our case, the syntax itself would not matter as the system is expecting any RDF format from the namespace. So for example a JSON-LD file resolved from the schema.org namespace with some hints (for example using rdfs:seeAlso or void:dataDump) to the actual vocabulary dumps would do. Not ideal, but better than nothing.

  18. gkellogg commented on Feb 15, 2021

    @gkellogg
    gkellogg
    on Feb 15, 2021
    Contributor

    The home page uses link: </docs/jsonldcontext.jsonld>; rel="alternate"; type="application/ld+json" to find the context, instead of content negotiation, which is a feature we added in JSON-LD 1.1 due to issues with modern publication platforms to do CN. Something similar, perhaps with a different link relation, could be done to point to alternate representations of the vocabulary.

    Given the controversy surrounding content negotiation in the wider web, having an alternative established as a best practice that accomplishes the same goals using more common mechanisms (if link headers can be considered common) would seem to be worthwhile.

    But, there seem to be two issues: how to find the vocabulary definitions, and how to deal with large vocabularies.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    site tools + python codeInfrastructural issues around schema.org site. Most can ignore this!

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions