Re: [Wikidata-l] Weekly Summary #152

[Ricordisamoa]

Il 05/04/2015 17:18, John Lewis ha scritto:

Hi everyone,

Here is the latest update of everything going on around Wikidata!


  Discussions

  * Closed RfC: Reforming administrator inactivity criteria




  Events /Press/Blogs
  

  * WikiArabia
 takes place
in Monastir, Tunisia, 3-5 April
  * The GLAM-WIKI 2015  conference in The
Hague (10-12 April) features several presentations and tutorials
about Wikidata for/with cultural institutions.
  * The Library world will use Wikidata


 to
link its information to any and all Wikipedias. No longer English
only, but every Wikipedia will be exposed in this way.
  * Freebase, SEO and Wikidata




Hmm... German?


  * Office hour on IRC covering overall status/development, Freebase
and admin inactivity criteria RfC. You can read the log

.


  Other Noteworthy Stuff

  * Magnus wrote a short tour of Wikidata's tool ecosystem
.
  * A first version of the Primary Sources Tool has been released
.
It'll help with migrating Freebase data and more.
  * Italian Wikipedia's quality festival


 is
focusing on interwiki links and Wikidata this month. Help them out?
  * Lots of new databases have been added to Mix n Match
.
  * Screenshots of the current state of new constraint reports and
checks against 3rd party databases have been posted.



  Did you know?

  * Newest properties: choreographer
, senat.fr ID
, Great Aragonese
Encyclopedia ID 


  Development

  * Wikidata development started 3 years ago
. <3 to
everyone who is a part of it.
  * Went through all the feedback we got for improving watchlist
integration on Wikipedia and co and posted our assesment


  * Put the infrastructure for creating Turtle
-Beta dumps in
place. All new Wikidata dumps will be in
https://dumps.wikimedia.org/wikidatawiki/entities/ from Monday on
(the old * directory will be kept around and receive new json
dumps for backwards compatibility).
  * Reduced size of entities pages by removing no longer needed data
(to make the UI faster).
  * Fixed bug that sometimes caused dates and other types of values to
be cut short when quickly saving. (phabricator:T92831
)
  * Fixed issues with setting focus after clicking edit.

You can see all open bugs related to Wikidata here 
.



  Monthly Tasks

  * Hack on one of these
.
  * Help fix these items
 which
have been flagged using Wikidata - The Game.
  * Help develop the next summary here!

  * Contribute to a Showcase item

  * Help translate
 or proofread
pages in your own language!



___
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: [Wikidata-l] Wikidata periodic table

[Ricordisamoa]

Forgot: the code is formally under review here 
. GPL-3.0+ as the old WikiPeriod.


Il 08/04/2015 01:18, Ricordisamoa ha scritto:
I'd like to announce a new Labs tool to show a periodic table 
.
It is based on WikiPeriod's PHP code (in turn ported from JavaScript) 
and features several improvements:


  * 'tiles' are wider and taller;
  * most of them are now provided with a background color (the same as
Wikipedia's

)
based on the elements' "subclass of" property
 (the same that
powers period/group detection);
  * for labels, Wikidata's built-in language fallback is used instead
of just falling back to English;
  * a public JSON API  is
available for everyone!

And some more under the hood:

  * rewritten in Python with Jinja2:
  o more object-oriented
  o presentation is split from actual logic
  o less vulnerable to XSS attacks
  * a LRU (least recently used) cache with a maximum TTL (per-item
time-to-live) value of 6 hours is used to avoid hitting data
sources on every request;
  * both the Wikidata API and Wikidata Query can be used
interchangeably as sources.

I had to create some items such as Q19753344 
 and Q19753345 
 to properly categorize 
elements. My knowledge of chemistry is limited, so please report/fix 
every mistake you can find ;-)


Future plans include:

  * oxidation state
  * images
  * responsive design
  * alternative table structures

___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

[Wikidata-l] Wikidata periodic table

[Ricordisamoa]

I'd like to announce a new Labs tool to show a periodic table 
.
It is based on WikiPeriod's PHP code (in turn ported from JavaScript) 
and features several improvements:


 * 'tiles' are wider and taller;
 * most of them are now provided with a background color (the same as
   Wikipedia's
   
)
   based on the elements' "subclass of" property
    (the same that powers
   period/group detection);
 * for labels, Wikidata's built-in language fallback is used instead of
   just falling back to English;
 * a public JSON API  is
   available for everyone!

