[semantic-web] <none>

Hi Hugh,

 

First of all our domain is a process plant, and all plant items are declared
and get their UUID and a label.

These are stored in the consolidating triple store of the plant.

 

Then comes a project to revamp, or to extend the plant with a new unit. In
most cases that is handled by a so-called EPC contractor (EPC = Engineering
Procurement, Construction).

In the case of a revamp the plant owner must share the relevant data about
the existing situation. Ideally this is done by federation, leaving that
information under the control of the plant owner since that plant is still
in operation for the, say, two years that such a revamp takes (which makes
it an update of a moving target).

 

In either case the EPC contractor starts to design the new situation, as the
design part of a Digital Twin (to be: DTs are making inroads in this field,
Messrs Aveva, for instance, are designing a new one based on ISO 15926. At
least that is what they told us). Once the design is finished, the
procurement has been done, and the plant has been constructed the contractor
hands over the design & engineering information to the plant owner. It is
this rather complex use case that triggered the development of ISO 15926,
also because plant owners and EPC contractors have a 'promiscuous'
relationship in most cases, causing endless interfacing.

 

Now to your questions:

[HG] How do you manage the UUIDs?

[HT] The issue of UUIDs is not managed because the chances of double
occurrence of a UUID is, for all practical purposes, zero. I read: '128-bits
is big enough and the generation algorithm is unique enough that if
1,000,000,000 GUIDs per second were generated for 1 year the probability of
a duplicate would be only 50%.'. On top of that they are residing in an
endpoint of which there are also a gazillion. I use this generator
<https://www.guidgenerator.com/online-guid-generator.aspx> , but undoubtedly
there are more of those.

 

[HG] For example, when you start to use data from a new DB, do you modify it
to re-write the primary keys (or whatever) to the UUID?

[HT] In the treatise I sent to you on Feb. 15th you can read that we intend
to map the data of all applications that are used in the context of a plant
to ISO 15926-8 in Turtle. In those apps the identifiers (tag numbers) are
those dictated by the plant owner. When mapped a check is made by the
software to see if that identifier already exists. If not, the technical
discipline involved must decide what to do. But that is exceptional, unless
the users of the app spelled the identifier incorrectly. In the little
diagram I sent an in-between triple store is shown where the responsible
discipline can correct or ignore or transfer the triples to the
consolidating triple store. Because of the uniqueness of the UUIDs that
transfer can basically be done by changing the endpoint of it during the
transfer.

 

[HG] Or do you add the UUID to the DB, with an internal mapping table to the
keys, and then modify everyones existing queries to include the UUIDs?

[HT] The mapping between identifier and UUID is in the declaration, e.g.:

 

ex:847931fd-eade-4beb-b07d-a9e889611c19 

            rdf:type lci:InanimatePhysicalObject, dm:WholeLifeIndividual,
dm: ActualIndiidual, rdl:RDS414674 <http://data.15926.org/rdl/RDS414674>  ;
# VESSEL

            rdfs:label "HG-ey37" ;

            meta:valEffectiveDate "2021-04-13T15:29:00Z"^^xsd:dateTime .

 

That mapping is used to fetch the UUID for a human-readable label. When an
object has more labels, such as serial number, asset number, maintenance
number, etc, each identification is covered by a template instance, for
example:

 

ex:763c75da-97c1-4b4e-b699-cf616c7c7a5d

      rdf:type tpl:ClassifiedIdentificationOfIndividual

      rdfs:label "[VESSEL] individual [HG-ey37] has an [IDENTIFICATION BY
ASSET NUMBER] [AN-45348832]"@en ; # storage of this label is optional - it
could be generated on the fly

      tpl:hasIdentified ex:847931fd-eade-4beb-b07d-a9e889611c19  ; # HG-ey37

      tpl:hasIdentifier "AN-45348832" ;

      tpl:hasIdentificationType rdl:RDS2221102  ; # IDENTIFICATION BY ASSET
