Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    iwan.aucamp
    @iwan.aucamp:matrix.org
    [m]
    Iwan Aucamp
    @aucampia
    ah, well, that is awkward
    Iyanuoluwa (Elijah) Raji
    @iraji1
    Hey Everyone, I've been trying to build out a JSON-LD Sample based on some dummy data and I'm having issues. Is there anyone that can assist
    Iwan Aucamp
    @aucampia
    @iraji1 I'm sure there is someone that can help, but you have to say what the problem is
    gnoric
    @gnoric
    Hi guys, anyone here? I got a question for you json-ld experts :)
    is there any way (including frames) to inherit a relationship, say: if child of, and child of, then grandchild of! Or is the only way to modify the original json?
    {
        "@id"     : "Model 1",
        "@type"    : "abc:model",
        "entities" : [
            {
                "@id"     : "Entity 1",
                "@type"    : "abc:entitiy",
                "attributes" : [
                    {
                        "@id"     : "Attribute 1",
                        "@type"    : "abc:attribute"
                    }
                ]
            }
        ]
    }
    gnoric
    @gnoric
    is there any possibility to say that Attribute 1 is in Model 1 without altering the json?
    Gregg Kellogg
    @gkellogg
    I answered the question in a private response. Might want to work in the RDF domain with RDFS/OWL inferrence or SPARQL Update then re-serialize as JSON-LD.
    gnoric
    @gnoric
    @gkellogg Thank you so much for taking the time to respond! <3
    Blake Regalia
    @blake-regalia
    does anyone recall discussions about the term canonicalization vs normalization and why one is preferred over the other ?
    Gregg Kellogg
    @gkellogg
    Regarding federated queries; JSON-LD isn't really a query language (although framing includes some filtering aspects). SPARQL is the appropriate standard to look to for doing federated queries, and the results can be formatted as JSON-LD.
    Re canonicalization vs. normalization, I consider them to be synonyms, with canonicalization (C14N) more common. There is a proposed Working Group that would include this work: https://w3c.github.io/lds-wg-charter/, which now uses the RDF Dataset Canonicalization naming, rather than the former RDF Dataset Normalization naming.
    Mark Foster
    @mfosterio
    @gkellogg Can JSON-LD be converted to rdfs and then queried by SPARQL?
    Mark Foster
    @mfosterio
    @gkellogg I am still learning these technologies. I was assuming that the conversion to N-Quads was triples with a graph dimension. https://json-ld.org/playground/ https://stackoverflow.com/questions/38112473/how-to-import-and-query-4-column-n-quad-quadruples-into-blazegraph
    Adrian Gschwend
    @ktk
    @mikcaweb JSON-LD is RDF and you can load it to most stores that provide SPARQL
    RDFS is the schema part, RDF is the "model" itself
    and yes N-Quads is N-Triples plus a graph IRI
    Iwan Aucamp
    @aucampia
    @mikcaweb but you can write RDFS in JSON-LD, as RDFS is just RDF, and JSON-LD is an encoding of RDF. So you cannot exactly convert JSON-LD to RDFS, but you can encode an RDF schema in JSON-LD
    Iwan Aucamp
    @aucampia
    RDFLib has this issue: RDFLib/rdflib#1443 (json-ld parser adds trailing slash to URLs that have no path) and there is this attempted fix RDFLib/rdflib#1456 (Fix JSON-LD data import adds trailing slashes to IRIs (#1443) #1456)

    So I think in part the issue is that the logic in RDFLib is not this:

    https://www.w3.org/TR/json-ld11/#type-coercion

    If no matching term is found in the active context, it tries to expand it as an IRI or a compact IRI if there's a colon in the value; otherwise, it will expand the value using the active context's vocabulary mapping, if present. Values coerced to @id in contrast are expanded as an IRI or a compact IRI if a colon is present; otherwise, they are interpreted as relative IRI references.

    .

    But I can't find the normative content which covers this
    nevermind it is this https://www.w3.org/TR/json-ld-api/
    Iwan Aucamp
    @aucampia
    can I somehow add comments to json-ld - I want to add an element which should be ingored by the processor
    I will go for @_comment for now
    Iwan Aucamp
    @aucampia
    okay I went for @x-comment - seems to be okay for riot and jsonld-cli
    Gregg Kellogg
    @gkellogg
    Its a common solution, althoughit. Ay raise warnings if a processor.
    haciendalosolivos
    @haciendalosolivos:matrix.org
    [m]
    Hello everyone. A very dumb question. I have a site of my own made with wix.com I know 0 about programming. I am aware of the importance of linked data in order for search engines to relate contents and obtain more visibility. However I am wondering if the effort to use JSN-LD properly in my site it is worth it. I repeat. I know 0 about it. My website is a Rural House and I am happy with it. Thank you very much.
    2 replies
    Gregg Kellogg
    @gkellogg
    Generally, it depends on your goals. If you want search engines to be able to pick up pertinent information, then you might look at the examples at https://schema.org, and apply those patterns to your own site. Many people find JSON-LD script blocks the easiest way to add semantic information to their websites.
    2 replies
    Devon Sparks
    @devonsparks

    Hi all,

    Mostly from curiosity, I'm trying to find a JSON-LD pattern that let's me use nested node identifier indexing so that URI paths match their corresponding JSON Pointer.
    For example, suppose I have the following JSON-LD document, representing Oregon cities, and hosted at the root of https://oregon.gov

        {
            "@context": {
                "@version": 1.1,
                "@vocab": "https://rels.org/",
                "@base": "http://oregon.gov/cities/",
                "path":"@id",
                "cities": {
                    "@id": "city",
                    "@container": "@id"
                },
                "neighborhoods": {
                    "@id": "neighborhood",
                    "@container": "@id"
                },
                "buildings": {
                    "@id": "building",
                    "@container": "@id"
                }
    
            },
            "@id":"#",
            "cities": {
                "portland": {
                    "@context": {
                        "@base": "portland/neighborhoods/"
                    },
                    "neighborhoods": {
                        "laurelhurt": {
                            "@context": {
                                "@base": "laurelhurt/buildings/"
                            },
                            "buildings": {
                                "ice-cream-shop": {
                                    "path": "/cities/portland/neighborhoods/laurelhurt/buildings/ice-cream-shop"
                                }
                            }
                        }
                    }
                }
            }
        }

    This document captures what I intended: the URI of "ice-cream-shop" is http://oregon.gov/cities/portland/neighborhoods/laurelhurt/buildings/ice-cream-shop. Its URI path is /cities/portland/neighborhoods/laurelhurt/buildings/ice-cream-shop, which also happens to be its JSON pointer within the document. This is fun, because it lets clients with no JSON-LD processing capability infer the path structure directly from the document.

    The only trouble are those nested @contexts. Currently they get lost if I attempt to do any kind of framing, and I can't see how to "hoist" them up to the parent document's @context because they depend on the identifier index of the node they belong to. The current approach effectively uses nested @contexts to build up a stack of @base path fragments.

    Is there any way to address this use case without relying on nested @contexts?

    Thanks!

    Gregg Kellogg
    @gkellogg
    Devon Sparks
    @devonsparks

    Thanks @gkellogg! I had tried this, but couldn't figure out how to make scoped contexts work in combination with node identifier indexing. If I added another city with a node identifier index like "eugene", I'd need a new @context detail, like

       "neighborhoods": {
          "@id": "neighborhood",
          "@context": {
            "@base": "eugene/neighborhoods/"
          },
          "@container": "@id"
        },

    But, like your sample shows (thanks for that!), we already have @base set to "portland/neighborhoods", so the two would be in conflict. I haven't been able to see how to "parameterize" scoped @contexts or @bases by named identifier indices.

    I'm at peace this may not be possible outside of my original snippet, but wanted to check with the experts first :)

    Devon Sparks
    @devonsparks

    Does anyone have suggestions for improvement for porting this SHACL list validation example? I've used a nested context to to ensure the inner sh:path is parsed as a list (the outer sh:path is not):

    {
        "@context": {
            "dash": "http://datashapes.org/dash#",
            "rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#",
            "rdfs": "http://www.w3.org/2000/01/rdf-schema#",
            "sh": "http://www.w3.org/ns/shacl#",
            "xsd": "http://www.w3.org/2001/XMLSchema#",
            "ex": "http://example.com/"
        },
        "@id": "ex:TrafficLightShape",
        "sh:targetClass": {
            "@id": "ex:TrafficLight"
        },
        "sh:property": {
            "sh:path": {
                "@id": "ex:colors"
            },
            "sh:property": {
                "sh:datatype": {
                    "@id": "xsd:string"
                },
                "@context": {
                    "sh:path": {
                        "@container": "@list"
                    }
                },
                "sh:path": [
                    {
                        "sh:zeroOrMorePath": {
                            "@id": "rdf:rest"
                        }
                    },
                    {
                        "@id": "rdf:first"
                    }
                ],
                "sh:minLength": 1,
                "sh:minCount": 2,
                "sh:maxCount": 3
            }
        }
    }

    Original TTL snippet is:

    ex:TrafficLightShape
        a sh:NodeShape ;
        sh:targetClass ex:TrafficLight ;
        sh:property [
            sh:path ex:colors ;
            sh:node dash:ListShape ;
            sh:property [
                sh:path ( [ sh:zeroOrMorePath rdf:rest ] rdf:first ) ;
                sh:datatype xsd:string ;
                sh:minLength 1 ;
                sh:minCount 2 ;
                sh:maxCount 3 ;
            ]
        ] .

    TopQuadrant reference where the example came from: https://www.topquadrant.com/constraints-on-rdflists-using-shacl/