Talk:Sandbox

From IHO Nautical Information Processing Working Group
Jump to navigation Jump to search

jens 15:18, 12 April 2014 (UTC)
SNPWG17 decided to make telecommunications complex. That based on the assumption that it would be necessary to provide more specific satellite service information like prefix of different sat services, areas on which specific access codes have to be used to connect tx and rx. The entries here are been made to discuss how it should look like and the possible effects on the current MPA and radio service application scheme.


It has to be considered if SRVHRS can somehow combined with this complex attribute. That would make after office hours number superfluous.

raphael 21:33, 5 May 2014 (UTC): how about generalizing communicationIdentityOutSideWorkingHours to an enumeration accessTime, operatingTimes, or access (?) with the following allowed values:
1: during usual working hours
2: out of usual working hours

This can be used in situations other than communications, and also used if we want to specify something is available or can be used both within and outside working hours.

Shorter camel case names would be better. Also, no one will be able to remember whether it is communications... or communication...

raphael 00:49, 8 May 2014 (UTC): The January 2014 S-101 DCEG defines both "web address" and "telephone number" attributes. More meat for the harmonization discussion.

raphael 01:33, 10 May 2014 (UTC): Let's re-organize CONDET address attributes into a new "address" complex attribute, that will allow multiple delivery addresses too.

ISO 19115:2014 defines class CI_Contact with many similarities to CONDET, and defines a CI_Address type with attributes similar to the CONDET physical/delivery address attributes. I think that is mostly a good idea.


jens 18:11, 12 May 2014 (UTC) I agree with both proposals, the accessTime idea and the idea to make CONDET a address complex attribute. For the latter, should we rename that too or should be proceed with CONDET?

raphael 03:40, 13 May 2014 (UTC): Proposed revised model of CONDET, figure below. I will replace attributes EMAILS and ADRNET with enumerants of telcomService if you insist but I think it would be overloading the concept, makes it difficult to define complex attribute telecommunications, and raises a question about modeling radio communications information with CALNAM and CALSGN attributes. Also ADRNET is a sub-attribute of complex attribute TXTCON.

Proposed CONDET model


Definitions: File:CONDET WIP.pdf
Suggestions or opinions about the methods used for making more compact diagrams are also invited. If I draw them using the "ordinary" conventions, either some boxes stretch three quarters of the page width, or we get tangles of "wiring diagrams".

jens 09:21, 14 May 2014 (UTC)At first, I like the new diagram very much. It is better to read and better to understand. In fact, I believe even people with no experience would be able to read this.

I think that ADRNET might have only one instance. That confirms your idea of having it still as an extra attribute. Regarding EMAILS I have a slightly different view. It could be that an organisation has several emails and we need to model more than one instance. Email is a data transfer. One can see it academic and say that digital phone is also data transfer but I think nobody would easily adopt that. Thus, I still believe that incorporating email might be a good idea.

draft association class detail page

ASSOCIATION CLASS

Association name: Permission Type

Acronym: PERMIS

Camel Case: PermissionType

Simple Attributes: CATREL [1..1]

Complex Attributes: none

Roles:

Source Target Navigability Remarks
Role name Feature or Info type Multiplicity Role name Feature or Info type Multiplicity
vslLocation InformationArea 0..* permission Applicability 0..* n/a
vslLocation (any feature) 0..* permission Applicability 0..* source → target


Definition:

Association class for associations describing whether the subsets of vessels determined by the ship characteristics specified in APPLIC may (or must, etc.) transit, enter, or use a feature.


References:

Remarks: No remarks

Justification:

Comments:


Jens Raphael Other
Y/N Y/N Y/N