You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'd try what happens in the example Gian gave of an RDF model where Animals have legs, and we classify Animals into Monoped, Biped and Quadruped based on the number of legs they have. Try doing this:
Monoped.all.println();
Biped.all.println();
Quadruped.all.println();
for (a in Animal.all) {
a.legs.println('Animal ' + a + ' legs: ');
}
(If you need an example of a Monoped, we could try limpets.)
This actually creates an interesting scenario, where we may be getting a single value from Monoped (since there will be a restriction that they have one leg), but in theory we'd still want a list. It does mean that while MOF2RDF-based RDF graphs would work with our idea of seeing if a restriction was imposed (in terms of producing equivalent query results), in the general case of RDF graphs you may not always want this behaviour.
If the Monoped example turns out to work in that way, we should create a backlog item to split things into two:
A base RDFModel class without MOF2RDF awareness.
An MOF2RDFModel subclass with added awareness of the mapping.
We would expose MOF2RDFModel as a separate "MOF2RDF Model" type, so the user would explicitly say if they want to apply the MOF2RDF encoding or not.
The text was updated successfully, but these errors were encountered:
OwenR-York
changed the title
Using an invalid RDF model as an example could create confusion in users, and did prompt a very interesting discussion :-D. I'd change this model to be valid (removing the extra motherboards), and I'd only introduce an invalid model as an example of how the Jena-based validation works when we work in #20. In any case, Gian commented that the Semantic Web community doesn't like to abuse OWL for validation, and instead constraint languages like SHACL would be more appropriate.
Create animal RDF Model
Jan 17, 2025
Dimitris noted today that this example, while interesting as a thought experiment in terms of the capabilities of RDFS+OWL vs those of MOF, would not clearly map to something that came from EMF/MOF so it should not impact our approach around supporting the MOF2RDF conventions in #15.
If we think in terms of Ecore metamodels written in Emfatic, Option 1 would be this:
class Animal {
val Leg[*] legs;
}
class Monoped extends Animal {}
class Biped extends Animal {}
class Quadruped extends Animal {}
In Option 1, you'd have to enforce the right number of legs via other constraints (e.g. an EVL script). MOF2RDF would therefore not produce maxCardinality constraints for the Animal subclasses, and we'd always return collections for the legs of any Animal.
Option 2 would be this, which would allow EMF to enforce the cardinality constraints:
class Animal {}
class Monoped extends Animal {
val Leg leg;
}
class Biped extends Animal {
val Leg[2] legs;
}
class Quadruped extends Animal {
val Leg[4] legs;
}
For Option 2, MOF2RDF would give you the maximum cardinality of 1 on the leg field of Monoped, meaning that our use of restrictions would make the driver behave the same as EMF (monoped.leg either gives you a Leg or null). It would also produce a maxCardinality of 2 and 4 for Biped and Quadruped, meaning that biped.legs and quadruped.legs will give you collections as you would expect.
Note that we could also have written this:
class Animal {}
class Monoped extends Animal {
val Leg[1] legs;
}
class Biped extends Animal {
val Leg[2] legs;
}
class Quadruped extends Animal {
val Leg[4] legs;
}
This is equivalent to Option 2 from the point of view of Ecore, though.
I'd try what happens in the example Gian gave of an RDF model where
Animal
s havelegs
, and we classifyAnimal
s into Monoped, Biped and Quadruped based on the number of legs they have. Try doing this:(If you need an example of a Monoped, we could try limpets.)
This actually creates an interesting scenario, where we may be getting a single value from
Monoped
(since there will be a restriction that they have one leg), but in theory we'd still want a list. It does mean that while MOF2RDF-based RDF graphs would work with our idea of seeing if a restriction was imposed (in terms of producing equivalent query results), in the general case of RDF graphs you may not always want this behaviour.If the Monoped example turns out to work in that way, we should create a backlog item to split things into two:
We would expose MOF2RDFModel as a separate "MOF2RDF Model" type, so the user would explicitly say if they want to apply the MOF2RDF encoding or not.
Originally posted by @agarciadom in #22 (comment)
The text was updated successfully, but these errors were encountered: