Re: Designing my vocabulary

JSON-LD is an RDF syntax, so everything can be represented (minus some
datatype edge cases I guess [1]).

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

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 20:51:59 UTC