w3id.org skg-if sandbox usage

[rduyme]

Hi,

In https://skg-if.github.io/interoperability-framework/

https://w3id.org/skg-if/sandbox/<provider acronym>/" 

We provide w3id.org base for SKG-IF providers. I find the sandbox term quite confusing in the URL, sandbox really sounds "not production ready", could we rename the url to

https://w3id.org/skg-if/provider/<provider acronym>/

This request is following change that will be implemented after skg-if/api#54 discussion.

Having for example prefixes

• https://w3id.org/skg-if/provider/cessda/
• https://w3id.org/skg-if/provider/openaire/
• https://w3id.org/skg-if/provider/xxx/

would really clarify what they are for.

We could also allow track the providers by managing optional resolution redirection to html human readable version of the entities in the w3id.org repo.

Case 1 :
I suppose this current implementation output is ok

https://skg-if-staging.cessda.eu/api/products?filter=identifiers.id:10.60686/t-fsd3217

• "https://datacatalogue.cessda.eu/detail/7e3c6fee8b0086785724ab698588433727629380e2ee04b7da1d34d94a0a82e4" resolves to a landing page, that I suppose should be very stable in an RDF context
• note : the @base is useful only to resolve the "FSD" scheme ( "FSD"is not in skg-if and will probably never be, it is a safe fallback that implementers will do without realizing it fixes the RDF )

Case 2 :
I suppose, we want to imagine implementers that may not rely on stable URL, but that would implement it in a more stable way.

