I am trying to add to "Equivalent To"
Patient and (hasSmokerStatus some xsd:boolean [= "true"])
however I cannot add it as I got error in xsd:boolean.
I tried
Patient and (hasSmokerStatus some xsd:boolean ["true"])
I tried all that with and without quotes, as well as
Patient and (hasSmokerStatus some "true"^^xsd:boolean)
but nothing works.
How can I use boolean in the "Equivalent To"?
Your idea is to adapt datatype restrictions (7.5) to boolean values. However, no constraining facet is normative for this datatype (4.4). Instead, you need enumerations of literals
(7.4). In Protégé:
Patient that hasSmokerStatus some {true}
Data property existential restrictions (8.4.2) with single-value data ranges could be replaced with literal value restrictions (8.4.3). In Protégé:
Patient that hasSmokerStatus value true
Related
What's the meaning of the frozen keyword in Cassandra?
I'm trying to read this documentation page: Using a user-defined type, but their explanation for the frozen keyword (which they use in their examples) is not clear enough for me:
To support future capabilities, a column definition of a user-defined
or tuple type requires the frozen keyword. Cassandra serializes a
frozen value having multiple components into a single value. For
examples and usage information, see "Using a user-defined type",
"Tuple type", and Collection type.
I haven't found any other definition or a clear explanation for that in the net.
In Cassandra if you define UDT or Collection as frozen, you can't update UDT's or collection's individual item, you have to reinsert with full value.
A frozen value serializes multiple components into a single value. Non-frozen types allow updates to individual fields. Cassandra treats the value of a frozen type as a blob. The entire value must be overwritten.
Source : https://docs.datastax.com/en/cql/3.1/cql/cql_reference/collection_type_r.html
#Alon : "Long story short: frozen = immutable"
For a user-defined type, I have noticed that you can update frozen the set by adding or removing the set elements. For example, let's say we create a table as follows.
create type rule_option_udt(display text, code text);
create TABLE rules (key text, options set<frozen<rule_option_udt>>, primary key (key));
As per the definition we expect that we won't be able to use + or - operation with the options field. But you can use add or remove operation as a normal set.
insert into rules (key, options) values ('fruits', {{display: 'Apple', code: 'apple'}}) ;
update rules set options = options + {{display: 'Orange', code: 'orange'}};
The above update is valid but you can't do the same with simple types such as text. I am not sure if this is expected nature or not but this is how it works for me.
In addition to this <frozen<set<udt>> && set<frozen<udt>> are behaving in the same manner. While describing the table you can see both are being shown as set<frozen<udt>>
I'm trying to model a schema where a list can have many items and each item can belong to many lists. It's clear to me that I can have a :list/items ref type to model the relationship, but I'd like to also have a rank attribute which determines an item's position in each list where it exists. How might one do such a thing?
The only answer I have - assuming that positioning is list dependent - is that you need to add an indirecting entity with a rank attribute. This isn't very pleasant. It would be nice if a many relation could be ordered, as this use case would simplify substantially.
Heterogenous tuples, added in June 2019, are a new modelling option here.
An attribute value, i.e. the v in the eavto 5-tuple, can now itself be a tuple. This is a clojure vector of max length 8.
Official blog post announcement.
Discussion of the release on twitter.
Note the example in the docs above uses
:db/tupleTypes [:db.type/long :db.type/long]
which is a little strange as the point is heterogenous tuples, so in the case of the OP this would be:
{:db/ident :list/item
:db/valueType :db.type/tuple
:db/tupleTypes [:db.type/ref :db.type/long] ; ref to item, rank
:db/cardinality :db.cardinality/many}
Or you could use a value type instead of a ref for item, if that works for you.
To use this in datalog, you can use the tuple and untuple functions.
I think I am going crazy! I have followed the various tutorials for Owl and Protege and still cannot figure out the answer. Use case is simple. I have defined a class called ‘Person’. I have defined a data property called hasFirstName. I have added a ‘subclass of’ restriction to Person like this : ‘hasFirstName exactly 1 string’. I have also added an individual called Alex of type Person, and have not added the hasFirstName property. I expect the reasoner to complain as I have specified the cardinality of 1, and asserted that Alex is a Person, but have not added the property value to Alex individual, yet the reasoner does not complain. If however I add two statements e.g. hasFirstName ‘Alex’ and hasFirstName ‘John’ then I get a complain. What I am doing wrong? Any help will be most appreciated, thanks.
There's no inconsistency in the first case. OWL makes the open world assumption, which means that something being unknown is different from it being known to be true or known to be false. Your username, at the time I'm writing this answer is user3552593. I'm relatively confident that you have a name, and that's not inconsistent with the fact that I don't know what it is yet.
By saying that
Person ⊑ =1 hasFirstName.String
and that
Alex : Person
you can infer that
Alex : =1 hasFirstName.String
There's nothing inconsistent with that; Alex, by virtue of Alex's personhood, has exactly one first name—we just don't know what it is yet.
I have an Article type structured like this:
type Article struct {
Title string
Content string `datastore:",noindex"`
}
In an administrative portion of my site, I list all of my Articles. The only property I need in order to display this list is Title; grabbing the content of the article seems wasteful. So I use a projection query:
q := datastore.NewQuery("Article").Project("Title")
Everything works as expected so far. Now I decide I'd like to add two fields to Article so that some articles can be unlisted in the public article list and/or unviewable when access is attempted. Understanding the datastore to be schema-less, I think this might be very simple. I add the two new fields to Article:
type Article struct {
Title string
Content string `datastore:",noindex"`
Unlisted bool
Unviewable bool
}
I also add them to the projection query, since I want to indicate in the administrative article list when an article is publicly unlisted and/or unviewable:
q := datastore.NewQuery("Article").Project("Title", "Unlisted", "Unviewable")
Unfortunately, this only returns entries that have explicitly included Unlisted and Unviewable when Put into the datastore.
My workaround for now is to simply stop using a projection query:
q := datastore.NewQuery("Article")
All entries are returned, and the entries that never set Unlisted or Unviewable have them set to their zero value as expected. The downside is that the article content is being passed around needlessly.
In this case, that compromise isn't terrible, but I expect similar situations to arise in the future, and it could be a big deal not being able to use projection queries. Projections queries and adding new properties to datastore entries seem like they're not fitting together well. I want to make sure I'm not misunderstanding something or missing the correct way to do things.
It's not clear to me from the documentation that projection queries should behave this way (ignoring entries that don't have the projected properties rather than including them with zero values). Is this the intended behavior?
Are the only options in scenarios like this (adding new fields to structs / properties to entries) to either forgo projection queries or run some kind of "schema migration", Getting all entries and then Puting them back, so they now have zero-valued properties and can be projected?
Projection queries source the data for fields from the indexes not the entity, when you have added new properties pre-existing records do not appear in those indexes you are performing the project query on. They will need to be re-indexed.
You are asking for those specific properties and they don't exist hence the current behaviour.
You should probably think of a projection query as a request for entities with a value in a requested index in addition to any filter you place on a query.
In OWL, is it possible to query a class that does not have a property?
Suppose I have an object property R and I want to retrieve all classes that do not have the property R. Also, suppose that I have already closed all classes with closures.
I was trying this:
suppose the propety in question is hasProperty, my query was this
hasProperty only Nothing
But it doesn't work
What do you mean by "class that does not have a property"?
Semantically, a class is a set of individuals and a property is a set of pairs of individuals. Given these two sets, what do you mean by "class has / has not a property"?
Regarding your example query
hasProperty only Nothing
lets rewrite it a bit so that we can think about it in natural language. This gives better intuition about the meaning of this query.
First lets rename hasProperty to follows (or whatever English verb), then we have:
follows only Nothing
This is semantically equivalent to
follows only (not Thing)
which is semantically equivalent to
not (follows some Thing)
Now we have gotten rid of the only which is a confusing part of OWL and is better avoided. So now we can verbalize the query in English as:
those who do not follow anything
or
who does not follow anything?
or more formally
which individuals of the ontology are known
not to have a follow relationship to any other individual
E.g. if your ontology states that
John does not follow Mary.
John does not follow himself.
Every individual in the ontology is either John or is Mary.
then John will be the answer to the above query.
You can also get a named class as the query answer if the asked restriction holds for a (named) group of individuals. In any case, the following must hold: if you asserted that the answer (or a member of it) does have a follow-relation to some individual then it would render the ontology inconsistent.
OWL does not have any means for querying the data. SPARQL is used for that. So the SPARQL query to find all class definitions that do not have the property :R would be:
SELECT ?cls
WHERE {
?cls a owl:Class .
FILTER NOT EXISTS {?cls :R ?o}
}