Re: Designing my vocabulary

> On Mar 16, 2020, at 1:51 PM, Martynas Jusevičius <martynas@atomgraph.com> wrote:
> 
> JSON-LD is an RDF syntax, so everything can be represented (minus some
> datatype edge cases I guess [1]).

JSON-LD 1.1 introduces an rdf:JSON datatype, but this can be represented in all other RDF syntaxes as well (much as rdf:HTML and rdf:XMLLiteral can be represented in JSON-LD, although this might not be too interesting).

JSON-LD 1.1 is, of course, a dataset syntax, so it is really closer to TriG than Turtle in that regard. A shortcoming of JSON-LD 1.0 was the inability to (elegantly) represent lists of lists. That has also been solved in 1.1.

JSON-LD 1.1 also adds support for text direction (right-to-left, left-to-right), though the use of an I18N-based IRI, which can also be represented in other RDF syntaxes, but there is no real RDF-level specification for this right not, but I expect it to come sometime in the future

A couple of things that JSON-LD 1.1 can support that other RDF syntaxes can’t are really not too good to do anyway, specifically BNode Literals. It ends up they’re really not necessary for the use cases they were promoted for, but can’t really be deprecated. I’d just stay away from these.

> What I'm thinking is merging 2 or more datasets, for example. Are you
> going to do it as RDF triples or on JSON syntax? RDF merge is
> well-defined (basically append); JSON-LD carrying the same triples can
> have different structures.
> 
> [1] https://www.w3.org/TR/json-ld11-api/#data-round-tripping

JSON-LD differs from other RDF syntaxes is that it defines an API for manipulating JSON-LD and transforming to/from RDF, while other syntaxes typically limit themselves to transforming from their native syntax to the RDF Abstract Syntax (basically N-Triples/N-Quads without specifics of BNode naming). Thus, we have an algorithm for merging graphs and datasets, but semantically it is equivalent to transforming to an RDF Dataset and then back into JSON-LD, where you might frame it to look pretty. As always, the potential for BNode name collisions can be an issue, if not handled properly.

Gregg

> On Mon, Mar 16, 2020 at 12:50 PM James Hudson <jameshudson3010@gmail.com> wrote:
>> 
>> Hello Martynas,
>> 
>> What can be represented in RDF that cannot be represented in JSON-LD?
>> 
>> Regards,
>> James
>> 
>> 
>> On Fri, Mar 13, 2020 at 5:11 PM Martynas Jusevičius <martynas@atomgraph.com> wrote:
>>> 
>>> Fair enough, you can pretend JSON-LD is just JSON with annotations.
>>> But you will not be able advantage of RDF's features if you try to
>>> ignore the triple model behind it and only work with surface syntax.
>>> 
>>> On Fri, Mar 13, 2020 at 9:51 PM James Hudson <jameshudson3010@gmail.com> wrote:
>>>> 
>>>> Hello Martynas,
>>>> 
>>>> On Fri, Mar 13, 2020 at 9:59 AM Martynas Jusevičius <martynas@atomgraph.com> wrote:
>>>>> 
>>>>> the common case is instances having a property with a value and the
>>>>> "schema" defining a constraint (using SHACL, SPIN etc.) for that
>>>>> property with the range of valid values. How would you enforce the
>>>>> constraint if there was no such distinction and the constraints were
>>>>> part of instance data?
>>>> 
>>>> 
>>>> As I and you already noted, this is not the correct path to follow. The concept and implementation of an enforceable constraint should exist outside of instances.
>>>> 
>>>>> I don't think your SHACL example uses the actual range constraints.
>>>>> "4.3 Value Range Constraint Components" looks like what you need:
>>>>> https://www.w3.org/TR/shacl/#core-components-range
>>>> 
>>>> 
>>>> I did not attempt to provide a SHACL example.
>>>> 
>>>>> 
>>>>> I'd also suggest to use Turtle for your examples, to get away from the
>>>>> overhead of the JSON-LD syntax and get closer to triples.
>>>> 
>>>> 
>>>> As a mere practitioner of this stuff, I am going to stay as far away from Turtle and triples as I can, dealing with them only when I have to. It is easier to sell json to people, which looks "normal" than it is to sell stuff that looks like triples, which most have never seen before and would be confused by. This is a marketing challenge to me as much as a technical one.
>>>> 
>>>> Regards,
>>>> James
>>>> 
>>>> 
>>>> 
>>>> 
>>>>> 
>>>>> 
>>>>> On Fri, Mar 13, 2020 at 2:47 PM James Hudson <jameshudson3010@gmail.com> wrote:
>>>>>> 
>>>>>> Hello,
>>>>>> 
>>>>>> Since I hate mailing lists threads which just end without any resolution or summary, I wanted to add what I learned, primarily in conversation with Adam K, in case others are interested now or later.
>>>>>> 
>>>>>> Based on my research into this topic there appears to be two reasonable solutions. Perhaps one solution is more reasonable then the other.
>>>>>> 
>>>>>> One key is to recognize that constraints exist as a concept outside of the instance of a class and should be outside of the actual instance data.
>>>>>> 
>>>>>> The first solution is to adopt https://www.w3.org/TR/shacl/. It is a W3C recommendation and supported project. It provides a well defined, generic, and powerful system for applying constraints to properties. There are standard libraries which implement SHACL which provide enforcement for free. The caveat here is that adopting SHACL may provide more power and flexibility than is needed by a project and the overhead of maintaining Shape files may not be worthwhile. Whether this is an issue will only be known with time and experience as the technology is new.
>>>>>> 
>>>>>> The second solution follows this general model:
>>>>>> 
>>>>>>    {
>>>>>>      "@id": "http://my-company.org/chanceOfSuccess",
>>>>>>      "@type": "rdf:Property",
>>>>>>      "http://schema.org/domainIncludes": {
>>>>>>        "@id": "http://my-company.org/Event"
>>>>>>      },
>>>>>>      "http://schema.org/rangeIncludes": {
>>>>>>          "@id": "http://schema.org/QuantitativeValue"
>>>>>>      },
>>>>>>      “ex:chanceMinValue” : “30”,
>>>>>>      “ex:chanceMaxValue” : “60”,
>>>>>>      "rdfs:comment": “Allow values are only 30-60.",
>>>>>>      "rdfs:label": “chanceOfSuccess with range 30-60"
>>>>>>    }
>>>>>> 
>>>>>> In this case, we declare the property and as part of that declaration, the constraints are encoded. How these constraints are defined and enforced is up to the particular project using the objects. At a minimum, code needs to be written which may not be available outside of the project to enforce the constraints.
>>>>>> 
>>>>>> The SHACL solution is the one I will be going with for now.
>>>>>> 
>

Received on Monday, 16 March 2020 21:37:12 UTC