NUMBER

      meta:valEffectiveDate "2021-09-21T10:24:00Z"^^xsd:dateTime .

 

Please note that templates are representing elementary, autonomous,
information chunks, not the object(s) where the information is about.
Actually an elementary KG.

 

[HG] Or is there some wrapping layer around it somehow?

[HT] No

 

[HG] How do you make your UUIDs discoverable, in particular in relation to
external IDs that come from different DBs?

[HT] In addition to what I wrote above, our Reference Data Library has
extensions for a number of standardization bodies, like ASTM, ASME, DIN, BS,
IEC, etc. What we do is assigning our own number and making reference to a
particular standard class. For instance:

 

Transmitter

id                                 http://data.15926.org/iec/ABA880

rdfs:label                     Transmitter

skos:definition             A <Transmitter> is a <Measuring instrument
component> and a <PROCESS VARIABLE TRANSMITTER> that 

accepts a process variable and converts it according to a definite law into
a standardized output signal.

owl:sameAs
https://cdd.iec.ch/cdd/iec61987/iec61987.nsf/TU0/0112-2---61987%23ABA880

meta:valEffectiveDate 2021-10-03Z

rdf:type                       ClassOfFunctionalObject

rdfs:subClassOf         Measuring instrument component

rdfs:subClassOf         PROCESS VARIABLE TRANSMITTER

 

In other cases, where the standardization body has no endpoint, we just
refer to a standard, such as:

 

FLANGED END RING JOINT ASME B16.5 CLASS 2500 NPS 10

id                                 http://data.15926.org/asme/RDS730304

rdfs:label                     FLANGED END RING JOINT ASME B16.5 CLASS 2500
NPS 10

rdf:type                       ClassOfFeature

rdfs:subClassOf         FLANGED END RING JOINT ASME B16.5

rdfs:subClassOf         FLANGED END ASME B16.5 CLASS 2500 NPS 10

skos:definition A         <FLANGED END RING JOINT ASME B16.5 CLASS 2500 NPS
10> is a <FLANGED END ASME B16.5 CLASS 2500 NPS 10
<http://data.15926.org/asme/RDS12152935> > 

and a <FLANGED END RING JOINT ASME B16.5
<http://data.15926.org/asme/RDS11482293> > conforming to the specification
for Class 2500, NPS 10

 

You see: small questions - large answers.

 

Regards, Hans 

15926.org <https://15926.org/home/> 

 

PS This presentation may interest you:
https://www.youtube.com/watch?v=tRGHBYsz2KM  It describes the next step
after ISO 15926: the CDBB Project in the UK: https://www.cdbb.cam.ac.uk/ 

--------------------------__________________________________________________
_______________________________________________________________________


From: Hugh Glaser <hugh@glasers.org> 
Sent: donderdag 17 februari 2022 20:09
To: hans.teijgeler@quicknet.nl
Cc: Matthew Lange <matthew@ic-foods.org>; Semantic Web <semantic-web@w3.org>
Subject: Re: EasierRDF

 

By the way, how do you manage the UUIDs?

For example, when you start to use data from a new DB, do you modify it to
re-write the primary keys (or whatever) to the UUID?

Or do you add the UUID to the DB, with an internal mapping table to the
keys, and then modify everyones existing queries to include the UUIDs?

Or is there some wrapping layer around it somehow?

How do you make your UUIDs discoverable, in particular in relation to
external IDs that come from different DBs?

 

Or maybe I am thinking of a different world.

Cheers

 

> On 17 Feb 2022, at 14:03, < <mailto:hans.teijgeler@quicknet.nl>
hans.teijgeler@quicknet.nl> < <mailto:hans.teijgeler@quicknet.nl>
hans.teijgeler@quicknet.nl> wrote:

> 

> Hi Hugh,

> 

> We use UUIDs, because of the long period in time and the many contributors
of life-cycle information.

> Next to the UUID we use rdfs:label for easy access. Label can change, the
UUID stays lifelong.

> 

> Regards, Hans