Closed csontosreka closed 1 month ago
hmmm - this isn't going to behave the way you think...
JSON-LD Input
(there's two dates - date
and date1
both resolving to
https://schema.org/date){
"@context": [
"https://w3id.org/ro/crate/1.1/context",
{
"@vocab": "http://schema.org/",
"txc": {
"@id": "http://purl.archive.org/textcommons/terms#"
},
"@base": null,
"date": "https://schema.org/date",
"date1": "https://schema.org/date"
}
],
"@graph": [
{
"@id": "ro-crate-metadata.json",
"@type": "CreativeWork",
"conformsTo": {
"@id": "https://w3id.org/ro/crate/1.1"
},
"about": {
"@id": "./"
},
"name": "ro-crate-metadata.json",
"@reverse": {}
},
{
"@id": "./",
"@type": "Dataset",
"name": "./",
"date": "2024-03-05T13:00:00.000Z",
"date1": "2021-03-04",
"@reverse": {
"about": {
"@id": "ro-crate-metadata.json"
}
}
}
]
}
Compacted
Have a look at the bottom section of the following screenshot. The two dates have been put together. That means that when you put this crate back into describo, you will only have the date field - not the date and date1 fields.
.
There is nothing wrong with your code. It does what it's supposed to. The issue is one of usability. If anyone takes this crate and runs it through the json-ld tools (which must be considered), it will be modified in a non obvious way to the user.
What are your thoughts on this? Have you come up with an alternative solution to your profile that doesn't have this issue?
I can't accept this pull request as is because it will hide profile errors when the same id is used against different properties.
We are still debating what we could do here as it affects our other systems (eg. knowledge graph) as well.
@csontosreka @beepsoft Can this be closed / withdrawn?
While you are right that in some JSON-LD representations we could lose information it might be a good compromise when using the other less compact representations. Would it be acceptable to warn users that if someone is using different property names with the same URI-s it will not work universally for all JSON-LD formats, but we could still allow its use?
I'm sorry but I'm not comfortable enabling functionality that shouldn't be allowed. I think if this is something you need then it needs to be done in your layer.
Are you familiar with the email syntax marco+{something}@example.com
? Mail servers treat that as marco@example.com
(the +{something} is ignored).
Could something like that work in your use case where you have http://schema.org/title
and http://schema.org/title+hun
(so two different identifiers from describo's point of view) which your upper code layers can then use to reconstruct identifiers in a deterministic way?
I share your concerns as well and I am also not very comfortable with the solution we have now.
Thanks for your '+' suggestion we look into it!
We encountered a problem where a profile had both a "title" and a "hunTitle" field sharing the same URI for an ID. Due to Describo's requirement for unique IDs, only the first instance was displayed.
To fix this, we can combine the input field's name and id with a separator like this:
input.name + "|" + input.id
. This way, profiles can have two fields with the same id, as long as their names are different.You can try this implementation with "blank" crate and "profile-with-constraints.json" profile.