Re: [Wikidata-l] External identifiers vs. Wikidata-internal links & data

2015-04-07 Thread Melvin Carvalho 
On 4 April 2015 at 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.
>

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
> [email protected]
> https://lists.wikimedia.org/mailman/listinfo/wikidata-l
>
>
___
Wikidata-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] External identifiers vs. Wikidata-internal links & data

2015-04-07 Thread Romaine Wiki 
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 (  )  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 :

> On Sun, Apr 5, 2015 at 6:52 PM, Magnus Manske
>  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
>
> --
> 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
> [email protected]
> https://lists.wikimedia.org/mailman/listinfo/wikidata-l
>
___
Wikidata-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] External identifiers vs. Wikidata-internal links & data

2015-04-07 Thread Lydia Pintscher 
There is a ticket for tracking this now at
https://phabricator.wikimedia.org/T95287


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
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] External identifiers vs. Wikidata-internal links & data

2015-04-06 Thread Bene* 

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


___
Wikidata-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] External identifiers vs. Wikidata-internal links & data

2015-04-06 Thread Joe Filceolaire 
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"  wrote:

> On Sun, Apr 5, 2015 at 6:52 PM, Magnus Manske
>  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
>
> --
> 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
> [email protected]
> https://lists.wikimedia.org/mailman/listinfo/wikidata-l
>
___
Wikidata-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] External identifiers vs. Wikidata-internal links & data

2015-04-06 Thread Lydia Pintscher 
On Mon, Apr 6, 2015 at 4:08 PM, Lydia Pintscher
 wrote:
> 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.

Here I of course wanted to write "I initially was set on 2 but am
coming around to 1."


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
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] External identifiers vs. Wikidata-internal links & data

2015-04-06 Thread Lydia Pintscher 
On Sun, Apr 5, 2015 at 6:52 PM, Magnus Manske
 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

-- 
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
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] External identifiers vs. Wikidata-internal links & data

2015-04-05 Thread Stas Malyshev 
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.

-- 
Stas Malyshev
[email protected]

___
Wikidata-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] External identifiers vs. Wikidata-internal links & data

2015-04-05 Thread Magnus Manske 
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 [email protected]  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
> >* 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
> "57405" 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
> [email protected]
>
> ___
> Wikidata-l mailing list
> [email protected]
> https://lists.wikimedia.org/mailman/listinfo/wikidata-l
>
>
> ___
> Wikidata-l mailing list
> [email protected]
> https://lists.wikimedia.org/mailman/listinfo/wikidata-l
>
___
Wikidata-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] External identifiers vs. Wikidata-internal links & data

2015-04-04 Thread [email protected] 
+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 
 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
"57405" 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
[email protected]

___
Wikidata-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikidata-l




___
Wikidata-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] External identifiers vs. Wikidata-internal links & data

2015-04-04 Thread Stas Malyshev 
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
"57405" 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
[email protected]

___
Wikidata-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] External identifiers vs. Wikidata-internal links & data

2015-04-04 Thread Thad Guidry 
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 

On Sat, Apr 4, 2015 at 2:05 PM, Joe Filceolaire 
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 ."  wrote:
>
>> On Sat, Apr 4, 2015 at 5:19 AM, Smolenski Nikola 
>> wrote:
>> > Citiranje Thad Guidry :
>> >> I think a simple naming convention would suffice (and clean up the
>> existing
>> >> ones):   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
>> [email protected]
>> https://lists.wikimedia.org/mailman/listinfo/wikidata-l
>>
>
> ___
> Wikidata-l mailing list
> [email protected]
> https://lists.wikimedia.org/mailman/listinfo/wikidata-l
>
>
___
Wikidata-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] External identifiers vs. Wikidata-internal links & data

2015-04-04 Thread Joe Filceolaire 
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 ."  wrote:

> On Sat, Apr 4, 2015 at 5:19 AM, Smolenski Nikola 
> wrote:
> > Citiranje Thad Guidry :
> >> I think a simple naming convention would suffice (and clean up the
> existing
> >> ones):   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
> [email protected]
> https://lists.wikimedia.org/mailman/listinfo/wikidata-l
>
___
Wikidata-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] External identifiers vs. Wikidata-internal links & data

2015-04-04 Thread Helder . 
On Sat, Apr 4, 2015 at 5:19 AM, Smolenski Nikola  wrote:
> Citiranje Thad Guidry :
>> I think a simple naming convention would suffice (and clean up the existing
>> ones):   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
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] External identifiers vs. Wikidata-internal links & data

