I have a model "messages". And it should have a predicate, which will indicate, are they (messages) fetching. Should I name it "areFetching" or "isFetching"?
I tried to google "predicates naming conventions", but they all are only about "is" and "has" prefixes.
Related
Schema.org both defines and uses the predicates named domainIncludes and rangeIncludes to relate types to properties (i.e. <schema:name> <schema:domainIncludes> <schema:Person> and <schema:name> <schema:rangeIncludes> <schema:Text>).
However in RDF Schema 1.1's specification, the predicates domain and range are already defined (giving <schema:name> <rdfs:domain> <schema:Person> and <schema:name> <schema:range> <schema:Text>).
My question boils down to: are schema.org's domainIncludes and rangeIncludes predicates equivalent to the RDFS domain and range predicates?
And if so:
Why does schema.org define them in the first place and not just use the predicates provided by the RDF standard? It already makes use of other RDFS defined predicates such as rdfs:label and rdfs:comment. Was this a stylistic choice? (Did they not like the names "domain" and "range"?)
Why is this relationship between the predicates not defined using owl:equivalentProperty or an equivalent? Schema.org should be explicit when creating predicates that are already defined by accepted standards such as RDFS 1.1, especially given its mission is structuring and standardising the web.
Otherwise remain a big fan of schema.org : )
Why does schema.org define them in the first place and not just use the predicates provided by the RDF standard?
Schema.org doesn't want you to do inferencing using certain properties. If I knew that
<schema:name> <rdfs:domain> <schema:Person>
then whenever I saw a <schema:name> defined for an object, I could infer that the object was of type <schema:Person>. Schema.org uses <schema:name> for lots of things so uses <schema:domainIncludes> to indicate how you could or should use it but doesn't lock it down.
Why is this relationship between the predicates not defined using owl:equivalentProperty or an equivalent?
This is a policy issue for schema.org! My guess is that, like many general purpose ontologies (e.g. Semantic Sensor Network vocab), they like to keep weak semantics to allow for flexibility of application over the kind of strictness you're talking about that you need for inference.
If you look at RDF/OWL as a distributed DB, and an ontology as the DB Schema,
then this explanation might make sense to you:
If you look at the definition of rdfs:domain, you find:
Where a property P has more than one rdfs:domain property, then the resources denoted by subjects of triples with predicate P are instances of all the classes stated by the rdfs:domain properties.
So if you have more then one domain, all those must be true! -> AND
If you have multiple schema:domainIncludess, at least one must be true. -> OR
I find that in (DB-)practice, one almost always wants the later approach (OR).
All this is the same for rdfs:range and schema:rangeIncludes.
As I read that
aggreagation kind is a property of the association's member ends
And also
aggregation, association and composition are features of the
properties, which take part in the association as associatio ends, and
is called AggregationKind.
Could you Please clarify the two sentences through a UML simple example?
It is obvious that both the sentences have basically the same meaning.Generally,in many-to-many associations the association has itself two or more Properties as MemberEnds. We can describe these properties separately using a type called aggregationkind. This property in fact has an attribute aggregation of type AggregationKind.
AggregationKind is an enumeration type that specifies the literals for defining the kind of aggregation of a property or you can simply say AggregationKind defines the type of aggregation with the help of following basic literals:
none Indicates that the property has no aggregation.
shared Indicates that the property has a shared aggregation.
composite Indicates that the property is aggregated compositely, i.e., the composite object has responsibility for the existence and storage of the composed objects (parts).
It’s this AggregationKind that specifies the difference between a regular Association, an Aggregation and a Composition.We can understand this with help of following diagram:
NOTE: the diagram is taken from here
Some of the useful links regarding this topic:
http://www.uml-diagrams.org/association.html
2.http://www.cs.sjsu.edu/~pearce/modules/lectures/uml/class/Aggregation.htm
Clearly, the implicit naming conventions for DAL/web2py are different from the conventions adopted by Rose::DB::Object but i dont see any explicit list of such conventions anywhere.
Is there a set of principles that guide the name of tables and columns when modeling data with DAL?
There are no requirements imposed, so feel free to follow whatever conventions you like. I think many of the conventions you point to are typically followed in web2py code, though there seems to be more of a preference for singular table names, and foreign key column names are often just the foreign table name, without joining "_id" to the end. By default, all tables get an auto-incrementing id field named "id", though you can change that name if you like.
Is there a convention for naming tables when using Doctrine ORM? I like to name tables with the plural but if there's a convention I want to stick to it.
So the table 'users' would be related to tables using the fk as the singular ('user_id').
Is there a best practice for this (using singular or plural table names) and if the latter, how does this apply to tables where the plural isn't a simple case of adding an 's'.
For example I currently have a table called 'categorys' instead of 'categories' to maintain the convention of adding 's'.
Is this a sensible approach?
I used to use plural table names when using my own basic ORM but I switched over to singular table names when I started using symfony + Propel and now a little bit of Doctrine. The reason for this is for the class names because you want to create a User and not a Users.
With Doctrine, when it comes to collections or relations, you tell it what the alias should be:
http://www.doctrine-project.org/projects/orm/1.2/docs/manual/working-with-models/en
You'll see the a User can have many Phonenumber so a foreignAlias was setup in the YAML schema so it would be Phonenumbers effectively accessed via $user->Phonenumbers.
In your example you'll set the foreignAlias to be Categories while keeping the table and record named Category.
The Doctrine convention is to use singular names for tables and models, as the first answerer explains, because logically you want methods like:
$user->Phonenumbers
... instead of:
$user->Phonenumberss
The definitions can be customised through Aliases.
Assume I have a composite relationship, say a Customer having a collection of Orders (and assuming an Order cannot exist without an "owning" Customer.) So, I'm not talking about aggregation.
What terms are used to describe the roles in this relationship? I might say the Customer is the "owner" of an Order and maybe the Order is "owned", but surely there are better terms, terms that can be stated without referring to the other role.
I'm trying to determine these terms so I can propertly name attributes in a meta model. I can "make something up", but would like to use names that will be easily understood.
Thanks in advance for suggestions and/or pointers to definitive sources.
Bill
You want the "has a" relationship; our thing "has a"nother thing attached, as opposed to inheritance of "is a" relationship. You can build fairly robust models around just those two relationships. But.
To postulate further, in Topic Maps (since we're talking about meta models) we have a few in-built relationships which also has global identifiers (which you could use for global knowledge / data exchange), which are the supertype-subtype (denotes hiearchies) and the type-instance (denotes typification, a strongly typed "is a") relationships. These are fairly global (meaning, also outside the Topic Maps world). Have a look at the end of the Topic Maps Data Model for more on this.
This is also called the "has a" relationship. The Customer object "has a" collection of Order objects. Where as in inheritance, you'd say the Customer "is a" Person. You could also say the collection of Orders is a field or member or whatever you're language calls member variables. You'd just call the Customer an object (or a composite type). Most classes are composite types anyway, unless there's no state (i.e. just methods/behavior).