Re: [niso-sts] Conditional expressions, units of measure and boolean operators

["Imsieke, Gerrit, le-tex gerrit.imsieke@xxxxxxxxx" <niso-sts-list-service@xxxxxxxxxxxxxxxxxxxxxx>]

Hi Doro,

<named-content> is appropriate, at least for the time being.

I already noted btagging of requirementsb as an item for the next 
iteration of NISO STS. We need to gather requirements for these 
requirements though, so it would be beneficial if you were able to 
obtain and share examples from real standards.

You can check the adequacy of your tagging by emulating how you would 
extract the tagged information for the target use case, probably some 
search or otherwise interactive application.

A minor thing that you need to consider is that you wonbt be able to 
link to other standards (as per our recent discussion on this list) from 
within named-content, at least if you buy into the blinks to other 
standards should be encoded using <std>b doctrine. I think not allowing 
<std> there is just an oversight; when we allow external linking 
elements in named-content and styled-content, we should include <std> as 
an external linking element. The necessity to link to another standard 
might not arise in small named-content phrases such as quantities and 
units. It may, however, well arise in more extensive phrases such as 
conditional statements (bif this material complies with ISO 12345-6, 
then b&b).

I wouldnbt call bifb a Boolean operator, I would rather call the whole 
statement a conditional statement and mark up the whole condition (bif 
the sun is shiningb) and the consequence (btemperature > 20 B0Cb) as such.
Ibd call bandb or borb Boolean operators that can combine other 
conditional statements.
It should be clear for an extraction tool which two predicates such an 
operator pertains to, so the formal relationship between these clauses 
should somehow also be encoded. Maybe by nested <named-content> elements.

You should also consider that content will inevitably become less 
human-readable if it is marked up with many, potentially nested, 
<named-content>s with all kinds of vocab attributes. I donbt have an 
immediate remedy for this though.

Although it is not available in STS right now, you can think about how 
youbd encode the same info using RDFa instead of named-content or even 
introduce a parallel formalized encoding of the requirements using RDF 
or OWL. These alternative formalized modelings are a bit like 
element-citation vs. mixed-citation or TBX vs. term-display (in their 
respective fields, citations and terminology).

I think it is important to explore whether everything, although maybe a 
bit clumsy or ad-hoc, may be expressed as named-content; or whether some 
automatic reasoning or whatever the intended application should perform 
depends on a more formalized modeling that cannot be superimposed on the 
requirement prose.

In any case, if you play through the modeling b extraction b application 
scenarios, you should get a good feeling for the adequacy of your 
concepts. And if you share your findings, it will inform the future 
directions of STS in this important area.

Gerrit


On 19/04/2018 12:44, DorothC)e Stadler doro@xxxxxxxxxxx wrote:
> Hello NISO community,
> Itbs me again with yet another question.
>
> In our national standards, we have a lot of requirements expressed that 
> can be considered conditional expressions, for example: "If the sun is 
> shining then temperature shall be >20B0C.b
>
> In this expression, bIfb and bthenb are boolean operators.
> bSunb is considered a parameter, the parameter value being bshiningb.
> bTemperatureb is also a parameter, the parameter value being b>20B0Cb.
> B0C is a unit of measure.
>
> The business would like to mark up the boolean operators separately, and 
> also the parameters and their values and their units of measure. I did 
> not find anything specific inside NISO so I have constructed a model 
> using <named-content> (which is starting to become my favourite tag of all).
>
> What do you think of the following:
> *Boolean operators:*
> <named-content content-type=boperatorb vocab=bbooleanb vocab-term=bIfb>
>
> *Units of measure:*
> <named-content content-type=bunitb vocab=bunitb vocal-term=bB0Cb>
>
> *Parameters:*
> For the name of the parameter: <named-content content-type=bparam-nameb 
> vocab=bparamb vocab-term=bSunb>Sun</named-content>
> For the value of the parameter: <named-content 
> content-type=bparam-valueb vocab=bparamb> shining </named-content>
>
> Can anyone see a better way of doing this apart from using named-content?
>
> Btw, the whole expression would be marked-up as a requirement (again 
> with named-content): <named-content content-type=brequirementb 
> vocab=bshallb>
>
> Thanks for your feedback and insights,
> Best Regards from sunny Berlin
> DorothC)e
>
> ---------------------------------------------
> DorothC)e Stadler
>
> Rathenower Str. 38
> 10559 Berlin
> Tel: +49 1525 840 85 93
> doro@xxxxxxxxxxx <mailto:doro@xxxxxxxxxxx>
>
>
>
> You are subscribed as gerrit.imsieke@xxxxxxxxx to NISO STS Discussion by 
> Mulberry Technologies, Inc. <http://www.mulberrytech.com/>
> EasyUnsubscribe 
> <-sts-list/225679> (by email 
> <>)

--
Gerrit Imsieke
GeschC$ftsfC<hrer / Managing Director
le-tex publishing services GmbH
Weissenfelser Str. 84, 04229 Leipzig, Germany
Phone +49 341 355356 110, Fax +49 341 355356 510
gerrit.imsieke@xxxxxxxxx, http://www.le-tex.de

Registergericht / Commercial Register: Amtsgericht Leipzig
Registernummer / Registration Number: HRB 24930

GeschC$ftsfC<hrer / Managing Directors:
Gerrit Imsieke, Svea Jelonek, Thomas Schmidt