Are Value Objects Allowed?

[multimeric]

Value Objects are used in JSON-LD when you want to add some extra detail to a literal such as a type or a language, e.g.

{
  "@id": "./",
  "@type": "Dataset",
  "datePublished": {
    "@type": "http://www.w3.org/2001/XMLSchema#date",
    "@value": "2025-01-01"
  },
  "name": {
      "@value": "My Crate",
      "@language": "en"
    }
}

I can't find mention of this in the spec, but currently crs4/rocrate-validator seems confused by them. You could argue that they should be excluded for simplicity, but removing them also removes a lot of expressiveness.

[simleo]

I think this is not allowed because the metadata is not flattened, see also crs4/rocrate-validator#106 (comment)

[multimeric]

No I believe this is still considered flattened. If I use pyld to flatten the offending document, it still preserves the object with @type and @value:

>>> from pyld import jsonld
>>> from pprint import pprint
>>> pprint(doc)
{'@context': ['https://w3id.org/ro/crate/1.1/context'],
 '@graph': [{'@id': './',
             '@type': 'Dataset',
             'author': 'abcd',
             'datePublished': {'@type': 'http://www.w3.org/2001/XMLSchema#date',
                               '@value': '2025-01-01'},
             'description': 'abcd',
             'license': 'abcd',
             'name': 'abcd',
             'publisher': {'@id': '#publisher'}},
            {'@id': 'ro-crate-metadata.json',
             '@type': 'CreativeWork',
             'about': {'@id': './'},
             'conformsTo': {'@id': 'https://w3id.org/ro/crate/1.1'}},
            {'@id': '#publisher', '@type': 'Organization'}]}
>>> pprint(jsonld.flatten(doc))
[{'@id': '#publisher', '@type': ['http://schema.org/Organization']},
 {'@id': './',
  '@type': ['http://schema.org/Dataset'],
  'http://schema.org/author': [{'@value': 'abcd'}],
  'http://schema.org/datePublished': [{'@type': 'http://www.w3.org/2001/XMLSchema#date',
                                       '@value': '2025-01-01'}],
  'http://schema.org/description': [{'@value': 'abcd'}],
  'http://schema.org/license': [{'@value': 'abcd'}],
  'http://schema.org/name': [{'@value': 'abcd'}],
  'http://schema.org/publisher': [{'@id': '#publisher'}]},
 {'@id': 'ro-crate-metadata.json',
  '@type': ['http://schema.org/CreativeWork'],
  'http://purl.org/dc/terms/conformsTo': [{'@id': 'https://w3id.org/ro/crate/1.1'}],
  'http://schema.org/about': [{'@id': './'}]}]

[stain]

@value can technically be part of JSON-LD flattened form, you can try Flatten in https://json-ld.org/playground/ for instance and it is persisted. However, we have not documented nor recommend use of @value in RO-Crate, as it complicates processing as JSON. I understand this means a loss of the XSD type information and these may sneak in if converting from say Turtle to JSON-LD.

Our JSON-LD context also does not set such XSD types on datePublished context for instance.

And so while we have not strictly forbidden it in RO-Crate, it is also never used in any examples. We should add a note to this in https://www.researchobject.org/ro-crate/specification/1.2/appendix/jsonld.html to warn against its use.

I think in typical schema.org usage on the Web, he XSD strings are not required or even recommended to use, even if they have range pointing to XSD-like types like https://schema.org/datePublished says range is https://schema.org/DateTime or https://schema.org/Date -- these are in schema.org land never really use as @type on string values and are more for guidance. They are also different constants than the usual xsd: suspects.

Using @value is however something to consider particularly to support language strings, for instance different name in different languages, then combined with @language. @ptsefton had some ideas on this but I can't find the issue.

[multimeric]

Thanks Stain, if you think it should be banned then I guess that guidance should go into the spec.

I'm a bit wary of doing that though, because this would reduce the expressiveness of RO-Crate. The other JSON-LD restrictions like flattening still allow any RDF graph to be represented, but if you remove @type for values then suddenly we can't round-trip RDF, we can't represent dates etc.

[jmfernandez]

Hi, as a programmer who added WRROC support to its own software, I'm divided. On one hand, fully supporting this means to check lots of lines of code, and I'm not only talking about my own code, but cornerstone libraries for the RO-Crate ecosystem. On the other hand, losing expressiveness means what @multimeric has explained.

So, my suggestion is including maybe a clarifying note about this topic for RO-Crate 1.2 and older. Also, I think the steering committee should either decide whether RO-Crate 2 should officially restrict the expressiveness, or developers of software related to RO-Crate 2 should support it in its fully extent (as well as passing some official tests) in order to get some kind of official "RO-Crate 2 compliant seal of approval.

Just my own opinion.

[multimeric]

A possible compromise is to allow @type in the @context only, which tools can and largely do ignore. However this poses a further question which is whether we should allow {"@type": "@id"} in the context as well. Personally I think that would be a nice idea, because I find "property": {"@id": "some_id"} to be ugly, but it's standard practice at the moment.

[stain]

I think it could make sense for properties you add specifically, as long as it does not change the "pure JSON" interpretation.

The schema.org context do have {"@type": "@id"} on some properties but not all (some properties allow both Text and nested objects). I think it's not sufficiently clear in the spec, but this should be reconsidered for 2.0. I think the thought was to make it explicit/consistent. I've seen too many times schema.org markup where there is such a @type annotation but still markup makers put "author": "Stian Soiland-Reyes" which is then not a valid @id URI reference. So here the challenge is it breaks the "pure JSON" interpretation as you need to check in the context if there is such a @type or not!

[multimeric]

Okay I take your point: {"@id": "..."} is clearly not a literal, and that makes processing easier.