2015-04-04 Thread David Cuenca 
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 
wrote:

> On 4 April 2015 at 10:20, Thomas Douillard 
> wrote:
>
> > I guess a class of properties ''external identifier definition property''
> > with isbn   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
> [email protected]
> https://lists.wikimedia.org/mailman/listinfo/wikidata-l
>



-- 
Etiamsi omnes, ego non
___
Wikidata-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] External identifiers vs. Wikidata-internal links & data

2015-04-04 Thread Andy Mabbett 
On 4 April 2015 at 10:20, Thomas Douillard  wrote:

> I guess a class of properties ''external identifier definition property''
> with isbn   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
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] External identifiers vs. Wikidata-internal links & data

2015-04-04 Thread Markus Krötzsch 

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
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikidata-l




___
Wikidata-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] External identifiers vs. Wikidata-internal links & data

2015-04-04 Thread Thomas Douillard 
@Nemo: I guess a class of properties ''external identifier definition
property'' with
isbn   external identifier prop could be useful as well.

2015-04-04 11:16 GMT+02:00 Federico Leva (Nemo) :

> 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&target=
> 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
> [email protected]
> https://lists.wikimedia.org/mailman/listinfo/wikidata-l
>
___
Wikidata-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] External identifiers vs. Wikidata-internal links & data

2015-04-04 Thread Federico Leva (Nemo) 
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&target=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
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] External identifiers vs. Wikidata-internal links & data

2015-04-04 Thread Stas Malyshev 
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
[email protected]

___
Wikidata-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] External identifiers vs. Wikidata-internal links & data

2015-04-04 Thread Smolenski Nikola 
Citiranje Erik Moeller :
> 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.



___
Wikidata-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] External identifiers vs. Wikidata-internal links & data

2015-04-04 Thread Smolenski Nikola 
Citiranje Thad Guidry :
> I think a simple naming convention would suffice (and clean up the existing
> ones):   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? :)



___
Wikidata-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] External identifiers vs. Wikidata-internal links & data

2015-04-04 Thread Gerard Meijssen 
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-iii.html

On 4 April 2015 at 09:29, Stas Malyshev  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
> [email protected]
>
> ___
> Wikidata-l mailing list
> [email protected]
> https://lists.wikimedia.org/mailman/listinfo/wikidata-l
>
___
Wikidata-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] External identifiers vs. Wikidata-internal links & data

2015-04-04 Thread Stas Malyshev 
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
[email protected]

___
Wikidata-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] External identifiers vs. Wikidata-internal links & data

2015-04-03 Thread Lydia Pintscher 
On Apr 4, 2015 02:37, "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.

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
> [email protected]
> https://lists.wikimedia.org/mailman/listinfo/wikidata-l
>
___
Wikidata-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] External identifiers vs. Wikidata-internal links & data

2015-04-03 Thread Gerard Meijssen 
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  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
> [email protected]
> https://lists.wikimedia.org/mailman/listinfo/wikidata-l
>
>
___
Wikidata-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] External identifiers vs. Wikidata-internal links & data

2015-04-03 Thread Emw 
>
> 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

https://www.wikidata.org/wiki/User:Emw
___
Wikidata-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] External identifiers vs. Wikidata-internal links & data

2015-04-03 Thread Erik Moeller 
On Fri, Apr 3, 2015 at 7:07 PM, Thad Guidry  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

___
Wikidata-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] External identifiers vs. Wikidata-internal links & data

2015-04-03 Thread Thad Guidry 
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 
___
Wikidata-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] External identifiers vs. Wikidata-internal links & data

2015-04-03 Thread Thad Guidry 
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):   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 

On Fri, Apr 3, 2015 at 8:17 PM, Denny Vrandečić  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  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
>> [email protected]
>> https://lists.wikimedia.org/mailman/listinfo/wikidata-l
>>
>
> ___
> Wikidata-l mailing list
> [email protected]
> https://lists.wikimedia.org/mailman/listinfo/wikidata-l
>
>
___
Wikidata-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] External identifiers vs. Wikidata-internal links & data

2015-04-03 Thread Denny Vrandečić 
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  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
> [email protected]
> https://lists.wikimedia.org/mailman/listinfo/wikidata-l
>
___
Wikidata-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikidata-l