Model-related comments on version 0.3.0

[kaiqu]

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

• Other Id has a Type attribute (erasmus, euc-no, local)
• Country is missing
• Description* (Lang) is missing
• I think personal and non-personal contacts should be structurally different:
  • Personal contacts correspond to Coordinator in the model, and include information from Person
  • Non-personal contacts correspond to HEI Information in the model (making them conceptually a kind of fact sheet)

[wrygiel]

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]

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]

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]

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?

• Abbreviation
• City* (Lang)

[wrygiel]

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]

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:

• Required language competence denotes a condition of some kind. It definitely belongs in Cooperation Condition (IIAs API), but I think I saw some documentation/discussion somewhere which seemed to indicate that it was wanted on the Inst/Org Unit Level as well. If not, I'm happy to remove it.
• (Actual) language competence is in Mobility (Mobilities API), denoting the person's knowledge of that language.
• Language of instruction is in LOI, and belongs in the Courses API, yes.

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]

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]

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]

Continuing the last remaining discussion elsewhere.