And some more under the hood:

 * rewritten in Python with Jinja2:
 o more object-oriented
 o presentation is split from actual logic
 o less vulnerable to XSS attacks
 * a LRU (least recently used) cache with a maximum TTL (per-item
   time-to-live) value of 6 hours is used to avoid hitting data sources
   on every request;
 * both the Wikidata API and Wikidata Query can be used interchangeably
   as sources.

I had to create some items such as Q19753344 
 and Q19753345 
 to properly categorize 
elements. My knowledge of chemistry is limited, so please report/fix 
every mistake you can find ;-)


Future plans include:

 * oxidation state
 * images
 * responsive design
 * alternative table structures

___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] Data templates

[Ricordisamoa]

Il 07/04/2015 15:21, Valentine Charles ha scritto:

Hello,

Yes I might not use the right term here especially if you use it 
already in a different context. What I mean is that it would be good 
to have list of properties that can be used for a given thing. For 
instance if you want to describe a painting here the list of 
properties you can use.


User:Magnus Manske/missing props.js 
 has 
some lists for that (look for "Potential properties").


https://www.wikidata.org/wiki/Wikidata:WikiProject_sum_of_all_paintings points 
to a page listing some properties that can be used for painting but 
not all of them.


Best,
Valentine
___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

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

[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
> 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: [Wikidata-l] External identifiers vs. Wikidata-internal links & data

[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
> 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: [Wikidata-l] External identifiers vs. Wikidata-internal links & data

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

Re: [Wikidata-l] Data templates

[Jane Darnell]

Well probably not, as it is an ongoing project. You can post questions
there however on the talk page that are more likely to generate useful
answers for you than this list. Most Wikidatans involved there don't speak
English as a first language and I don't think they are frequent readers of
this mailing list. For specific questions on properties for paintings, I
believe you can best look at the Wikidata items for the Mona Lisa and
Vermeer's "Milkmaid" aka "The Yellow Kitchenmaid"

On Tue, Apr 7, 2015 at 3:21 PM, Valentine Charles 
wrote:

> Hello,
>
> Yes I might not use the right term here especially if you use it already
> in a different context. What I mean is that it would be good to have list
> of properties that can be used for a given thing. For instance if you want
> to describe a painting here the list of properties you can use.
> https://www.wikidata.org/wiki/Wikidata:WikiProject_sum_of_all_paintings points
> to a page listing some properties that can be used for painting but not all
> of them.
>
> Best,
> Valentine
>
> 2015-04-07 15:15 GMT+02:00 Daniel Kinzler :
>
>>
>> I'm confused by your use of the term "template" here. In the context of
>> MediaWiki, "template" refers to a bit of wikitext that can be
>> parametrized and
>> re-used, e.g. to make info-boxes.
>>
>> If I understand correctly, what you mean is a kind of schema saying which
>> properties can and should be present on items of which type. The Wikibase
>> software has no concept of such schemas, on Wikidata such schemas are
>> defined
>> and enforced by convention only.
>>
>> For the sake of clarity, I suggest to use the term "schema convention"
>> for this,
>> to avoid confusion with wikitext templates.
>>
>> Am 07.04.2015 um 13:12 schrieb Valentine Charles:
>> > Hello,
>> >
>> > I wanted to get an overview of all the properties used boy the instance
>> Painting
>> > (https://www.wikidata.org/wiki/Q3305213) for further mapping with the
>> Europeana
>> > Data Model.
>> > My initial thought that I would find a representative list
>> > at
>> http://www.wikidata.org/wiki/Wikidata:WikiProject_Visual_arts/Item_structure
>> > but in fact I have found much more properties used in association with
>> painting.
>> > So I was wondering whether it would be a good idea to update the
>> template
>> > mentioned above with the additional properties.
>> > I think it would be really interesting for GLAMs to have access to to
>> > representative templates listing all the properties used for a given
>> type of
>> > objects. It would help them to understand Wikidata and to compare it
>> with their
>> > own data. I think it would also help mappings activities. I on behalf of
>> > Europeana would be happy to help in this task and also facilitate the
>> > discussions with GLAMs around Wikidata.
>> >
>> > What do you think?
>> >
>> > Best wishes,
>> > Valentine
>> >
>> > 2015-04-04 23:45 GMT+02:00 Stas Malyshev > > >:
>> >
>> > Hi!
>> >
>> > > For things that actually *are* free text, and not terribly long,
>> a monolongual
>> > > (or, in the future, multilingual) text property could be used.
>> "quote" already
>> > > exists, "abstract" could be added, pending community discussion.
>> Length
>> > > limitations can be adjusted if need be.
>> >
>> > Maybe if the need of bigger texts arises we can have separate field
>> > type? Right now the storage model is not very good for storing
>> texts of
>> > non-negligible sizes, especially multilingual ones (x800 languages).
>> > OTOH, we have a type that allows us to use multimedia by integrating
>> > with Commons. So maybe the same idea with using some other wiki -
>> > quotes? sources? for bigger text snippets would work too? Just
>> > brainstorming here :)
>> >
>> > > What I was warning against is continuing the misuse of text
>> fields for
>> > > semi-structured or even fully structured data that I have often
>> seen in GLAM
>> > > meta-data. That kind of thing should not be copied to Wikidata.
>> >
>> > Right. I think it may be useful here to understand which kinds of
>> text
>> > we're talking about which can't be structured but are big enough to
>> > cause concern. I.e. if it's quotes - we already have wikiquote,
>> right? Etc.
>> >
>> > --
>> > Stas Malyshev
>> > smalys...@wikimedia.org 
>> >
>> > ___
>> > Wikidata-l mailing list
>> > Wikidata-l@lists.wikimedia.org > 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
>> >
>>
>>
>> --
>> Daniel Kinzler
>> Senior Software Developer
>>
>> Wikimedia Deutschland
>> Gesellschaft zur Förderung Freien Wissens e.V.
>>
>> _

Re: [Wikidata-l] Data templates

[Valentine Charles]

Hello,

Yes I might not use the right term here especially if you use it already in
a different context. What I mean is that it would be good to have list of
properties that can be used for a given thing. For instance if you want to
describe a painting here the list of properties you can use.
https://www.wikidata.org/wiki/Wikidata:WikiProject_sum_of_all_paintings points
to a page listing some properties that can be used for painting but not all
of them.

Best,
Valentine

2015-04-07 15:15 GMT+02:00 Daniel Kinzler :

>
> I'm confused by your use of the term "template" here. In the context of
> MediaWiki, "template" refers to a bit of wikitext that can be parametrized
> and
> re-used, e.g. to make info-boxes.
>
> If I understand correctly, what you mean is a kind of schema saying which
> properties can and should be present on items of which type. The Wikibase
> software has no concept of such schemas, on Wikidata such schemas are
> defined
> and enforced by convention only.
>
> For the sake of clarity, I suggest to use the term "schema convention" for
> this,
> to avoid confusion with wikitext templates.
>
> Am 07.04.2015 um 13:12 schrieb Valentine Charles:
> > Hello,
> >
> > I wanted to get an overview of all the properties used boy the instance
> Painting
> > (https://www.wikidata.org/wiki/Q3305213) for further mapping with the
> Europeana
> > Data Model.
> > My initial thought that I would find a representative list
> > at
> http://www.wikidata.org/wiki/Wikidata:WikiProject_Visual_arts/Item_structure
> > but in fact I have found much more properties used in association with
> painting.
> > So I was wondering whether it would be a good idea to update the template
> > mentioned above with the additional properties.
> > I think it would be really interesting for GLAMs to have access to to
> > representative templates listing all the properties used for a given
> type of
> > objects. It would help them to understand Wikidata and to compare it
> with their
> > own data. I think it would also help mappings activities. I on behalf of
> > Europeana would be happy to help in this task and also facilitate the
> > discussions with GLAMs around Wikidata.
> >
> > What do you think?
> >
> > Best wishes,
> > Valentine
> >
> > 2015-04-04 23:45 GMT+02:00 Stas Malyshev  > >:
> >
> > Hi!
> >
> > > For things that actually *are* free text, and not terribly long, a
> monolongual
> > > (or, in the future, multilingual) text property could be used.
> "quote" already
> > > exists, "abstract" could be added, pending community discussion.
> Length
> > > limitations can be adjusted if need be.
> >
> > Maybe if the need of bigger texts arises we can have separate field
> > type? Right now the storage model is not very good for storing texts
> of
> > non-negligible sizes, especially multilingual ones (x800 languages).
> > OTOH, we have a type that allows us to use multimedia by integrating
> > with Commons. So maybe the same idea with using some other wiki -
> > quotes? sources? for bigger text snippets would work too? Just
> > brainstorming here :)
> >
> > > What I was warning against is continuing the misuse of text fields
> for
> > > semi-structured or even fully structured data that I have often
> seen in GLAM
> > > meta-data. That kind of thing should not be copied to Wikidata.
> >
> > Right. I think it may be useful here to understand which kinds of
> text
> > we're talking about which can't be structured but are big enough to
> > cause concern. I.e. if it's quotes - we already have wikiquote,
> right? Etc.
> >
> > --
> > Stas Malyshev
> > smalys...@wikimedia.org 
> >
> > ___
> > Wikidata-l mailing list
> > Wikidata-l@lists.wikimedia.org  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
> >
>
>
> --
> Daniel Kinzler
> Senior Software Developer
>
> Wikimedia Deutschland
> Gesellschaft zur Förderung Freien Wissens e.V.
>
> ___
> 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: [Wikidata-l] Data templates

[Daniel Kinzler]

I'm confused by your use of the term "template" here. In the context of
MediaWiki, "template" refers to a bit of wikitext that can be parametrized and
re-used, e.g. to make info-boxes.

If I understand correctly, what you mean is a kind of schema saying which
properties can and should be present on items of which type. The Wikibase
software has no concept of such schemas, on Wikidata such schemas are defined
and enforced by convention only.

For the sake of clarity, I suggest to use the term "schema convention" for this,
to avoid confusion with wikitext templates.

Am 07.04.2015 um 13:12 schrieb Valentine Charles:
> Hello, 
> 
> I wanted to get an overview of all the properties used boy the instance 
> Painting
> (https://www.wikidata.org/wiki/Q3305213) for further mapping with the 
> Europeana
> Data Model. 
> My initial thought that I would find a representative list
> at 
> http://www.wikidata.org/wiki/Wikidata:WikiProject_Visual_arts/Item_structure
> but in fact I have found much more properties used in association with 
> painting.
> So I was wondering whether it would be a good idea to update the template
> mentioned above with the additional properties.
> I think it would be really interesting for GLAMs to have access to to
> representative templates listing all the properties used for a given type of
> objects. It would help them to understand Wikidata and to compare it with 
> their
> own data. I think it would also help mappings activities. I on behalf of
> Europeana would be happy to help in this task and also facilitate the
> discussions with GLAMs around Wikidata. 
> 
> What do you think? 
> 
> Best wishes, 
> Valentine 
> 
> 2015-04-04 23:45 GMT+02:00 Stas Malyshev  >:
> 
> Hi!
> 
> > For things that actually *are* free text, and not terribly long, a 
> monolongual
> > (or, in the future, multilingual) text property could be used. "quote" 
> already
> > exists, "abstract" could be added, pending community discussion. Length
> > limitations can be adjusted if need be.
> 
> Maybe if the need of bigger texts arises we can have separate field
> type? Right now the storage model is not very good for storing texts of
> non-negligible sizes, especially multilingual ones (x800 languages).
> OTOH, we have a type that allows us to use multimedia by integrating
> with Commons. So maybe the same idea with using some other wiki -
> quotes? sources? for bigger text snippets would work too? Just
> brainstorming here :)
> 
> > What I was warning against is continuing the misuse of text fields for
> > semi-structured or even fully structured data that I have often seen in 
> GLAM
> > meta-data. That kind of thing should not be copied to Wikidata.
> 
> Right. I think it may be useful here to understand which kinds of text
> we're talking about which can't be structured but are big enough to
> cause concern. I.e. if it's quotes - we already have wikiquote, right? 
> Etc.
> 
> --
> Stas Malyshev
> smalys...@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
> 


-- 
Daniel Kinzler
Senior Software Developer

Wikimedia Deutschland
Gesellschaft zur Förderung Freien Wissens e.V.

___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] Data templates

[Jane Darnell]

For paintings you can better look here:
https://www.wikidata.org/wiki/Wikidata:WikiProject_sum_of_all_paintings

On Tue, Apr 7, 2015 at 1:12 PM, Valentine Charles 
wrote:

> Hello,
>
> I wanted to get an overview of all the properties used boy the instance
> Painting (https://www.wikidata.org/wiki/Q3305213) for further mapping
> with the Europeana Data Model.
> My initial thought that I would find a representative list at
> http://www.wikidata.org/wiki/Wikidata:WikiProject_Visual_arts/Item_structure
> but in fact I have found much more properties used in association with
> painting. So I was wondering whether it would be a good idea to update the
> template mentioned above with the additional properties.
> I think it would be really interesting for GLAMs to have access to to
> representative templates listing all the properties used for a given type
> of objects. It would help them to understand Wikidata and to compare it
> with their own data. I think it would also help mappings activities. I on
> behalf of Europeana would be happy to help in this task and also facilitate
> the discussions with GLAMs around Wikidata.
>
> What do you think?
>
> Best wishes,
> Valentine
>
> 2015-04-04 23:45 GMT+02:00 Stas Malyshev :
>
>> Hi!
>>
>> > For things that actually *are* free text, and not terribly long, a
>> monolongual
>> > (or, in the future, multilingual) text property could be used. "quote"
>> already
>> > exists, "abstract" could be added, pending community discussion. Length
>> > limitations can be adjusted if need be.
>>
>> Maybe if the need of bigger texts arises we can have separate field
>> type? Right now the storage model is not very good for storing texts of
>> non-negligible sizes, especially multilingual ones (x800 languages).
>> OTOH, we have a type that allows us to use multimedia by integrating
>> with Commons. So maybe the same idea with using some other wiki -
>> quotes? sources? for bigger text snippets would work too? Just
>> brainstorming here :)
>>
>> > What I was warning against is continuing the misuse of text fields for
>> > semi-structured or even fully structured data that I have often seen in
>> GLAM
>> > meta-data. That kind of thing should not be copied to Wikidata.
>>
>> Right. I think it may be useful here to understand which kinds of text
>> we're talking about which can't be structured but are big enough to
>> cause concern. I.e. if it's quotes - we already have wikiquote, right?
>> Etc.
>>
>> --
>> Stas Malyshev
>> smalys...@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
>
>
___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] Data templates

