From d532d617eb793de6bda150879fa656c61e6fbfa0 Mon Sep 17 00:00:00 2001 From: Travis CI Date: Sat, 16 Nov 2024 14:25:58 -0800 Subject: [PATCH] add to migration guide --- .../src/main/version-migration.md | 24 +++++++++++-------- 1 file changed, 14 insertions(+), 10 deletions(-) diff --git a/io.opencaesar.oml.specification/src/main/version-migration.md b/io.opencaesar.oml.specification/src/main/version-migration.md index b9847031..218736b2 100644 --- a/io.opencaesar.oml.specification/src/main/version-migration.md +++ b/io.opencaesar.oml.specification/src/main/version-migration.md @@ -191,7 +191,7 @@ The OML syntax and APIs have significantly changed from v1 to v2. This section s ] -2. In v2 vocabularies, the `structure` type (which was used in v1 as a type for anonymous instances) has been removed and replaced by a simple `concept` in (which can have either named or anonymous instances). +1. In v2 vocabularies, the `structure` type (which was used in v1 as a type for anonymous instances) has been removed and replaced by a simple `concept` in (which can have either named or anonymous instances). Similarly, a `structured property` (which was typed by a `structure` in v1) has been removed and replaced by a simple `relation`. For example: @@ -201,6 +201,9 @@ The OML syntax and APIs have significantly changed from v1 to v2. This section s `concept` Point // used to be a structure `scalar` `property` x [ `domain` Point `range` xsd:int ] `scalar` `property` y [ `domain` Point `range` xsd:int ] + `concept` Shape + `relation` top-left [ `from` Shape `to` Point ] // used to be a structured property + `relation` bottom-right [ `from` Shape `to` Point ] // used to be a structured property In a description: @@ -208,12 +211,13 @@ The OML syntax and APIs have significantly changed from v1 to v2. This section s 
 	`instance` p1 : Point [ x 10 y 20] // named instance
 	`instance` s1 : Shape [
-		top-right : Point [ x 30 y 40 ] // anonymous instance
-		bottom-left [ x 90 y 100 ] // anonymous instance
+		top-left : Point [ x 30 y 40 ] // anonymous instance
+		bottom-right [ x 90 y 100 ] // anonymous instance
 	]
-3. In v2 vocabularies, a new (unreified) `relation` can now be specified as an alternative to a (refieid) `relation entity`. This supports cases where instances of the relation are not foreseen in descriptions. It also helps avoid synthesizing relation entity names when mapping vocabularies from other formats that do not natively support reified relations. The syntax of an unreified `relation` resembles closely that of a `relation entity` (except for the `forward` statement). The syntax of an unreieifed `relation` is (partially) as follows: + +2. In v2 vocabularies, a new (unreified) `relation` can now be specified as an alternative to a (refieid) `relation entity`. This supports cases where instances of the relation are not foreseen in descriptions. It also helps avoid synthesizing relation entity names when mapping vocabularies from other formats that do not natively support reified relations. The syntax of an unreified `relation` resembles closely that of a `relation entity` (except for the `forward` statement). The syntax of an unreieifed `relation` is (partially) as follows: 
 	Relation ::= `relation` NAME (`[`
@@ -241,9 +245,9 @@ The OML syntax and APIs have significantly changed from v1 to v2. This section s
 	]
-4. In v2 vocabularies, an unreified relation can now be referenced anywhere other relations (like `forward`, `reverse`) can. This includes restriction statements (`restricts REL_REF`), specialization statements (`< REL_REF`), equivalence statements (`= REL_REF`), rule predicates (`REL_REF(ARG1, ARG2)`), assertion axioms (`REL_REF TARGET_REF`), etc. Also, a relation is a kind of property in v2, whereas a relation entity is a kind of type. Therefore, a relation cannot be a supertype of a relation entity (and vice versa). But, an unreified relation can have any relation (including forward and reverse) as a super relstion. +3. In v2 vocabularies, an unreified relation can now be referenced anywhere other relations (like `forward`, `reverse`) can. This includes restriction statements (`restricts REL_REF`), specialization statements (`< REL_REF`), equivalence statements (`= REL_REF`), rule predicates (`REL_REF(ARG1, ARG2)`), assertion axioms (`REL_REF TARGET_REF`), etc. Also, a relation is a kind of property in v2, whereas a relation entity is a kind of type. Therefore, a relation cannot be a supertype of a relation entity (and vice versa). But, an unreified relation can have any relation (including forward and reverse) as a super relstion. -5. In v2 vocabularies, the `from` and `to` statements (of relations), as well as the `domain` and `range` statements (of properties), can now specify more than one type as a value (both on the original definition or on a `ref` of the member). The semantics of having multiple types is equivalent to the intersection of those types. This makes a value asserted as a subject (or object) of a property (or relation) to be classified by all the types at once. +4. In v2 vocabularies, the `from` and `to` statements (of relations), as well as the `domain` and `range` statements (of properties), can now specify more than one type as a value (both on the original definition or on a `ref` of the member). The semantics of having multiple types is equivalent to the intersection of those types. This makes a value asserted as a subject (or object) of a property (or relation) to be classified by all the types at once. For example: @@ -266,9 +270,9 @@ The OML syntax and APIs have significantly changed from v1 to v2. This section s ] -6. In v2 vocabularies, the symbol `^` separating rule predicates has changed to `&` to better reflect the AND semantics between predicates. +5. In v2 vocabularies, the symbol `^` separating rule predicates has changed to `&` to better reflect the AND semantics between predicates. -7. In v2 vocabularies, a new term `builtIn` has been added to define a builtin function that can be referenced by a rule antecedant predicate. A standard set of builtins has been added to the `core-vocabularies` library in the `` vocabulary. Note that a custom `builtIn` function cannot be specified yet. +6. In v2 vocabularies, a new term `builtIn` has been added to define a builtin function that can be referenced by a rule antecedant predicate. A standard set of builtins has been added to the `core-vocabularies` library in the `` vocabulary. Note that a custom `builtIn` function cannot be specified yet. 
 	 // in the "http://www.w3.org/2003/11/swrlb#" vocabulary
@@ -286,9 +290,9 @@ The OML syntax and APIs have significantly changed from v1 to v2. This section s
 	 ]
-8. In v2 descriptions, the symbol `ci` for a concept instance has now changed to the more readable `instance`. Also, such instances can also now be typed by both `Concepts` and `Aspects` (whereas only `Concepts` were the only valid types in v1). +7. In v2 descriptions, the symbol `ci` for a concept instance has now changed to the more readable `instance`. Also, such instances can also now be typed by both `Concepts` and `Aspects` (whereas only `Concepts` were the only valid types in v1). -9. In v2 descriptions, the symbol `ri` for a relation instance has now changed to the more readable `relation instance`. Also, such instances can also now be typed by both `Relation Entities` and `Aspects` (whereas only `Relation Entities` were the only valid types in v1). +8. In v2 descriptions, the symbol `ri` for a relation instance has now changed to the more readable `relation instance`. Also, such instances can also now be typed by both `Relation Entities` and `Aspects` (whereas only `Relation Entities` were the only valid types in v1). **API Changes**