E. g. In Composition the element date has the data type dateTime.
<Composition xmlns="http://hl7.org/fhir">
...
<date value="[dateTime]"/><!-- 1..1 Composition editing time § -->
...
Is it with a Profile possible that the element date also adapts another data type, for instance the data type date?
See http://hl7.org/fhir/2015May/structuredefinition.html#6.17.5.2
Under the bullet "In practice..." the specification states "the list of types for an element must be the same or a subset of the list of types for the same element in the base structure".
So, no, new types may not be introduced. In general, a Profile (StructureDefinition) can only further restrict the use/content of a resource. It may not loosen the standard.
Chris is correct - the type cannot change and new types cannot be added. So if the specification says dateTime, you can't use "string" instead. However, in this specific circumstance, you can communicate "just date" within dateTime. And you can assert constraints against the type. So in theory, you could assert a length constraint of 10 characters on dateTime, essentially making it a date. As well, there's no requirement in FHIR that you store everything that's sent to you. So it's legitimate to throw away any time information that is sent to you (see http://hl7.org/fhir/2015May/updates.html for more information).
As a rule, stripping the time would be better than outright rejecting instances that contain a time. However, even that option is going to be seen as unexpected/undesirable by many communication partners.
Related
I'm a C# programmer who just have found out the beauty of F# programming (thanks to the book Domain Modeling Made Functional). However, I surprised that I have not found examples of a common scenario: User has multiple options he can tick. For example, booking a hotel room you may want to have several extra options, like free Wifi, allergic room, pets allowed, free breakfast, free parking etc. How to model this? All the examples I have found have only two options to choose from: either opt1 or opt2, or both. That solution doesn't scale, though.
I found a solution, but I also need a solution for a harder case, where options may have parameter, like in the hotel room reservation example: Distance from city center (user can provide a value), Max prize per night etc. These are search options that user may tick if he wants, but if he ticks, he has to provide a required parameter for each ticked option.
Seeing as you want to have values associated with the different options, what I would do in your case would be to just use a record with multiple optional fields.
type Booking =
{
freeWifi: unit option
maxPricePerNight: decimal option
}
static member Empty =
{
freeWifi = None
maxPricePerNight = None
}
It may seem like extending this record would be a pain, but I don't think this would really be a case in any real life system. With things like the provided Empty member and pattern matching on individual record fields, you'd never really need to list all the fields outside the type definition.
You can see a more robust solution to this problem in CLI option parser Argu (using DU's and quotations to lookup option values by case name), but that's an overkill for the scenario you're handling.
I am putting my collection of some 13000 books in a mySQL database. Most of the copies I possess
can be identified uniquely by ISBN. I need to use this distinguishing code as a foreign key into
another database table.
However, quite a few of my books date from pre-ISBN ages. So for these, I am trying to devise a
scheme to uniquely assign a code, sort of like an SKU.
The code would be strictly for private use. It should have the important property that, when I
obtain a pre-ISBN publication, I could build the code from inspecting the work, and based on the
result search the database to see if I already have other copies in my possession.
Many years ago I think I saw a search scheme for some university(?) catalogue, where you could
perform a search of a title based on a concatenated string' (or code) that was made up of let's
say 8 letters from the title, and 4 from the author, and maybe some other data. For example,
to search 'The Nature of Space and Time' by Stephen Hawking and Roger Penrose you might perform
a search on the string 'Nature SHawk', being comprised of 8 characters from the title (omitting
non-filing words and stopwords) and 4 from the author(s).
I haven't been able to find any information on such scheme's, or whether or not such an approach
was standardized in any way.
Something along these lines could be made up of course, but I was wondering if people here have
heard of such schemes, of have ideas on how to come to a solution to this.
So keep in mind the important property of 'replicability': using the scheme, inspection of a pre-
ISBN dated work should --omitting very special or exclusive cases-- in general lead to a code
that can singly be used to subsequently determine if such a copy is already in the database.
Thank you for your time.
Just use the Title (add Author and Publisher as options) and a series id to produce a fake isbn. Take a look at fake_isbn.
NOTE: use the first digit as a series id but don't use 9!
Is possible to define a data property of a class as the number of individuals of another class, and this number is computed automatically.
There is no functionality for counting already available, far as I know.
It could be implemented for asserted axioms, but I don't think it can be guaranteed to work reliably. The open world assumption and the default non unique name assumption mean that it's impossible to say if there are unknown individuals or if any of the known individuals are sameAs each other.
I would like to know how I can prevent a duplicate entry (based on my own client/project definition of what that means-below), in an AppSheet mobile app connected to Google Sheets.
AppSheet talks alot about UNIQUEID() which they also encourage using and designating as the KEY field. row_number is another possibility.
This is fine for the KEY in the sense of its purpose is to be unique, meaningless, and uniquely identify a record, and relate to other tables.
However, it doesn't prevent a duplicate ("duplicate" again, as defined by my own client's business rules&process) from occurring. I mean, I assume the UniqueId() theoretically would, but that's abstract theory, because it would only produce unique ones anyway.
MY TABLE HAS THESE COLUMN: [FACILITY NUMBER] and [TIMESTAMP] (date and time of event). We consider it a duplicate event, and want to DISALLOW the adding of such a record to this table, if the 2nd record has the same DATE (time irrelevant), with the same FACILITY. (we just do one facility per day, ever).
In AppSheet how can I create some logic that disallows the add based on that criteria? I even basically know some ways I would do it. it just seems like I can't find a place to "put" it. I created an expression that perfectly evalutes to TRUE or FALSE and nothing else, (by referencing whether or not the FACILIY NUMBER on the new record being added is in a SLICE which I've defined as today's entries). I wanted to place this expression in another (random) field's VALIDIF. To me it seemed like that would meet the platform documentation. the other random field would be considered valid, only if the expression evaluated to true. but instead appsheet thought i wanted to conver the entire [other random column] to a dependent dropdown.
Please help! I will cry tears of joy when appsheet introduces FORM events and RECORD events that can be hooked into at the time of keying, saving, etc.
surprised to see this question here in stackoverflow --- most AppSheet questions are at http://community.appsheet.com.
The brief answer is that you are doing the right thing providing a Valid_If constraint. Your constraint is of the form IN([_THIS], ) so AppSheet is doing the "smart" thing by automatically converting that list into a dropdown of allowed values. From your post, it appears that you may instead want to say NOT(IN([_THIS], )) -- thereby saying that the value [_THIS] is valid as long as it is not in the list specified (making sure it is not a duplicate).
Old question, but in case someone stumbles upon the same:
The (not so simple) answer is given in https://help.appsheet.com/en/articles/961274-list-expressions-and-aggregates.
From the reference:
NOT(IN([_THIS], SELECT(Customers[State], NOT(IN([CustomerId],
LIST([_THISROW].[CustomerId])))))): when used as the Valid_If
condition for the State column, it ensures that every customer has a
unique value for State. In this example, we assume that CustomerId is
the key for the Customers table.
This could be written more schematic like this:
NOT(IN([_THIS], SELECT(<TableName>[<UnqiueColumnName>], NOT(IN([<KeyColumnName>], LIST([_THISROW].[<KeyColumnName>]))))))
Technically it says:
Get me a list of the current values of the column of the table
Ignore the value of the current row (identified by [_THISROW] and looking into the column)
Check, if the given value exists in the resulting list
This statement has to be defined - with the correct values for , & - as Valid_If statement.
The W3C TAG published the Working Draft URLs in Data Primer last month. It specifies a solution for the httpRange-14 issue.
Now vocabularies should specify categories for their properties, i.e. if a property applies to the document or to an entity described by the document.
How should/could RDF vocabularies specify the categories for properties today?
It says that metaformats (→ RDF) should specify a default category for properties and schema languages (→ RDFS) "should include mechanisms for indicating the category of a property". But I guess it will take some time until those specifications are updated.
Generally, I think that there is no such standardised method today, because right now you still need to differ between a thing and a document that holds a description of the thing. However, you may specify/create an owl:AnnotationProperty to indicate the type of a property in an RDF vocabulary.