we should not be obfuscating globally identifiable things by inserting blank nodes for those

[mpo-vliz]

https://github.com/emo-bon/observatory-bpns-crate/blob/0ff7aec7be638cb15753f52022ad2a6be71723e2/extra-metadata.json#L284-L302

this snippet shows how some entities with global identifiers are being obfuscated with local identifiers.

Yes those global URI still get referenced and linked to, but they are moved to a secondary descriptive role.

The downside of this is that after feeding into a triple store very little queries will be considering that items associated to a Person or Organization will only be retrievable via the schema:identifier property path (and not directly to its orcid or ror)

This would less be the case if sameAs was used (and then preferable the one in owl, not the one in schema) as some triple stores support using these alias in queries.

Still better IMHO is to use the URI directly and not use these _:localname -- and yeah, I know it kills readability

[kmexter]

can you include an example here of how it should be done - easier for @cymon to change then

[mpo-vliz]

Actually, we are preparing separate communication to @cymon via recent document in context of FE devcycle 5 (link shared)

Also, this issue is more about our own usage in the already existing observatory repos (see link) we are doing ourselves.
And I think you (assigned peeps) are best aware of where this pattern has been applied already?

Anyway, let me be more explicit (but not extensive) on the kind of changes I propose:

change references to use public identifiers:

-- so from

    {"@id":"_:VLIZ"},
    {"@id":"_:KlaasD"}

-- to resp.

     {  "@id":"https://ror.org/0496vr396" },    # to discuss in context of emobon: but I prefer ror.org over seadatanet ?
     {  "@id":"https://orcid.org/0000-0002-8559-3508" },

change the descriptions of those entities accordingly:

... and properly use @id when linking to other entities --> see affiliation!

-- so from

    {
        "@id":"_:KlaasD",
        "@type": "Person", 
        "name": "Klaas Deneudt",
        "email": "[email protected]",
        "identifier": "https://orcid.org/0000-0002-8559-3508",
        "affiliation": "_:VLIZ"
    },
    {
        "@id":"_:VLIZ",
        "@type":"Organization",
        "name":"Flanders Marine Institute",
        "identifier":"https://edmo.seadatanet.org/report/422",
        "url":"https://www.vliz.be/en"
    },

-- to resp.

    {
        "@id":"https://orcid.org/0000-0002-8559-3508",
        "@type": "Person", 
        "name": "Klaas Deneudt",
        "email": "[email protected]",
        "affiliation": {"@id": "https://ror.org/0496vr396"}
    },

    {
        "@id":"https://ror.org/0496vr396",
        "@type":"Organization",
        "name":"Flanders Marine Institute",
        "owl:sameAs":"https://edmo.seadatanet.org/report/422",  
        "url":"https://www.vliz.be/en"
    },

Note: for the owl:sameAs to work, one has to add the owl-context-declaration -- I am totally ok if we remove that line, and just decide on using either ror or seadatanet-edmo

fix connection for opsci to vliz

while at it, I noticed the opsci org created here should be properly connected to VLIZ -- the @id usage is essential here too

Note: since this opsci org has no public identifier (and does not need one), the local node id can actually be kept:

-- so from

    {
        "@id":"_:OpSci",
        "@type":"Organization",
        "parentOrganization":"_:VLIZ",
        "email":"[email protected]"
    },

-- to resp.

    {
        "@id":"_:OpSci",
        "@type":"Organization",
        "parentOrganization": {"@id": "https://ror.org/0496vr396"},
        "email":"[email protected]"
    },

[kmexter]

woops, sorry, I didn't see that this was a comment in the BPNS crate, not the MFG one :-D

I do think this should be in a different repo (https://github.com/emo-bon/rocrate-metadata-generator-action/issues) because this applies to all crates, not just BPNS and it is otherwise very hard to find issues in GH. That is where I am putting issues that need to be resolved for ro-crates. Can we move this?

[marc-portier]

@kmexter, yes -- moved via "transfer issue" in right panel -- old link should still work and redirect

[laurianvm]

can we agree on approach in case no external identifier is available?
(e.g. _: with name in camelcase & no use of whitespace)

[mpo-vliz]

surely no whitespace -- anything after the _: needs to be urlencoded (e.g. check with https://www.urlencoder.org/)