{
 "@context": [
   "https://w3id.org/skg-if/context/1.1.0/skg-if.json",
   "https://w3id.org/skg-if/context/1.0.0/skg-if-api.json",
   {
     "@base": "https://w3id.org/skg-if/provider/cessda/"
   }
 ],
 "@graph": [
   {
     "local_identifier": "product_7e3c6fee8b0086785724ab698588433727629380e2ee04b7da1d34d94a0a82e4",
     "entity_type": "product",

or
"local_identifier": "https://w3id.org/skg-if/provider/cessda/product_7e3c6fee8b0086785724ab698588433727629380e2ee04b7da1d34d94a0a82e4",

• a redirection in w3id.org

https://w3id.org/skg-if/provider/cessda/product_{xx} => https://datacatalogue.cessda.eu/detail/{xx}

Promoting the case 2 implementation with human readable redirection would also clarify the base URL behaviour.

=> https://w3id.org/skg-if/provider/cessda/product_{xx} resolves to somewhere

• non RDF gurus understands what is happening.
• you really introduce stable PIDs in the graph
• SKG-IF w3id.org IRI behave like stable DOIs.

Request

• Could we rename our docs to https://w3id.org/skg-if/provider/<provider acronym>/
• Could we promote the redirection contribution by providers into w3id.org repo https://github.com/perma-id/w3id.org, via PR. So we can answer the classic question "RDF ok... but why are these URLs not going anywhere ? How to fix them ?"

[rduyme]

cc @essepuntato @andremann @menzowindhouwer @dgbroeder

[markusjt]

I find the sandbox term quite confusing in the URL, sandbox really sounds "not production ready"

I agree with this and provider sounds fine to me.

I commented on this implementation partly in the other issue but I could use a clarification: do you mean either of these cases would be fine to use or that everyone should follow the format introduced in Case 2 so it stays consistent across providers and across entities?

[rduyme]

@markusjt I understand your current implementation is perfectly fine. local_identifier is a URL and in RDF you are free to put what you want... It would be hard to validate all implementations so we need to give this RDF freedom, as discussed in skg-if/api#54

The syntax https://w3id.org/skg-if/provider/<provider acronym>/xxx is probably more flexible to manage on your side. You may share these ids with external systems and want them to be very stable. w3id.org provides this service. For example if you change a bit your www server domain/root_path https://datacatalogue.cessda.eu/detail/

But, let's wait for the RDF gurus feedback before touching your ids :-)

[dgbroeder]

sandbox URLs was introduced in https://raw.githubusercontent.com/skg-if/interoperability-framework/59432700247d1e311a28e0dc560a53da3ae023d3/index.md, and many examples. So I mentioned it specifically as one identifier format to be supported, but not to the exclusion of others, and having another name is the least of our worries We can recommend an additional set of recommendations on top of the SKG-IF model specifying redirection details of the indentifier URL. I would be in favour of listing such redirection behaviour (amongst others) of every SKG-IF in an additional registry.

[rduyme]

least of our worries

My worry is getting the skg-if framework pushing these kind of ids in the RDF semantic cloud
local_identifier:https://myserver/v1/mycatalog.php?prod=12345&display=full

There is a need to explain what are best practices for ids and how our w3id.org skg-if sub repo can help our users to create stable RDF IRIs.

• https://w3id.org/skg-if/sandbox/whitehouse/tax-rule-123456 vs https://w3id.org/skg-if/provider/whitehouse/tax-rule-123456
• https://doi.org/10.1038/1234 vs https://doi.org/sandbox/nature.com/10.1038/1234

We will have to manage redirection rule in our w3id.org sub repo, we want them clean, they may be shared and used :-)

[rduyme]

Hi Silvio, @essepuntato @andremann

What did you have in mind with the initial sandbox concept ?

I think suggesting resolvable human readable IRIs for entities to our users is a good practice.

• Option 1 : Do you think we should allow redirection setup in our w3id skg-if by implementers. This means managing the Pull Requests...
• Option 2 : if not option 1, why not removing any concept of "sandbox" and leave all implementers the responsibility to define the IRI with the base they want, on their own.
  • https://w3id.org/acme ( and not https://w3id.org/skg-if/sandbox/acme )
  • or any other @base URL they want...

The current OpenAIRE implementation looks like this https://api.openaire.eu/graph/swagger-ui/index.html?urls.primaryName=SKG-IF%20OpenAPI%20V1

{
  "@context": [
    "https://w3id.org/skg-if/context/1.1.0/skg-if.json",
    "https://w3id.org/skg-if/context/1.0.0/skg-if-api.json",
    {
      "@base": "https://api.openaire.eu/graph/"
    }

...
  "local_identifier": "otf___1772806165234___product",
    "entity_type": "product",
...

[essepuntato]

Hi @rduyme, all,

Apologies for the late reply on this. Let me clarify the purpose of the "sandbox" to better understand its meaning.

The main goal of using it is to provide a backup mechanism for defining URLs when the original source, which provides data compliant with SKG-IF, lacks a URL-like mechanism for defining local identifiers, but only provides string-like objects such as "09604536-bf60-4a77-b17c-4a6c40bf1087", and it is not interested in handling local identifiers URL internally. In that case, since we do need a URL always as a local identifier, the "sandbox" mechanism allows one to use the string-like identifier to define a valid URL on the fly, which is, indeed, a "non-production" URL, in the end, since it is not handled by the original source. In practice, the "sandbox" URL should be used when the source provider is not interested in managing the URL itself.

In principle, one could specify, as @base, any URL a source wants to use as base URL for its entities' local identifier, or define the sandbox anyway (just in case something is missing, as a backup mechanism) and then make explicit the full URL in the local identifier field, such as in here:

{
    "@context": [
        "https://w3id.org/skg-if/context/skg-if.json",
        {
            "@base": "https://w3id.org/skg-if/sandbox/oc/"
        }
    ],
    "@graph": [
        {
            "entity_type": "product",
            "local_identifier": "https://w3id.org/oc/meta/br/062501777134",
            "identifiers": [
        ...
    ]
}

In the case of the local identifier in the example above, @base is not practically used because the local_identifier field includes a full URL – but I would suggest to leave it in case, by mistake, only a local identifier of other entities is specified with a partial URL, which would have made the data incorrect without any @base specified.

An alternative approach would be to rewrite @base, as OpenAIRE does, since OpenAIRE is responsible for handling such identifiers. Honestly, being the otf___ ids something temporary, I would suggest to use the "sandbox" URL as an alternative, in particular if that URL does not resolve (as in the case of https://api.openaire.eu/graph/otf___1772806165234___product), thus expliciting the fact that the URL generated not only is temporary but lives in a "sandbox" environment. But I think this is a personal choice about the source.

Thus, I do not see any issue in allowing sources to specify any @base they want; but probably we should justify in the IF documentation when it is appropriate to do so (i.e. when the source takes responsibility of the handling of the URL, and thus returning something if that URL is put on a browser, for instance) or use the "sandbox" URL instead. The point is that if a user sees a URL with "sandbox" inside it, it may not have a lot of expectation about the correct functioning of such a URL, while if it is a "source-official" URL, the fact of returning an error in accessing the data behind that URL may mean that there is a problem. Thus, "sandbox" is there, in my opinion, just to prevent such expectations.

I hope this clarifies the overall argument about the use of the "sandbox" URLs. I'm happy to extend the SKG-IF documentation to explicitly reflect this function, if it clarifies the purposes better.

[rduyme]

@essepuntato Thanks Silvio, Based on you response.

I have the feeling it would be easier to not use any common in case of domain sandbox at all. It would mean each implementer is responsible for its SKG prefixes, without relying on the https://w3id.org/skg-if/ repo.
In the end, why mistakes or missing elements (like schemes see example in my initial comment ) should land on https://w3id.org/skg-if/ ?

• This would be easier to explain : any implementer is responsible for their local_identifers. They can easily create their own w3id sub repo if necessary. Each implementer can understand they are fully managing how all the stuff they output is resolved (or not).
• In terms of responsibilities it is probably easier to manage for everybody.
• I know, it is not mandatory to resolve IRI. But it is a best practice that really helps non RDF developers.

For OpenCitations it would be

{
    "@context": [
        "https://w3id.org/skg-if/context/skg-if.json",
        {
            "@base": "https://w3id.org/oc/" => no sandbox, opencitation can manage the fallback on their domain,
 if someone gets an URL with this base.
        }
    ],
    "@graph": [
        {
            "entity_type": "product",
            "local_identifier": "https://w3id.org/oc/meta/br/062501777134",
            "identifiers": [
        ...
    ]
}

This means

• https://api.openaire.eu/graph/otf___1772806165234___product => resolve on openaire.eu domain
• https://w3id.org/oc/mistake_foobar => resolves (or not) on opencitations.net but does not land in https://w3id.org/skg-if/ domain
• https://w3id.org/oc/meta/br/062501777134 => resolves on opencitations.net domain

At the moment https://w3id.org/skg-if/sandbox/acme/otf_xxx resolves to a 404 on domain https://skg-if.github.io/sandbox/acme/otf_xxx . This is not clean...

I really want to clarify this point. We see 2 implementations that do not need the sandbox at all.