Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

additional names for a centre #245

Open
bansp opened this issue Oct 24, 2023 · 9 comments
Open

additional names for a centre #245

bansp opened this issue Oct 24, 2023 · 9 comments
Assignees
Labels
priority SIS:centres centre-oriented part of the SIS SIS:functionality SIS:schemas document grammars for parts of the SIS DB
Milestone

Comments

@bansp
Copy link
Member

bansp commented Oct 24, 2023

We've already seen issues where a centre is called one name in the CLARIN network, another in Text+, and has a third name for other purposes (or there exist minute organisational differences perhaps not fully relevant from the point of view of the SIS).

The listing of TALAR in re3data is a nice example of several issues, notably of handling the naming differences:
https://www.re3data.org/repository/r3d100010152
image

Let us make it possible to use more than one name for a centre / repository. Let these names get qualified by optional attributes whose content is going to end up in brackets after the name. Hmm, or a loose attribute as above and a controlled @ri attribute, that could be used for the purpose of filtering...

One way or another, this is a schema + implementation ticket, so I am self-assigning it for the schema part and will switch to Eliza once I'm done.

@bansp bansp added SIS:functionality SIS:schemas document grammars for parts of the SIS DB SIS:centres centre-oriented part of the SIS labels Oct 24, 2023
@bansp bansp added this to the SIS v. 2.7.0 milestone Oct 24, 2023
@bansp bansp self-assigned this Oct 24, 2023
@bansp bansp added the priority label Oct 24, 2023
@bansp
Copy link
Member Author

bansp commented Oct 24, 2023

Prioritising for myself; it's a short job and it would be good to handle it asaP.

@bansp
Copy link
Member Author

bansp commented Oct 26, 2023

This is what we have there right now, it must have been a rather quick patch:

               <xs:element name="centre" maxOccurs="unbounded">
                    <xs:complexType mixed="true">
                        <xs:sequence>
                            <xs:element name="name" type="xs:string"/>
                            <xs:element ref="a"/>
                            <xs:element ref="nodeInfo"/>
                        </xs:sequence>
                        <xs:attribute name="id" type="xs:ID" use="required"/>
                        <xs:attribute name="deposition" type="xs:boolean" use="optional" default="false"/>
                    </xs:complexType>
                </xs:element>

I suggest to change "name" to "centreName", to make it more specific. I also suggest that <a> is misused here and should evolve.
Also, centreName should get the attributes @ri (restricted list) and a boolean @preferred that kicks in in the absence of @ri (the logic should be a bit more complex here, actually -- processing @ri, checking for @preferred among identical values for @ri, and falling back on @preferred alone only if no @ris are present -- right?).

@bansp
Copy link
Member Author

bansp commented Nov 14, 2023

Eliza says that a is probably not used at all.
Piotr will implement this for this milestone, but not before Eliza has a while to look at this ticket and comment.

@margaretha
Copy link
Collaborator

margaretha commented May 13, 2024

<a> is actually used to specify references to CLARIN centre pages. I agree we should change the element name. Maybe <link> like respStmt?

@ri attribute is rather ambiguous because we also have <ri> element in <nodeInfo>. Maybe @restricted ? It is also more understandable than acronyms.

@bansp
Copy link
Member Author

bansp commented May 13, 2024

In the suggestion, @ri is meant to hold a restricted list of RIs, and was intentionally named the same as <ri>. I'll have to look at it again anyway, now, because it's not super-clear to myself anymore, either...

@bansp
Copy link
Member Author

bansp commented May 13, 2024

OK, so the first step could be for me to change name to centreName -- as long as Eliza gives me green light for that.
In the same step, I would equip centreName with optional attributes @preferred (boolean) and @ri (a list).
And at this point, we could just see and discuss if we want to use that or have something else there. Is that more or less OK?

@bansp bansp modified the milestones: SIS v. 2.7.0, SIS v. 2.8.0 May 17, 2024
@bansp
Copy link
Member Author

bansp commented May 21, 2024

Just a remark for now: if we end up using <link> then something clever has to be done about the current annotation of <link>, which is RespStmt-specific. It is also not anyURI, which probably begs for a separate ticket...
We currently have three pointing elements in this schema: a, url, and link. Sigh.

@bansp
Copy link
Member Author

bansp commented Sep 19, 2024

Interim update (no, we're not done yet, it seems):

    <xs:element name="centre">
        <xs:complexType mixed="false">
            <xs:sequence>
                <xs:element name="name" type="xs:string">
                    <xs:annotation>
                        <xs:documentation>the full name of the centre</xs:documentation>
                    </xs:annotation>
                </xs:element>
                <xs:element ref="registryLink" minOccurs="1" maxOccurs="unbounded"/>
                <xs:element ref="nodeInfo"/>
            </xs:sequence>
            <xs:attribute name="id" type="xs:string" use="required">
                <xs:annotation>
                    <xs:documentation xml:lang="en">'shorthand' for the centre that acts as its ID</xs:documentation>
                </xs:annotation>
            </xs:attribute>
            <xs:attribute name="deposition" type="xs:boolean" use="optional" default="false"/>
        </xs:complexType>
    </xs:element>

So, name is still not centreName, and it has no attributes.
I will not change that right now in formats, because I want formats to be instantly mergeable for Eliza tomorrow.

So we need to coordinate on this change, and maybe actually postpone it till post-CAC -- we should restrict ourselves to fixes and cosmetics, for the time being. BUT let me add Eliza to the assignees, and let me drop the priority label.

@bansp
Copy link
Member Author

bansp commented Nov 7, 2024

Meeting decision: keep it in this milestone and try to handle it before the release. Piotr will prioritize it for himself.

@bansp bansp added the priority label Nov 7, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
priority SIS:centres centre-oriented part of the SIS SIS:functionality SIS:schemas document grammars for parts of the SIS DB
Projects
None yet
Development

No branches or pull requests

2 participants