search

erasmus-without-paper / ewp-specs-api-institutions

Specifications of EWP's Institutions API.
MIT License
0 stars 0 forks source link

Model-related comments on version 0.3.0 #8

Closed kaiqu closed 7 years ago

kaiqu commented 7 years ago

I have questions/comments concerning the following features from the model:

wrygiel commented 7 years ago

Other Id has a Type attribute (erasmus, euc-no, local)

Yes. To support different types of IDs. Is there something wrong with it?

Country is missing

Would it be a required element, or can it be optional? Is it possible that some HEIs span multiple countries (or they will, in the future)?

Description* (Lang) is missing

Can you explain the purpose of this element? What should it contain? Could you provide some example values?

I think personal and non-personal contacts should be structurally different

You may be right. This is one of the issues I have delayed on purpose, because I'm still thinking about it. On one hand, clients might simply display all the contacts to the viewer (in this case, having one abstract contact "view" might be enough). On the other hand, other clients might want to store them to their databases (in this case, we need more precise structure). We will come back to this.

kaiqu commented 7 years ago

Other Id has a Type attribute (erasmus, euc-no, local)

Yes. To support different types of IDs. Is there something wrong with it?

Sorry, I must have looked at the (XMLSpy) graphic representation of the XSD (I couldn't see the attribute, but I see it now in the textual representation).

Country is missing

Would it be a required element, or can it be optional? Is it possible that some HEIs span multiple countries (or they will, in the future)?

It should probably be optional, yes (I'll change the model).

Description* (Lang) is missing

Can you explain the purpose of this element? What should it contain? Could you provide some example values?

Actually, I think this is obviated by the HEI Information entity (fact sheets), so I'll remove it from the model.

I think personal and non-personal contacts should be structurally different

You may be right. This is one of the issues I have delayed on purpose, because I'm still thinking about it. On one hand, clients might simply display all the contacts to the viewer (in this case, having one abstract contact "view" might be enough). On the other hand, other clients might want to store them to their databases (in this case, we need more precise structure). We will come back to this.

Ok. Maybe an attribute could differentiate?

wrygiel commented 7 years ago

Ok. Maybe an attribute could differentiate?

It depends. If it turns out that this information has to be stored by the client in an actual PERSON table, then attribute might not be enough (we might need separate first name and last name fields).

kaiqu commented 7 years ago

The remaining unanswered question in this issue is whether (and in that case, how) personal and non-personal contacts should be structurally different.

In addition, I have the following questions:

In the model, Inst/Org Unit has a list of required language competences (Req Lang Comp*). I don't remember where I got this from, but since it's not present in either the Institutions or the OUnits API, I wonder if it's relevant at this level? (It's also in Cooperation Condition)

I also added a couple of optional fields from the dictionary, which maybe should be part of one or both APIs?

wrygiel commented 7 years ago

The remaining unanswered question in this issue is whether (and in that case, how) personal and non-personal contacts should be structurally different.

I hope I will be able to answer this definitely before the end of the month.

In the model, Inst/Org Unit has a list of required language competences (Req Lang Comp*). I don't remember where I got this from, but since it's not present in either the Institutions or the OUnits API, I wonder if it's relevant at this level? (It's also in Cooperation Condition)

Hmm... it seems to fit Courses API more? We already have an element with language of instruction there, this seems related.

City is already present in the address(es). Abbreviation - I have no opinion. Who had requested it?

kaiqu commented 7 years ago

In the model, Inst/Org Unit has a list of required language competences (Req Lang Comp*). I don't remember where I got this from, but since it's not present in either the Institutions or the OUnits API, I wonder if it's relevant at this level? (It's also in Cooperation Condition)

Hmm... it seems to fit Courses API more? We already have an element with language of instruction there, this seems related.

There are several language concepts floating around:

The following are from the dictionary. I bring them up because the author might have had some valid reason for putting them there (otherwise, I'm happy to drop them):

City is already present in the address(es).

Which depends on the address(es) being given (as they're optional). Is there a chance that an address is not given, but one wants to connect an institution/department to a city anyway?

Abbreviation - I have no opinion. Who had requested it?

No one, to my knowledge - I just picked it from the dictionary. If an institution (or even a department) has an internationally well-established acronym, it could serve as a visual aid?

wrygiel commented 7 years ago

Required language competence denotes a condition of some kind.

Okay, I understand now. However I can't currently see a place for this in Institutions API (nor Units API).

Is there a chance that an address is not given, but one wants to connect an institution/department to a city anyway?

I don't think so. Especially, since we have actually allowed the address to have any number of missing fields (it can, for example, have only a country and a city). In fact, I am now wondering, if perhaps we should drop the <country> element too, for similar reasons. Do you know who had requested these elements in the first place?

If an institution (or even a department) has an internationally well-established acronym, it could serve as a visual aid?

Okay, I will add it. Being well-established seems to be pretty subjective thing, though ;)

kaiqu commented 7 years ago

Required language competence denotes a condition of some kind.

Okay, I understand now. However I can't currently see a place for this in Institutions API (nor Units API).

Ok, then I'll remove it. (There are some related questions/comments in the dictionary as well)

Is there a chance that an address is not given, but one wants to connect an institution/department to a city anyway?

I don't think so. Especially, since we have actually allowed the address to have any number of missing fields (it can, for example, have only a country and a city). In fact, I am now wondering, if perhaps we should drop the "country" element too, for similar reasons.

Which we have done in the OUnits issue already :-)

kaiqu commented 7 years ago

Continuing the last remaining discussion elsewhere.