The most consistent would actually be to enforce that all literals as value objects, right? Because then implementations can always look for @value for literals or @id for node references. But that also makes everything more verbose, harder to read and write by hand.

[stain]

All literals as value objects would be very verbose to write.. and then you have to still take into consideration there may be 1 or more values ([] or {}).

You can consider processing to JSON-LD Expanded form which is easier to consume consistently if you want to be in RDF-land. So for instance in https://json-ld.org/playground/ if I use this example RO-Crate I get:

[
  {
    "@id": "https://www.researchobject.org/ro-crate/specification/1.2/examples/rainfall-1.2.0/ro-crate-metadata.json",
    "@type": [
      "http://schema.org/CreativeWork"
    ],
    "http://schema.org/about": [
      {
        "@id": "https://www.researchobject.org/ro-crate/specification/1.2/examples/rainfall-1.2.0/"
      }
    ],
    "http://purl.org/dc/terms/conformsTo": [
      {
        "@id": "https://w3id.org/ro/crate/1.2"
      }
    ]
  },
  {
    "@id": "https://www.researchobject.org/ro-crate/specification/1.2/examples/rainfall-1.2.0/",
    "@type": [
      "http://schema.org/Dataset"
    ],
    "http://schema.org/datePublished": [
      {
        "@value": "2022-12-01"
      }
    ],
    "http://schema.org/description": [
      {
        "@value": "Official rainfall readings for Katoomba, NSW 2022, Australia"
      }
    ],
    "http://schema.org/hasPart": [
      {
        "@id": "https://www.researchobject.org/ro-crate/specification/1.2/examples/rainfall-1.2.0/data.csv"
      }
    ],
    "http://schema.org/license": [
      {
        "@id": "http://spdx.org/licenses/CC0-1.0"
      }
    ],
    "http://schema.org/name": [
      {
        "@value": "Example dataset for RO-Crate specification"
      }
    ],
    "http://schema.org/publisher": [
      {
        "@id": "https://ror.org/04dkp1p98"
      }
    ]
  },
  {
    "@id": "https://www.researchobject.org/ro-crate/specification/1.2/examples/rainfall-1.2.0/data.csv",
    "@type": [
      "http://schema.org/MediaObject"
    ],
    "http://schema.org/encodingFormat": [
      {
        "@value": "text/csv"
      }
    ],
    "http://schema.org/license": [
      {
        "@id": "https://creativecommons.org/licenses/by-nc-sa/3.0/au/"
      }
    ],
    "http://schema.org/name": [
      {
        "@value": "Rainfall data for Katoomba, NSW Australia February 2022"
      }
    ]
  },
  {
    "@id": "https://ror.org/04dkp1p98",
    "@type": [
      "http://schema.org/Organization"
    ],
    "http://schema.org/description": [
      {
        "@value": "Australian Government Bureau of Meteorology"
      }
    ],
    "http://schema.org/name": [
      {
        "@value": "Bureau of Meteorology"
      }
    ],
    "http://schema.org/url": [
      {
        "@value": "http://www.bom.gov.au/"
      }
    ]
  },
  {
    "@id": "https://creativecommons.org/licenses/by-nc-sa/3.0/au/",
    "@type": [
      "http://schema.org/CreativeWork"
    ],
    "http://schema.org/description": [
      {
        "@value": "Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Australia"
      }
    ],
    "http://schema.org/name": [
      {
        "@value": "CC BY-NC-SA 3.0 AU"
      }
    ]
  },
  {
    "@id": "http://spdx.org/licenses/CC0-1.0",
    "@type": [
      "http://schema.org/CreativeWork"
    ],
    "http://schema.org/description": [
      {
        "@value": "This is a human-readable summary of the Legal Code (read the full text).\n\nNo Copyright\n\n    The person who associated a work with this deed has dedicated the work to the public domain by waiving all of his or her rights to the work worldwide under copyright law, including all related and neighboring rights, to the extent allowed by law.\n\n    You can copy, modify, distribute and perform the work, even for commercial purposes, all without asking permission. See Other Information below.\n\nThis license is acceptable for Free Cultural Works.\nOther Information\n\n    In no way are the patent or trademark rights of any person affected by CC0, nor are the rights that other persons may have in the work or in how the work is used, such as publicity or privacy rights.\n    Unless expressly stated otherwise, the person who associated a work with this deed makes no warranties about the work, and disclaims liability for all uses of the work, to the fullest extent permitted by applicable law.\n    When using or citing the work, you should not imply endorsement by the author or the affirmer.\n"
      }
    ],
    "http://schema.org/identifier": [
      {
        "@value": "CC0-1.0"
      }
    ],
    "http://schema.org/name": [
      {
        "@value": "Creative Commons Zero v1.0 Universal"
      }
    ],
    "http://schema.org/url": [
      {
        "@value": "https://creativecommons.org/publicdomain/zero/1.0/"
      }
    ]
  }
]

You will notice that here all properties are full URIs, and all values are wrapped inside [ { "@value": ... } ] and all references as [ { "@id": ... } ]

[multimeric]

I'm using RDF machinery so parsing is mostly "free" for me. Rather my concern is retaining expressiveness (languages, data types) while also making it easy for JSON parsers. Honestly the fully expanded form is delightfully regular and therefore easy to parse, but it's also pretty ugly so I can see why it has been avoided.

Back to the original problem, I think the context is designed for adding an RDF layer onto plain JSON, which is why JSON-LD lets you provide plain JSON and a separate context if you want. So I suggest we move as much RDF logic over to there are possible rather than treating it like a flat term list. I think data types, container types, languages, @id for IRIs should all be moved over there where it makes sense to.