o-development / ldo-legacy

Linked Data Objects
Other
19 stars 2 forks source link

Refactor to not be dependent on JSON-LD context #22

Open jaxoncreed opened 1 year ago

jaxoncreed commented 1 year ago

At the moment, LDO depends on the JSON-LD context to tell jsonld-dataset-proxy what an object should look like at runtime. This is an inappropriate use of the jsonld context and causes a few problems.

Problems

Firstly, Any fields that could have more than one object are marked with “@container”: “@set”. This interpretation does not exactly map to the interpretation outlined in the JSON-LD specification as the absence of a “@container” field does not officially mean a cardinality of 1 in JSON-LD. Therefore, in this version of LDO, developers should only use a JSON-LD context that was generated by the “build” command and not one that was generated externally.

Secondly, as noted in https://github.com/o-development/ldo/issues/18, generating cardinality using the same field in different shapes causes problems. For example, if one shape uses the field as a collection, but another does not, this would not be possible to represent using JSON-LD context (without frames).

Solution

A new context-like object should be generated that LDO can use at runtime. It should let different shapes use different contexts instead of a single context for all shapes.

mrkvon commented 1 year ago

Not sure if this is related: In shex, if we define cardinality of a predicate to be 0-1, but in the RDF we have multiple predicates, it seems that we receive array of objects, not just one. So the type doesn't match result in this case, either.

I'm not sure which of the multiple possible values should be chosen, but i'd expect LDO object to match type, even if data are inconsistent. Is this a valid expectation?

Example (omitting prefix definitions):

shape:

ex:FoafProfile EXTRA a {
  a [ foaf:Person ] ;
  foaf:name xsd:string ? ;
}

data:

:me
    a foaf:Person;
    foaf:name "Name", "OtherName".

result:

{ "name": ["Name", "OtherName"] }

We didn't try to run this simple example, but we experienced something similar. We initialized LDO with createLdoDataset(dataset), not with parseRdf(turtle) if it makes any difference

It seems that there isn't much that we can do with this at the moment, besides redefining the schema or pre-filtering the dataset.

jaxoncreed commented 1 year ago

It shouldn't make a difference if you initialize with createLdoDataset and not parseRdf.

In the simple example you provided, LDO should make name a string rather than an array of strings. Does it not do that?

mrkvon commented 12 months ago

In the simple example you provided, LDO should make name a string rather than an array of strings. Does it not do that?

Sorry for not replying earlier. I finally managed to make a minimal reproduction of the issue. You can see it on codesandbox or run it locally.

The code is here, shape is here and the output is

{"@id":"https://example.com/jane_doe/profile/card#me","type":{"@id":"Person"},"name":["Jane Doe","Jane"]}

Should we open a separate issue and mark this thread as offtopic?

jaxoncreed commented 10 months ago

Yep, this is a bug. We can create a separate issue for it.