[Valentine Charles]

Hello,

I wanted to get an overview of all the properties used boy the instance
Painting (https://www.wikidata.org/wiki/Q3305213) for further mapping with
the Europeana Data Model.
My initial thought that I would find a representative list at
http://www.wikidata.org/wiki/Wikidata:WikiProject_Visual_arts/Item_structure
but in fact I have found much more properties used in association with
painting. So I was wondering whether it would be a good idea to update the
template mentioned above with the additional properties.
I think it would be really interesting for GLAMs to have access to to
representative templates listing all the properties used for a given type
of objects. It would help them to understand Wikidata and to compare it
with their own data. I think it would also help mappings activities. I on
behalf of Europeana would be happy to help in this task and also facilitate
the discussions with GLAMs around Wikidata.

What do you think?

Best wishes,
Valentine

2015-04-04 23:45 GMT+02:00 Stas Malyshev :

> Hi!
>
> > For things that actually *are* free text, and not terribly long, a
> monolongual
> > (or, in the future, multilingual) text property could be used. "quote"
> already
> > exists, "abstract" could be added, pending community discussion. Length
> > limitations can be adjusted if need be.
>
> Maybe if the need of bigger texts arises we can have separate field
> type? Right now the storage model is not very good for storing texts of
> non-negligible sizes, especially multilingual ones (x800 languages).
> OTOH, we have a type that allows us to use multimedia by integrating
> with Commons. So maybe the same idea with using some other wiki -
> quotes? sources? for bigger text snippets would work too? Just
> brainstorming here :)
>
> > What I was warning against is continuing the misuse of text fields for
> > semi-structured or even fully structured data that I have often seen in
> GLAM
> > meta-data. That kind of thing should not be copied to Wikidata.
>
> Right. I think it may be useful here to understand which kinds of text
> we're talking about which can't be structured but are big enough to
> cause concern. I.e. if it's quotes - we already have wikiquote, right? Etc.
>
> --
> Stas Malyshev
> smalys...@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