Hi Lydia,
If a separate section is needed for identifiers, I do not care.
From the user perspective point of view my question would be what happens
when a user tries to add an identifier in the statements section instead of
the identifiers section? Besides users are used to add identifier
On 4 April 2015 at 02:35, Erik Moeller e...@wikimedia.org wrote:
Hi all --
Have we considered separating in some way (in the UI, and possibly the
data model) properties which track identifiers in external databases vs.
properties that describe the item using Wikidata-internal links? As more
If you change the datatype for identifiers from string and the other
properties with string datatype are changed to monolingual then we won't
have much need for the string datatype
On 6 Apr 2015 15:09, Lydia Pintscher lydia.pintsc...@wikimedia.de wrote:
On Sun, Apr 5, 2015 at 6:52 PM, Magnus
Hi
Am 06.04.2015 um 16:08 schrieb Lydia Pintscher:
3 seems problematic from a performance point
Really? I expect that when queries for simple property-value pairs are
here this shouldn't be problematic at all. Furthermore we can cache the
results, thus such a lookup should be as simple as a
Hi!
Quick hack: On your user common.js page, add:
importScript( 'User:Magnus Manske/ext-props.js' );
Thanks a lot, looks nice!
I think you missed a few there:
https://www.wikidata.org/wiki/Property:P1015
https://www.wikidata.org/wiki/Property:P1005
https://www.wikidata.org/wiki/Property:P949
Quick hack: On your user common.js page, add:
importScript( 'User:Magnus Manske/ext-props.js' );
This will move all statements for external IDs (to be exact, all
properties with a URL formatter property) to the sidebar.
The statements in the main body are just hidden; there is a toggle link in
On Apr 4, 2015 02:37, Erik Moeller e...@wikimedia.org wrote:
Hi all --
Have we considered separating in some way (in the UI, and possibly the
data model) properties which track identifiers in external databases vs.
properties that describe the item using Wikidata-internal links? As more
and
Hi!
away from the old layout and that is very welcome. Singling out the
external resources does not make sense at this time.
It is true that more structure in general would be good, but I think
there's some difference between external IDs and other properties -
namely, the former convey almost
Hi!
I agree this would be a nice idea. I believe it would be relatively easy to
do,
if only properties could have properties of their own.
AFAIK they can, e.g. https://www.wikidata.org/wiki/Property:P35
--
Stas Malyshev
smalys...@wikimedia.org
Stas Malyshev, 04/04/2015 09:29: away from the old layout and that is
very welcome. Singling out the
external resources does not make sense at this time.
It is true that more structure in general would be good, but I think
there's some difference between external IDs and other properties -
Citiranje Thad Guidry thadgui...@gmail.com:
I think a simple naming convention would suffice (and clean up the existing
ones): blah ID such as for example:
CANTIC ID
Freebase ID
Munzinger IBA ID
NLP ID
dmoz ID
Oxford Biography Index ID
SELIBR ID
How would you name ISBN, for example?
Citiranje Erik Moeller e...@wikimedia.org:
Have we considered separating in some way (in the UI, and possibly the data
model) properties which track identifiers in external databases vs.
properties that describe the item using Wikidata-internal links? As more
and more external identifiers are
Hoi,
Reasonator is read only in the sense that the display does not update
itself when you make an edit from it through Widar. Even that is not
strictly true; the label of the article itself will update when you add a
label in your language and once it has been included in Wikidata.
I really
@Nemo: I guess a class of properties ''external identifier definition
property'' with
isbn instance of external identifier prop could be useful as well.
2015-04-04 11:16 GMT+02:00 Federico Leva (Nemo) nemow...@gmail.com:
Stas Malyshev, 04/04/2015 09:29: away from the old layout and that is
Hi Erik, hi all,
Aren't those properties already distinguished by the classification
statements we now have on property pages? For example:
https://www.wikidata.org/wiki/Property:P214
Defines the VIAF id to be a unique identifier (yes, this is somewhat
questionable modelling, since a
On 4 April 2015 at 10:20, Thomas Douillard thomas.douill...@gmail.com wrote:
I guess a class of properties ''external identifier definition property''
with isbn instance of external identifier prop could be useful as well.
The property for an ORCID iD (P 496), for example, is an instance of
Hi all,
On a side note I would like to mention that labels and aliases are
external identifiers, perhaps not as accurate as database IDs, as natural
language users tend to stretch the conceptual boundaries, but they can also
be referenced and sourced.
If, as Lydia says, database IDs will have
On Sat, Apr 4, 2015 at 5:19 AM, Smolenski Nikola smole...@eunet.rs wrote:
Citiranje Thad Guidry thadgui...@gmail.com:
I think a simple naming convention would suffice (and clean up the existing
ones): blah ID such as for example:
CANTIC ID
Freebase ID
Munzinger IBA ID
NLP ID
dmoz ID
Ah, as Markus mentions, since we already have https://www.wikidata.org/wiki/
Property:P214
Then the rest of the problem is just a readability issue.
So there is no need for renaming property names as I suggested and
suffixing with ID P214 solves the grouping problem fairly easily.
And Lydia
+1
I have exactly the same impression when reading individual pages on Wikidata.
Cheers,
Aleksander Smywiński-Pohl
Wł. So, 04 kwi 2015 22:50:05 +0200 Stas Malyshev
lt;smalys...@wikimedia.orggt; napisał(a)
Hi!
gt;gt; there's some difference between external IDs and other properties
Yes. I could see a simple Statements vs. External identifiers
distinction being useful that's also reflected in the data model so
it's easier to treat these property groups in a distinct manner.
I support grouping statements about external identifiers together and
distinguishing them from
Hoi,
When you look at Wikidata itself, it is very much a jungle of unsorted
data. This has been recognised and a different layout of the information is
in the planning. I am glad with your complaint because it shows that we are
maturing.. We have so much of a mess that it is largely
Re-reading...
Erik,
I think you mean that the display itself for instance on this page:
https://www.wikidata.org/wiki/Q42
would be more useful if all Identifiers were pushed down to the bottom half
or different section, for instance, and keeping descriptor properties on
the upper half ? (instead
On Fri, Apr 3, 2015 at 7:07 PM, Thad Guidry thadgui...@gmail.com wrote:
I think you mean that the display itself for instance on this page:
https://www.wikidata.org/wiki/Q42
would be more useful if all Identifiers were pushed down to the bottom half
or different section,
for instance, and
Why do you have to get lost in them ?
Most already have the phrase ID or Identifier in their naming
convention. So perhaps a better approach would be to standardize the
naming convention used for External Identifiers and make it a best practice
and golden rule during property creation and
25 matches
Mail list logo
