Syntax for Compound

[Sveino]

How shall Compound be serilisased in CIMXML or CIMJSON-LD?

E.g.

[Sveino]

Principle does CIMXML (61970-552) does not support the serialization of Compound. There are no Compound in the 61970-package (with the exception of CIMdatatypes see issue #278 ) I am not sure how 61968-13 is handling this. In AutoFOS we only had the address as a issue. This was solved by a adding an extensions. To address this the WG has decided to remove all Compound. I am not sure I totally agree with this. However, we currently have compound inside a compound. This I cannot see the point of having. Other items like address is created as Compound - something that I think is incorrect. The other way is to create CIMJSON-LD that must support Compound. For CIMJSON-LD. We should follow the same way as datatype is serialization #278 .

For CIMXML we have three option:

1. Same principle as CIMSJON-LD
2. Link
3. Remove the the compound level

[Sveino]

Proposed model

[ThomasRanvikEriksen]

Example:

{
    "dig:Location.PhysicalAddress": {
        "@id": "urn.uuid:609870a4-1575-4f90-a4fc-d87d9c0e084a",
        "dig:IdentifiedObject.mRID": "609870a4-1575-4f90-a4fc-d87d9c0e084a",
        "dig:Address.country": "string",
        "dig:Address.streetNumber": "string",
        "dig:Address.streetAddress": "string",
        "dig:Address.postalCode": "string",
        "dig:Address.locality": "string",
        "dig:Address.region": "string",
        "dig:PhysicalAddress.streetSuffix": "string",
        "dig:PhysicalAddress.streetPrefix": "string",
        "dig:PhysicalAddress.district": "string",
        "dig:PhysicalAddress.municipality": "string",
        "dig:PhysicalAddress.city": "string",
        "dig:PhysicalAddress.globalLocationNumber": "string",
        "dig:PhysicalAddress.town": "string",
        "dig:PhysicalAddress.community": "string",
        "dig:PhysicalAddress.isicV4": "string",
        "dig:PhysicalAddress.isWithinTownLimits": "boolean",
        "dig:PhysicalAddress.nearestIntersection": "string"
}

[ThomasRanvikEriksen]

@Sveino

Location to PhysicalAddress is one to one?

[svenCal]

what about city, town, locality?

                "UsagePointLocation": {
                    "PhysicalAddress": {
                        "city": "SKIEN",
                        "postalCode": "3715",
                        "streetAddress": "Frognerlia",
                        "streetNumber": "0000 H0101"
                    },
                    "accessMethod": "Bolig"
                },

[ThomasRanvikEriksen]

@svenCal adjusted my example to include all attributes

[EmilieSkog]

The association Location.PostalAddress should be changed to Address.Location with a 0..* to 0..1 multiplicity

[Sveino]

Use nc namespace with nc-no as the Norwegian extension:

xmlns:nc-no="http://cim4.eu/ns/nc-no#"
xmlns:nc="http://cim4.eu/ns/nc#"

    "cim:IdentifiedObject.mRID": "609870a4-1575-4f90-a4fc-d87d9c0e084a",
    "nc-no:Address.country": "string",

use nc-no for extentions that is not yet adopted by CIM or NC. At one state the nc-no can be adaptet to CIM18. At this stage we can refer to this as xmlns:cim18="http://ucaiug.org/ns/CIM18#". When we then make CIM18 our standard xmlns:cim="http://ucaiug.org/ns/CIM#"

[Sveino]

I recommend to use the following model for Address and Location:

[Sveino]

The recommended linkaged between Location and addresss is:

[Sveino]

Emilie, Thomas, Svein: Agreed to: We would like to follow the recommendation by have the resource point to location (GPS) and Address. We will remove the two association that is tagged removed. In addition we would like to remove the Site to Physical address. In the case of cablebox (or any small electrical component) we will create an nc-no:Building (aligned with BuildingSmart) and add link to location and address. The address can in the description include the note that this is not really the address, but the closes address use for access.

Svein will create an updated model that shows the link from the Building (CableBox) to Asset and PowerSystemResource.