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 more external identifiers are added, it's easy to get lost in them while looking for the right property to describe an item.
We're effectively already doing this with Wikimedia identifiers by calling them "sitelinks" and it seems like a potential logical extension of that concept to group other kinds of external identifiers in their own section rather than having CANTIC, BIBSYS identifiers, Freebase identifiers or even DMOZ links mixed together with the primary descriptors of an author or work, for example.
Thanks, Erik
Is there any external key which is not of data type string and vice versa?
Also, no matter whether this gets done or not, please don't remove qualifiers and references from these statements (I.e. explicitly don't treat them like sitelinks)
On Fri, Apr 3, 2015, 17:36 Erik Moeller erik@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 more external identifiers are added, it's easy to get lost in them while looking for the right property to describe an item.
We're effectively already doing this with Wikimedia identifiers by calling them "sitelinks" and it seems like a potential logical extension of that concept to group other kinds of external identifiers in their own section rather than having CANTIC, BIBSYS identifiers, Freebase identifiers or even DMOZ links mixed together with the primary descriptors of an author or work, for example.
Thanks, Erik
Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
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 voting. A further refinement could be to enhance the statement selector with an option for "ID" or "WP ID" or "Descriptor".
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 etc..
Thad +ThadGuidry https://www.google.com/+ThadGuidry
On Fri, Apr 3, 2015 at 8:17 PM, Denny Vrandečić vrandecic@gmail.com wrote:
Is there any external key which is not of data type string and vice versa?
Also, no matter whether this gets done or not, please don't remove qualifiers and references from these statements (I.e. explicitly don't treat them like sitelinks)
On Fri, Apr 3, 2015, 17:36 Erik Moeller erik@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 more external identifiers are added, it's easy to get lost in them while looking for the right property to describe an item.
We're effectively already doing this with Wikimedia identifiers by calling them "sitelinks" and it seems like a potential logical extension of that concept to group other kinds of external identifiers in their own section rather than having CANTIC, BIBSYS identifiers, Freebase identifiers or even DMOZ links mixed together with the primary descriptors of an author or work, for example.
Thanks, Erik
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
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 of the current mixing of both within the div.wikibase-listview ?
Thad +ThadGuidry https://www.google.com/+ThadGuidry
On Fri, Apr 3, 2015 at 7:07 PM, Thad Guidry thadguidry@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 keeping descriptor properties on the upper half ? (instead of the current mixing of both within the div.wikibase-listview ?
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. External identifiers seem as fundamentally different to me from Wikidata-internal and Wikimedia-related properties as external links in a Wikipedia article are from the main content. They (in the common cases) don't tell me anything other than "There's more information about $foo in $bar".
Whether I'm a human or a friendly machine, I might want to just look at one set of properties or another, depending on what I'm doing, so having them grouped in some fashion may be beneficial for both user groups.
Erik
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 other statements, but I would voice caution about presenting that distinction as "Statements vs. External identifiers".
I agree with Denny that qualifiers and references should be retained for external identifiers. I would further suggest that external identifiers remain structured as properties that can (along with their values in claims) be created, updated and deleted by the community.
Given that, I think the distinction should be styled less as "Statements vs. External identifiers" and more as "External identifiers as a kind of statement". UI editing controls and data modeling as statements would remain, but "External identifiers" (e.g. *VIAF identifier* 113230702) would be moved to the bottom or side of statements of subject knowledge (e.g. *cause of death* heart attack).
Grouping together and separating external identifiers from other kinds of statements in the UI, and reflecting that in the data model and API, sounds like a great idea. https://www.wikidata.org/wiki/Q42 is a rat's nest of meaningless (but technically useful) statements about external identifiers and meaningful statements about the subject. It's important to fix that, and I imagine we could do so while retaining all the current UI controls and data model attributes of statements in statements about external identifiers.
Best, Eric
Citiranje Thad Guidry thadguidry@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? ISBN ID? :)
On Sat, Apr 4, 2015 at 5:19 AM, Smolenski Nikola smolensk@eunet.rs wrote:
Citiranje Thad Guidry thadguidry@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? ISBN ID? :)
And how would this work with translations?
Helder
Best to have a statement (instance of:wikidata database index property) instead of trying to do this with the English language label as it is easier to localise statement s. On 4 Apr 2015 17:23, "Helder ." helder.wiki@gmail.com wrote:
On Sat, Apr 4, 2015 at 5:19 AM, Smolenski Nikola smolensk@eunet.rs wrote:
Citiranje Thad Guidry thadguidry@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? ISBN ID? :)
And how would this work with translations?
Helder
Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
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 says readability in general is going to improve...just wait.
So, I am looking forward to the site display improvements in the future and more use of P214.
Thad +ThadGuidry https://www.google.com/+ThadGuidry
On Sat, Apr 4, 2015 at 2:05 PM, Joe Filceolaire filceolaire@gmail.com wrote:
Best to have a statement (instance of:wikidata database index property) instead of trying to do this with the English language label as it is easier to localise statement s. On 4 Apr 2015 17:23, "Helder ." helder.wiki@gmail.com wrote:
On Sat, Apr 4, 2015 at 5:19 AM, Smolenski Nikola smolensk@eunet.rs wrote:
Citiranje Thad Guidry thadguidry@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? ISBN ID? :)
And how would this work with translations?
Helder
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
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 unintelligible. The development of Wikidata is slowly but surely moving away from the old layout and that is very welcome. Singling out the external resources does not make sense at this time.
When you want your information is a more readable way use Reasonator. All the externals are on the sidebar. You can use it in multiple languages. It is the current best of breed for displaying everything Wikidata AND you can label in your language when WIDAR is enabled.
Having the external resources in there has already proven itself as being extremely important.. OCLC will use Wikidata as its primary source for linking its sum of all knowledged to our sum of encyclopaedic knowledge.
Erik be patient.. see that the German team have the resources they need. Thanks, Gerard
On 4 April 2015 at 02:35, Erik Moeller erik@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 more external identifiers are added, it's easy to get lost in them while looking for the right property to describe an item.
We're effectively already doing this with Wikimedia identifiers by calling them "sitelinks" and it seems like a potential logical extension of that concept to group other kinds of external identifiers in their own section rather than having CANTIC, BIBSYS identifiers, Freebase identifiers or even DMOZ links mixed together with the primary descriptors of an author or work, for example.
Thanks, Erik
Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
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 no information useful to a human in most cases (though definitely not in all - in some cases, that's exactly what one may look for). So internally (on the data level, etc. with respect to qualifiers and all other data model things) they may be the same, but if in the UI they were separated somehow I think that would help making both cases more efficient and make finding way in the data easier.
When you want your information is a more readable way use Reasonator.
Reasonator is excellent but AFAIK it's read-only and one can be lost in the wall of IDs even when editing. I think having them in separate section (and, further, having properties grouped somehow in general) would be helpful.
Having the external resources in there has already proven itself as being extremely important.. OCLC will use Wikidata as its primary source for linking its sum of all knowledged to our sum of encyclopaedic knowledge.
It's indeed important, so I think the idea is not to diminish their importance somehow but to give them separate space which may lead to improved workflows for both "data" properties and "external ID" properties.
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 wonder when you have been last at Widar because there is no wall of ID's. Thanks, GerardM
http://ultimategerardm.blogspot.nl/2015/04/wikidata-what-to-do-in-datathon-i...
On 4 April 2015 at 09:29, Stas Malyshev smalyshev@wikimedia.org wrote:
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 no information useful to a human in most cases (though definitely not in all - in some cases, that's exactly what one may look for). So internally (on the data level, etc. with respect to qualifiers and all other data model things) they may be the same, but if in the UI they were separated somehow I think that would help making both cases more efficient and make finding way in the data easier.
When you want your information is a more readable way use Reasonator.
Reasonator is excellent but AFAIK it's read-only and one can be lost in the wall of IDs even when editing. I think having them in separate section (and, further, having properties grouped somehow in general) would be helpful.
Having the external resources in there has already proven itself as being extremely important.. OCLC will use Wikidata as its primary source for linking its sum of all knowledged to our sum of encyclopaedic
knowledge.
It's indeed important, so I think the idea is not to diminish their importance somehow but to give them separate space which may lead to improved workflows for both "data" properties and "external ID" properties.
-- Stas Malyshev smalyshev@wikimedia.org
Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
On Apr 4, 2015 02:37, "Erik Moeller" erik@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 more external identifiers are added, it's easy to get lost in them while looking for the right property to describe an item.
We're effectively already doing this with Wikimedia identifiers by
calling them "sitelinks" and it seems like a potential logical extension of that concept to group other kinds of external identifiers in their own section rather than having CANTIC, BIBSYS identifiers, Freebase identifiers or even DMOZ links mixed together with the primary descriptors of an author or work, for example.
Yes we will separate them somehow. But there are still open questions about how to preserve references and qualifiers for example as Denny said.
Cheers Lydia
Thanks, Erik
Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Citiranje Erik Moeller erik@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 added, it's easy to get lost in them while looking for the right property to describe an item.
We're effectively already doing this with Wikimedia identifiers by calling them "sitelinks" and it seems like a potential logical extension of that concept to group other kinds of external identifiers in their own section rather than having CANTIC, BIBSYS identifiers, Freebase identifiers or even DMOZ links mixed together with the primary descriptors of an author or work, for example.
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.
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, 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 - namely, the former convey almost no information useful to a human
Did you mean the opposite?
Stas Malyshev, 04/04/2015 10:22:
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
Indeed: https://www.wikidata.org/wiki/Property:P1628 is already used to mark properties ("identifiers") already defined in other ontologies. https://www.wikidata.org/w/index.php?title=Special%3AWhatLinksHere&targe...
Looks like we just need to add this property to more properties. Whether this piece of information is used for presentational purposes seems secondary, or at least I don't see a compelling argument for it yet.
Nemo
@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) nemowiki@gmail.com:
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 - namely, the former convey almost no information useful to a human
Did you mean the opposite?
Stas Malyshev, 04/04/2015 10:22:
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
Indeed: https://www.wikidata.org/wiki/Property:P1628 is already used to mark properties ("identifiers") already defined in other ontologies. https://www.wikidata.org/w/index.php?title=Special%3AWhatLinksHere&targe... Property%3AP1628&namespace=120
Looks like we just need to add this property to more properties. Whether this piece of information is used for presentational purposes seems secondary, or at least I don't see a compelling argument for it yet.
Nemo
Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
On 4 April 2015 at 10:20, Thomas Douillard thomas.douillard@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 "Wikidata property for authority control for people" (Q19595382). That, in turn is a sub-class of "Wikidata property for authority control" (Q18614948)
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 their own section (either only in the frontend, or also in the backend), I would recommend to use a similar method for sourcing+qualifying labels, as "natural language identifiers" and "database identifiers" share the same problems.
On Freebase, database keys had a separate tab. Not sure if that is the right approach...
Cheers, Micru
On Sat, Apr 4, 2015 at 3:45 PM, Andy Mabbett andy@pigsonthewing.org.uk wrote:
On 4 April 2015 at 10:20, Thomas Douillard thomas.douillard@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 "Wikidata property for authority control for people" (Q19595382). That, in turn is a sub-class of "Wikidata property for authority control" (Q18614948)
-- Andy Mabbett @pigsonthewing http://pigsonthewing.org.uk
Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Hi!
there's some difference between external IDs and other properties - namely, the former convey almost no information useful to a human
Did you mean the opposite?
I meant when you're looking at the page for Douglas Adams, you can see that his birth name was "Douglas Noël Adams" and this is useful for you as a human reader. But before that, you see that his "LNB identifier" is "000057405" and in 99.9% of cases it is not useful for you since you neither know what "LNB identifier" is nor you need to see one unless you're a Latvian librarian working on integration with Wikidata. Now, I imagine there is a lot of uses for such identifiers, and I am in no way call for diminishing their role or somehow questioning their importance as data, but *presenting* it as the second most important knowledge we have about Douglas Adams right after the fact he is a human looks wrong to me.
+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 <smalyshev@wikimedia.org> napisał(a) ----
Hi!
>> there's some difference between external IDs and other properties - >> namely, the former convey almost no information useful to a human > > Did you mean the opposite?
I meant when you're looking at the page for Douglas Adams, you can see that his birth name was "Douglas Noël Adams" and this is useful for you as a human reader. But before that, you see that his "LNB identifier" is "000057405" and in 99.9% of cases it is not useful for you since you neither know what "LNB identifier" is nor you need to see one unless you're a Latvian librarian working on integration with Wikidata. Now, I imagine there is a lot of uses for such identifiers, and I am in no way call for diminishing their role or somehow questioning their importance as data, but *presenting* it as the second most important knowledge we have about Douglas Adams right after the fact he is a human looks wrong to me.
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 the sidebar to make them visible again, qualifiers and all.
This is, of course, just a demo to show what the main body would look like without such statements.
On Sun, Apr 5, 2015 at 12:05 AM apohllo@o2.pl apohllo@o2.pl wrote:
+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 <smalyshev@wikimedia.org smalyshev@wikimedia.org>* napisał(a) ----
Hi!
there's some difference between external IDs and other properties - namely, the former convey almost no information useful to a human
Did you mean the opposite?
I meant when you're looking at the page for Douglas Adams, you can see that his birth name was "Douglas Noël Adams" and this is useful for you as a human reader. But before that, you see that his "LNB identifier" is "000057405" and in 99.9% of cases it is not useful for you since you neither know what "LNB identifier" is nor you need to see one unless you're a Latvian librarian working on integration with Wikidata. Now, I imagine there is a lot of uses for such identifiers, and I am in no way call for diminishing their role or somehow questioning their importance as data, but *presenting* it as the second most important knowledge we have about Douglas Adams right after the fact he is a human looks wrong to me.
-- Stas Malyshev smalyshev@wikimedia.org
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
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 https://www.wikidata.org/wiki/Property:P1207
Q42 is a treasure trove for these :) Will see if there is more.
On Sun, Apr 5, 2015 at 6:52 PM, Magnus Manske magnusmanske@googlemail.com wrote:
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 the sidebar to make them visible again, qualifiers and all.
This is, of course, just a demo to show what the main body would look like without such statements.
Magnus, as always you're a treasure ;-) I hadn't thought about the toggle option yet.
So let me summarize the options I see for identifiers: 1) we give them their own section below statements 2) we give them their own section in the right sidebar and have some compact way of showing and editing references and qualifiers 3) we do both of the above and have a way to toggle between the two
I initially was set on 2 but am coming around to 2. 3 seems like the easiest way out right now but it'll feel awkward to new users.
On the technical side I see the following options to identify which statements to group into the identifiers section: 1) we make them sitelinks 2) we we give them a special datatype (We should be able to migrate the existing ones in a one-time operation without changing their property IDs) 3) we rely on a statement on the property 4) we have a list in the wiki configuration
1 seems bad because we'd lose references and qualifiers 3 seems problematic from a performance point 4 is ugly and not maintainable So I am coming around to 2.
Cheers Lydia
On Mon, Apr 6, 2015 at 4:08 PM, Lydia Pintscher lydia.pintscher@wikimedia.de wrote:
So let me summarize the options I see for identifiers:
- we give them their own section below statements
- we give them their own section in the right sidebar and have some
compact way of showing and editing references and qualifiers 3) we do both of the above and have a way to toggle between the two
I initially was set on 2 but am coming around to 2.
Here I of course wanted to write "I initially was set on 2 but am coming around to 1."
Cheers Lydia
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.pintscher@wikimedia.de wrote:
On Sun, Apr 5, 2015 at 6:52 PM, Magnus Manske magnusmanske@googlemail.com wrote:
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
the sidebar to make them visible again, qualifiers and all.
This is, of course, just a demo to show what the main body would look
like
without such statements.
Magnus, as always you're a treasure ;-) I hadn't thought about the toggle option yet.
So let me summarize the options I see for identifiers:
- we give them their own section below statements
- we give them their own section in the right sidebar and have some
compact way of showing and editing references and qualifiers 3) we do both of the above and have a way to toggle between the two
I initially was set on 2 but am coming around to 2. 3 seems like the easiest way out right now but it'll feel awkward to new users.
On the technical side I see the following options to identify which statements to group into the identifiers section:
- we make them sitelinks
- we we give them a special datatype (We should be able to migrate
the existing ones in a one-time operation without changing their property IDs) 3) we rely on a statement on the property 4) we have a list in the wiki configuration
1 seems bad because we'd lose references and qualifiers 3 seems problematic from a performance point 4 is ugly and not maintainable So I am coming around to 2.
Cheers Lydia
-- Lydia Pintscher - http://about.me/lydia.pintscher Product Manager for Wikidata
Wikimedia Deutschland e.V. Tempelhofer Ufer 23-24 10963 Berlin www.wikimedia.de
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985.
Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
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 label lookup as far as I understand.
Best regards, Bene
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 statements to the statements section, it can cause misunderstanding if it is no longer possible to add identifiers to the statements section. I would then recommend (if this is not yet thought of) to allow users to add identifiers to the statement section, and with reloading the page they show up in the right section. (Maybe the other way round as well.)
Also when I currently want to add a statement, I press [ end ] on my keyboard, there I click [ add ]. If I must add the a statement to the right section, this would make it much uncomfortable to have to search somewhere between the statements and the identifiers where the [ add ] is for the statements section. If this would happen, it would make adding statements more annoying. (I would like to recommend to make it less annoying and more easier to add statements.) An alternative idea to solve this is to be able to add statements at the top of the statements section.
Navigation will be an important issue to have attention for, otherwise splitting it up in identifiers and other statements would make the improvement for users nett less improving but instead worse.
If it is wished for to split the identifiers from the other statements, I would more like it see just all the identifiers on the bottom of the statements section.
If all statements in the source code ( <div class="wikibase-statementgroupview-property"> ) would get an id="..." based on the property number, it is easy to arrange having all identifier properties on the bottom. At the same time this would be easier for users to put certain properties always on top of the statements section of an item
PS: Not all properties with URLs are identifiers, like the official website: https://www.wikidata.org/wiki/Property:P856 PS2: Not all identifiers have or will have an URL available.
Romaine
2015-04-06 16:08 GMT+02:00 Lydia Pintscher lydia.pintscher@wikimedia.de:
On Sun, Apr 5, 2015 at 6:52 PM, Magnus Manske magnusmanske@googlemail.com wrote:
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
the sidebar to make them visible again, qualifiers and all.
This is, of course, just a demo to show what the main body would look
like
without such statements.
Magnus, as always you're a treasure ;-) I hadn't thought about the toggle option yet.
So let me summarize the options I see for identifiers:
- we give them their own section below statements
- we give them their own section in the right sidebar and have some
compact way of showing and editing references and qualifiers 3) we do both of the above and have a way to toggle between the two
I initially was set on 2 but am coming around to 2. 3 seems like the easiest way out right now but it'll feel awkward to new users.
On the technical side I see the following options to identify which statements to group into the identifiers section:
- we make them sitelinks
- we we give them a special datatype (We should be able to migrate
the existing ones in a one-time operation without changing their property IDs) 3) we rely on a statement on the property 4) we have a list in the wiki configuration
1 seems bad because we'd lose references and qualifiers 3 seems problematic from a performance point 4 is ugly and not maintainable So I am coming around to 2.
Cheers Lydia
-- Lydia Pintscher - http://about.me/lydia.pintscher Product Manager for Wikidata
Wikimedia Deutschland e.V. Tempelhofer Ufer 23-24 10963 Berlin www.wikimedia.de
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985.
Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
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 property is not an identifier: the *values* of the property are identifiers, but the idea should be clear).
The UI code could now use such property classifications to improve readability. I am sure that Lydia et al. have already thought about this, too. One could make use of more fine-grained classifications of this type to improve the UI even further, e.g., Reasonator already groups family relationships in the display.
Instead of using classification ("instance of" P31), one could also introduce another property that is used on Property pages to assign them to a "property group" (to avoid mixing UI aspects with other uses of P31 on properties). The UI can then simply group statements by the UI group value of their property page. It would not even need to understand the meaning of each property group -- it's enough if it has a label.
Importantly, the underlying datamodel would not change in any case, so data consumers do not have to change their code. They can tke advantage of the same information -- or ignore it if they don't want to present statements in a grouped fashion.
Cheers,
Markus
On 04.04.2015 02:35, Erik Moeller 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 more external identifiers are added, it's easy to get lost in them while looking for the right property to describe an item.
We're effectively already doing this with Wikimedia identifiers by calling them "sitelinks" and it seems like a potential logical extension of that concept to group other kinds of external identifiers in their own section rather than having CANTIC, BIBSYS identifiers, Freebase identifiers or even DMOZ links mixed together with the primary descriptors of an author or work, for example.
Thanks, Erik
Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
There is a ticket for tracking this now at https://phabricator.wikimedia.org/T95287
Cheers Lydia
On 4 April 2015 at 02:35, Erik Moeller erik@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 more external identifiers are added, it's easy to get lost in them while looking for the right property to describe an item.
We're effectively already doing this with Wikimedia identifiers by calling them "sitelinks" and it seems like a potential logical extension of that concept to group other kinds of external identifiers in their own section rather than having CANTIC, BIBSYS identifiers, Freebase identifiers or even DMOZ links mixed together with the primary descriptors of an author or work, for example.
As systems grow they often need to interact with a larger eco system, I think URI's were designed exactly for this use case.
Perhaps it would be an idea to bring all these systems together by giving each entity a URI.
Thanks, Erik
Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l