I think you can use either in other contexts. I see the tradeoff being that the inclusion syntax and templates for referring to properties of another item might be slightly longer. For the example of children of Charles Dickens you definitely want to have each child be their own item, as it currently is:
http://www.wikidata.org/wiki/Q5686. The question for construction phases of Roman forts is whether or not each phase has enough information to justify being a complete item. Although if you are ready to go right now then it isn't really a question because qualifiers aren't implemented yet. I suggest creating the extra properties you need and creating separate items for the construction phases, even if they only have a few properties each, and then later on if downgrading them to just qualified values of properties for the main fort item simplifies some of your queries, inclusion syntax usage, and template boxes, then you can certainly do that.
Date: Wed, 27 Mar 2013 20:44:39 +0200
From: saturnian@gmx.com
To: wikidata-l@lists.wikimedia.org
Subject: Re: [Wikidata-l] A data model for Roman forts (castra)
Thanks Denny and Michael, it really
helps. It is indeed a major difference between string enumerations
of XSD and the values that should link to other items resulting in
a knowledge network.
Choosing between lists of values and own item as value, I would
prefer usually an own item because it could be
used in other context, e.g. a sentence. A good example could be
"The <children of Charles Dickens - Qxxxxxxxx> were younger
than ...".
On 03/27/2013 04:53 PM, Michael Hale wrote:
Regarding the construction phases complex type that
you want you have a couple of options. Properties support lists
of values, so you could split the type into multiple properties
and give a list of values for each. Then when qualifiers are
added you could add a date range qualifier to each value to
specify the phase or just use string qualifiers that say "phase
1", "phase 2", etc. depending on how detailed the information
is. You can also group the properties in their own item. So you
could create an item called "Potaissa phase 1 construction
details" and then have construction phase just be a list of
those specific items, which themselves contain the information.
Date: Wed, 27 Mar 2013 12:55:18 +0100
From:
denny.vrandecic@wikimedia.de
To:
wikidata-l@lists.wikimedia.org
Subject: Re: [Wikidata-l] A data model for Roman forts
(castra)
I would say this is a good starting point. The
Wikidata data model is described in full detail here [1],
and a introductory primer is given here [2]. Qualifiers are
not implemented yet, but will be there soon, and followed by
more datatypes (like time, geo, etc.).
The major difference is that values like "stone" for
material or "opus-quadratum" for technique should not be
strings - this does not translate well. They should be
pointing to items, e.g. Q8063 instead of "stone"
and Q2631941 instead of "opus-quadratum".
The other thing is that Wikidata does not really intend
to enable constraints in that very strong sense that your
schema chooses. So if someone wants to add a value for
material that you did not preconceive, like Q40861
(Marble), Wikidata-as-a-software will not stop them from
doing so (just as Wikipedia-as-a-software does not stop
you from entering that, either) (see also [3]).
I hope this helps,
Denny
_______________________________________________
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l
_______________________________________________
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l
_______________________________________________
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l