Re: [Wikidata-l] Wikidata CACM article (Was: Conflict of Interest policy for Wikidata)

[Markus Krötzsch]

On 08.01.2015 18:38, Denny Vrandečić wrote:

Yes, CC-BY is great.


Good. I have officially released the article text under this license now:

https://korrekt.org/page/Wikidata:_A_Free_Collaborative_Knowledgebase

Cheers,

Markus



On Thu Jan 08 2015 at 7:01:12 AM Markus Krötzsch
mailto:mar...@semantic-mediawiki.org>>
wrote:

On 08.01.2015 15:10, ja...@j1w.xyz wrote:
 > Prior to viewing Markus Krötzsch's Wikidata page, I was unaware
of the
 > "Wikidata: A Free Collaborative Knowledgebase" article [1] written by
 > Denny Vrandečić and Markus Krötzsch.  This is a very helpful article
 > that in my opinion should be featured on the Wikidata main page.

Glad you liked it. Checking the Wikidata item, I notice that it is
actually Open Access and not "all rights reserved". It is available for
free ("forever") from the ACM [1], but it seems they do not define any
license. However, as we have retained all the rights, we can do what we
like there.

Denny, shall we use CC-BY?

Markus

[1]
http://cacm.acm.org/magazines/__2014/10/178785-wikidata/__fulltext



 >
 > [1]
http://cacm.acm.org/magazines/__2014/10/178785-wikidata/__fulltext

 >
 > Regards,
 > James Weaver
 >
 > On Wed, Jan 7, 2015, at 05:14 PM, Markus Krötzsch wrote:
 >> Irrespective of the general policy discussion, I have now been
bold and
 >> changed my item and user page to record that relationship as by my
 >> earlier suggestion (as copied below):
 >>
 >> https://www.wikidata.org/wiki/__Q18618630

 >>
 >> I was wondering if, given that we have single signon, "website
account
 >> on" should point to "Wikidata" or to "Wikimedia" or something
else. But
 >> besides this minor point this seems to be a nice way to have COI
 >> declarations in the data (would also be interesting to know
which living
 >> people have official Wikimedia accounts).
 >>
 >> Cheers,
 >>
 >> Markus
 >>
 >> On 07.01.2015 15:25, Markus Krötzsch wrote:
 >> ...
 >>>
 >>> In addition, there should be a template that one can use on
one's user
 >>> page to disclose that one is the person described in a certain
item.
 >>> Conversely, we should also use our "website account on"
property (P553)
 >>> to connect living people to their Wikidata user account, so the
COI is
 >>> recorded in the data. One could further disclose other COIs on
one's
 >>> user page in some standard format, but maybe with Wikidata we could
 >>> actually derive such COIs automatically (your family members, the
 >>> companies you founded, the university you graduated from, etc.
can all
 >>> be specified in data).
 >>>
 >>> Cheers,
 >>>
 >>> Markus
 >>>
 >>>
 >>
 >> _
 >> 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




___
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] Freebase's incompatible types and Property description permissions

[Markus Krötzsch]

On 09.01.2015 00:53, Lydia Pintscher wrote:
...


I like the property-centric approach of wikidata, but is there a notion of
subproperties for contextual refinement?  I only found this:

https://www.wikidata.org/wiki/Property:P1647


Yes that is all there is. For a usage example see
https://www.wikidata.org/wiki/Property:P9 (The value is currently not
linked in that statement. That will be fixed with the next deployment
next week.)


Yes, and using subproperty relationships in queries etc. is a next step 
(we only have had statements on property pages for a few weeks now ...). 
I fully agree that this will make many modelling issues easier to handle 
(a very broad relationship "associated with country" can be a 
subperproperty of more specific relations like "had first public 
performance in country" (for bands), so one can have a clear meaning as 
well as broad coverage.


However, other related issues occur in many places, even without 
properties and classes involved. For example, we have many occupations, 
but there is no reasoning to relate broader occupations to more specific 
ones when used as values of the "occupation" property (Catholic priests 
are priest; computer scientists are researchers; etc. -- right now it 
seems one would have to state all of these, since there is no way of 
saying that the occupation property should be transitive over the 
subclass of property). We have only just started to use the most basic 
schema-level modelling in Wikidata so far, but we need to take one step 
after the other.


Markus


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

Re: [Wikidata-l] Freebase's incompatible types and Property description permissions

[Markus Krötzsch]

On 08.01.2015 22:52, Peter F. Patel-Schneider wrote:

What then is P17 supposed to be used for?

Could, I, for example, use P17 on the address of the Swiss embassy in
Germany and have Switzerland as the value?

"associated" is generally too weak a word to use in describing properties.


We have to be careful not to generalise too far from the original 
example in this thread (bands). I think you cannot say many formal 
things about the country of a band, but it's different with other types 
of objects that may have a country.


This could mean that one will need different descriptions for the 
meaning of P17 with embassies and bands. Seems plausible. (And it would 
bring in some Freebase-like type-based rationale into the system as well 
-- maybe a nice conclusion for this part of the discussion).


In general, I don't think one can discuss such things in general ;-). 
Every individual domain has to be looked at by experts who know what is 
reasonable there and what is confusing/too vague/too specific to work.


Markus




On 01/08/2015 01:46 PM, Thad Guidry wrote:

Markus,

Devils in the details. =)

You used the English word "associated".  That's great.  Then I would
propose
to expand the definition of P17 just a bit to add that.

P17 Country - sovereign state of this item ... to ... sovereign state
ASSOCIATED with this item

Then you save the world. =)

Thoughts ? Agreement ?

Secondly, the Description: (Description :colon:  on the Discussion page
https://www.wikidata.org/wiki/Property_talk:P17) is defining a
Country... not
the description of the Country __Property__..which is the line just
above it.
How is the Description :colon: line supposed to work or be really used
for ?
Seems like the Description :colon: line is basically describing the
Represents
:colon: line lol.
Very confusing.

Thad
+ThadGuidry 



___
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] Freebase's incompatible types and Property description permissions

[Daniel Kinzler]

Am 08.01.2015 21:52, schrieb Peter F. Patel-Schneider:
> What then is P17 supposed to be used for?
> 
> Could, I, for example, use P17 on the address of the Swiss embassy in Germany
> and have Switzerland as the value?

You could use P17 that way on the item about the Swiss embassy in Germany. I
don't think we want to have an item about the *address* of the embassy. If we
did, the country "of" the address would probably be Germany (even if the
embaqssy is technically Swiss territory).

-- 
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] Freebase's incompatible types and Property description permissions

[Joe Filceolaire]

First:
A band is an organisation, not a person.

Second
P17 is deliberately a bit ambiguous so it can be used for those cases where
we don't have specific info. We also have specific properties for those
cases where we have specific info.

We can have an architect born in Germany who spent most of his career in
Lithuania and is one of their most prominent architects.

We can have an Irish band playing traditional Irish ballads who have only
worked in the USA for the last 20 years and are almost unknown in Ireland.

Joe
On 8 Jan 2015 23:07, "Paul Houle"  wrote:

> There is the cultural factor here that Freebase took an approach which is
> very similar to the RDFS approach in that they like the idea of defining
> separate properties like
>
> :HumanBirthDate
> :HorseBirthDate
> :DogBirthDate
>
> You can then treat these as subproperties of :AnimalBirthDate which is in
> turn a subproperty of :StartDate,  or something like that.
>
> Freebase has a metaschema that does this sort of aggregation
>
> https://developers.google.com/freebase/v1/search-metaschema
>
> To a system designer who puts economy and simplicity first,  there is
> something maddening about how Freebase defines separate types for "Film
> Actor",  "TV Actor" and "Theatre Actor",  since you might think an actor is
> just an actor and that the property to say an actor appeared in a film is
> almost the same as saying actor appeared in a TV episode;  look deeper of
> course and you find different modelling needs.  For instance there is a big
> difference between a TV actor with a recurring role and a TV actor who
> appears in one episode,  etc.
>
> I think Freebase approached it this way because they had the idea of it
> being divided into separate "bases" which can managed separately;  this
> means you get vocabulary tuned to each domain rather than somebody figuring
> out the grand scheme ahead of time.
>
>
> On Thu, Jan 8, 2015 at 4:52 PM, Peter F. Patel-Schneider <
> pfpschnei...@gmail.com> wrote:
>
>> What then is P17 supposed to be used for?
>>
>> Could, I, for example, use P17 on the address of the Swiss embassy in
>> Germany and have Switzerland as the value?
>>
>> "associated" is generally too weak a word to use in describing properties.
>>
>> peter
>>
>>
>> On 01/08/2015 01:46 PM, Thad Guidry wrote:
>>
>>> Markus,
>>>
>>> Devils in the details. =)
>>>
>>> You used the English word "associated".  That's great.  Then I would
>>> propose
>>> to expand the definition of P17 just a bit to add that.
>>>
>>> P17 Country - sovereign state of this item ... to ... sovereign state
>>> ASSOCIATED with this item
>>>
>>> Then you save the world. =)
>>>
>>> Thoughts ? Agreement ?
>>>
>>> Secondly, the Description: (Description :colon:  on the Discussion page
>>> https://www.wikidata.org/wiki/Property_talk:P17) is defining a
>>> Country... not
>>> the description of the Country __Property__..which is the line just
>>> above it.
>>> How is the Description :colon: line supposed to work or be really used
>>> for ?
>>> Seems like the Description :colon: line is basically describing the
>>> Represents
>>> :colon: line lol.
>>> Very confusing.
>>>
>>> Thad
>>> +ThadGuidry 
>>>
>>>
>>>
>>> ___
>>> 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
>>
>
>
>
> --
> Paul Houle
> Expert on Freebase, DBpedia, Hadoop and RDF
> (607) 539 6254paul.houle on Skype   ontolo...@gmail.com
> http://legalentityidentifier.info/lei/lookup
>
> ___
> 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] Freebase's incompatible types and Property description permissions

[Lydia Pintscher]

On Fri, Jan 9, 2015 at 12:43 AM, Jason Douglas  wrote:
> Having worked at Metaweb/Google on Freebase, I'd be one of the first to
> admit that Freebase's types conflate too many concepts as they were both
> used for "Is A" class assertions and to group properties that were
> frequently edited together (in the UI) and for more contextual descriptions
> and for...
>
> Over time, the class use was mostly abandoned for reasons like Paule's actor
> example.
>
> I like the property-centric approach of wikidata, but is there a notion of
> subproperties for contextual refinement?  I only found this:
>
> https://www.wikidata.org/wiki/Property:P1647

Yes that is all there is. For a usage example see
https://www.wikidata.org/wiki/Property:P9 (The value is currently not
linked in that statement. That will be fixed with the next deployment
next week.)


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] Freebase's incompatible types and Property description permissions

[Jason Douglas]

Having worked at Metaweb/Google on Freebase, I'd be one of the first to
admit that Freebase's types conflate too many concepts as they were both
used for "Is A" class assertions and to group properties that were
frequently edited together (in the UI) and for more contextual descriptions
and for...

Over time, the class use was mostly abandoned for reasons like Paule's
actor example.

I like the property-centric approach of wikidata, but is there a notion of
subproperties for contextual refinement?  I only found this:

https://www.wikidata.org/wiki/Property:P1647

-jason


On Thu Jan 08 2015 at 3:07:47 PM Paul Houle  wrote:

> There is the cultural factor here that Freebase took an approach which is
> very similar to the RDFS approach in that they like the idea of defining
> separate properties like
>
> :HumanBirthDate
> :HorseBirthDate
> :DogBirthDate
>
> You can then treat these as subproperties of :AnimalBirthDate which is in
> turn a subproperty of :StartDate,  or something like that.
>
> Freebase has a metaschema that does this sort of aggregation
>
> https://developers.google.com/freebase/v1/search-metaschema
>
> To a system designer who puts economy and simplicity first,  there is
> something maddening about how Freebase defines separate types for "Film
> Actor",  "TV Actor" and "Theatre Actor",  since you might think an actor is
> just an actor and that the property to say an actor appeared in a film is
> almost the same as saying actor appeared in a TV episode;  look deeper of
> course and you find different modelling needs.  For instance there is a big
> difference between a TV actor with a recurring role and a TV actor who
> appears in one episode,  etc.
>
> I think Freebase approached it this way because they had the idea of it
> being divided into separate "bases" which can managed separately;  this
> means you get vocabulary tuned to each domain rather than somebody figuring
> out the grand scheme ahead of time.
>
>
> On Thu, Jan 8, 2015 at 4:52 PM, Peter F. Patel-Schneider <
> pfpschnei...@gmail.com> wrote:
>
>> What then is P17 supposed to be used for?
>>
>> Could, I, for example, use P17 on the address of the Swiss embassy in
>> Germany and have Switzerland as the value?
>>
>> "associated" is generally too weak a word to use in describing properties.
>>
>> peter
>>
>>
>> On 01/08/2015 01:46 PM, Thad Guidry wrote:
>>
>>> Markus,
>>>
>>> Devils in the details. =)
>>>
>>> You used the English word "associated".  That's great.  Then I would
>>> propose
>>> to expand the definition of P17 just a bit to add that.
>>>
>>> P17 Country - sovereign state of this item ... to ... sovereign state
>>> ASSOCIATED with this item
>>>
>>> Then you save the world. =)
>>>
>>> Thoughts ? Agreement ?
>>>
>>> Secondly, the Description: (Description :colon:  on the Discussion page
>>> https://www.wikidata.org/wiki/Property_talk:P17) is defining a
>>> Country... not
>>> the description of the Country __Property__..which is the line just
>>> above it.
>>> How is the Description :colon: line supposed to work or be really used
>>> for ?
>>> Seems like the Description :colon: line is basically describing the
>>> Represents
>>> :colon: line lol.
>>> Very confusing.
>>>
>>> Thad
>>> +ThadGuidry 
>>>
>>>
>>>
>>> ___
>>> 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
>>
>
>
>
> --
> Paul Houle
> Expert on Freebase, DBpedia, Hadoop and RDF
> (607) 539 6254paul.houle on Skype   ontolo...@gmail.com
> http://legalentityidentifier.info/lei/lookup
>  ___
> 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] Freebase's incompatible types and Property description permissions

[Paul Houle]

There is the cultural factor here that Freebase took an approach which is
very similar to the RDFS approach in that they like the idea of defining
separate properties like

:HumanBirthDate
:HorseBirthDate
:DogBirthDate

You can then treat these as subproperties of :AnimalBirthDate which is in
turn a subproperty of :StartDate,  or something like that.

Freebase has a metaschema that does this sort of aggregation

https://developers.google.com/freebase/v1/search-metaschema

To a system designer who puts economy and simplicity first,  there is
something maddening about how Freebase defines separate types for "Film
Actor",  "TV Actor" and "Theatre Actor",  since you might think an actor is
just an actor and that the property to say an actor appeared in a film is
almost the same as saying actor appeared in a TV episode;  look deeper of
course and you find different modelling needs.  For instance there is a big
difference between a TV actor with a recurring role and a TV actor who
appears in one episode,  etc.

I think Freebase approached it this way because they had the idea of it
being divided into separate "bases" which can managed separately;  this
means you get vocabulary tuned to each domain rather than somebody figuring
out the grand scheme ahead of time.


On Thu, Jan 8, 2015 at 4:52 PM, Peter F. Patel-Schneider <
pfpschnei...@gmail.com> wrote:

> What then is P17 supposed to be used for?
>
> Could, I, for example, use P17 on the address of the Swiss embassy in
> Germany and have Switzerland as the value?
>
> "associated" is generally too weak a word to use in describing properties.
>
> peter
>
>
> On 01/08/2015 01:46 PM, Thad Guidry wrote:
>
>> Markus,
>>
>> Devils in the details. =)
>>
>> You used the English word "associated".  That's great.  Then I would
>> propose
>> to expand the definition of P17 just a bit to add that.
>>
>> P17 Country - sovereign state of this item ... to ... sovereign state
>> ASSOCIATED with this item
>>
>> Then you save the world. =)
>>
>> Thoughts ? Agreement ?
>>
>> Secondly, the Description: (Description :colon:  on the Discussion page
>> https://www.wikidata.org/wiki/Property_talk:P17) is defining a
>> Country... not
>> the description of the Country __Property__..which is the line just above
>> it.
>> How is the Description :colon: line supposed to work or be really used
>> for ?
>> Seems like the Description :colon: line is basically describing the
>> Represents
>> :colon: line lol.
>> Very confusing.
>>
>> Thad
>> +ThadGuidry 
>>
>>
>>
>> ___
>> 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
>



-- 
Paul Houle
Expert on Freebase, DBpedia, Hadoop and RDF
(607) 539 6254paul.houle on Skype   ontolo...@gmail.com
http://legalentityidentifier.info/lei/lookup
___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] Freebase's incompatible types and Property description permissions

[Peter F. Patel-Schneider]

What then is P17 supposed to be used for?

Could, I, for example, use P17 on the address of the Swiss embassy in Germany 
and have Switzerland as the value?


"associated" is generally too weak a word to use in describing properties.

peter


On 01/08/2015 01:46 PM, Thad Guidry wrote:

Markus,

Devils in the details. =)

You used the English word "associated".  That's great.  Then I would propose
to expand the definition of P17 just a bit to add that.

P17 Country - sovereign state of this item ... to ... sovereign state
ASSOCIATED with this item

Then you save the world. =)

Thoughts ? Agreement ?

Secondly, the Description: (Description :colon:  on the Discussion page
https://www.wikidata.org/wiki/Property_talk:P17) is defining a Country... not
the description of the Country __Property__..which is the line just above it.
How is the Description :colon: line supposed to work or be really used for ?
Seems like the Description :colon: line is basically describing the Represents
:colon: line lol.
Very confusing.

Thad
+ThadGuidry 



___
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] Freebase's incompatible types and Property description permissions

[Thad Guidry]

Markus,

Devils in the details. =)

You used the English word "associated".  That's great.  Then I would
propose to expand the definition of P17 just a bit to add that.

P17 Country - sovereign state of this item ... to ... sovereign state
ASSOCIATED with this item

Then you save the world. =)

Thoughts ? Agreement ?

Secondly, the Description: (Description :colon:  on the Discussion page
https://www.wikidata.org/wiki/Property_talk:P17) is defining a Country...
not the description of the Country __Property__..which is the line just
above it.
How is the Description :colon: line supposed to work or be really used for
?  Seems like the Description :colon: line is basically describing the
Represents :colon: line lol.
Very confusing.

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

Re: [Wikidata-l] Freebase's incompatible types and Property description permissions

[Ricordisamoa]

Il 08/01/2015 20:37, Thad Guidry ha scritto:


On Thu, Jan 8, 2015 at 12:17 PM, Federico Leva (Nemo) 
mailto:nemow...@gmail.com>> wrote:


Thad Guidry, 08/01/2015 18:58:

Unless the P17 Country property had an expanded definition of
"sovereign
state (or originating sovereign state) of this item"


That's more like P27. Both are rather flexible though, see their
talk pages.
https://www.wikidata.org/wiki/Property_talk:P17


1. How does Wikidata want to handle Property / Statement rule
enforcement and Freebase's incompatible types ?


I'm not sure how this is an example of "incompatible" type, it
sounds more like a type Freebase didn't have. Handling such
differences is possible by tweaking property descriptions and
adding constraints. P17 is already declared incompatible with
"instance of: human". If you make "music band" a subclass of
"human", then this statement about U2 will be reported by bots as
a constraint violation.


Right, Freebase would not stick a Property called "Country" right on 
an instance of a Music Band.  We would put Country under the Musical 
Group type, and give it a better definition like "The nation or 
territory that this item originated from".  Freebase's Properties 
always live under a Freebase Type, like "Musical Group".  Which is why 
on Wikidata, even seeing P17 on the U2 topic page makes me wonder what 
kind of schema Wikidata is trying to pull off.  But it appears that 
someone did not really read the description page of P17, like I just 
did, then they would see it just is not allowed like that, but instead 
should have used P27, but then you can't have a date of birth for a 
Musical Group (band), which voids using even P27 on an instance of band.


I understand, there are many holes in Wikidata's schema currently.  I 
am one of several Freebase experts coming over that can help Wikidata 
identify those problematic Schema. :-)



2. How does Wikidata want to handle locking down Property
descriptions
(Freebase uses Permissions and Owners), where the complete
meaning of
something being changed might cause severe wrongful polluted
data ?


There is no such thing in wikis.
http://c2.com/cgi/wiki?WikiDesignPrinciples
https://meta.wikimedia.org/wiki/The_wiki_way


But Wikidata is not a "wiki" in the true sense, or should not be 
purported as one Because it is not Schema-less, but in fact, 
prescribes to a publicly editable and agreed upon Schema model.


One thing I did notice is that the Wikidata Schema model is actually 
composed of both agreement on the 2 tabs of 
https://www.wikidata.org/wiki/Property_talk:P17  both the Property 
tab, AND the Discussions tabcombined...give the effective model of 
the Property...whereas in Freebase, we would just have the Property, 
where all rules and definitions about it are stored (Discussions about 
a Property were stored on our wiki and also our mailing list).  I 
enjoy the Wikidata way a bit more compared to Freebase, the benefit 
being a primary place to see the defines of the Property as well as 
the Discussion and questions about it in the past.


The errors are corrected after the fact; the central control
system is not made of permissions, but of checks like the
constraint violations bots mentioned above. What other pollutions
of the data you have in mind?


And that is my worry.  That the Schema model is publicly editable at 
any time.  And constraint violations are only effective against a 
"Well Defined Property".  But what if I do not Well Define that 
property, or worst, I completely change the meaning of that Property.  
Imagine if I suddenly change the meaning of one of your MySQL table 
columns... like, PERSON suddenly becomes FURNITURE. That can happen 
with Wikidata's publicly editable Schema modelif someone 
maliciously changes the description of that P17 Country to something 
very generic like "a state" oh really ?  What kind of state ?  
Nations only ? Or territories considered as an organized political 
community under one government.? or both ?  it appears that P17's 
Discussion clarifies this a bit, and defines it a bit more narrowly 
and would not allow just any territory with a political community.


We have the same problem in Freebase, where if by public agreement, we 
change the meaning of a Property so much that it might cause erroneous 
data statements, then we deprecate that Property and create a new one, 
splitting off the various statements into their proper form and 
letting the Community know, and also performing the data tasks to 
subscribe the old data to the new Schema.


The pollution of data would happen if by agreement P17's Discussion 
page drastically changed the intended meaning of it, then all the data 
that used P17 would need to be cleaned up.


How does Wikidata intend to deal with those kinds of changes to 
Property mea

Re: [Wikidata-l] Freebase's incompatible types and Property description permissions

[Markus Krötzsch]

On 08.01.2015 21:29, Thad Guidry wrote:

Hi Marcus!

Yes, you and I are on the same page.


I do indeed get this impression ;-)


Yes, I know about the
Property-first view of WIkidata.  No quibbles.  But there is still an
issue with Assumptions for "Country" P17 being used for an instance of
Band...so let's clarify this...

So, I guess things are fuzzy, because I do not jump to assumptions
beyond the meaning of P17 as it states on its Property or Discussion
page.  And the difference is that you are mentally performing a few
assumptions.  It is hard to train a computer to read your mind and
answer a question for you however.  :)  Its better to write those
assumptions (meanings) down somewhere.

Even for Freebase, we found that Properties had to be described very
well for all to understand their meaning with minimal ambiguity, and I
was a big proponent on Freebase to Google for better descriptions.

So, question since you understand the meaning of "Country" on the U2
page as you state... Can you please tell me that meaning...and then
let's see if we can transfer your knowledge to better improve P17
Property and its description.


For me this means "the band is associated with Ireland" (culturally, 
personally, originally). No deeper meaning. In most cases, it will also 
be true that the band has had its first public performance in this 
country and that (all) the band members are of that nationality, but 
this would be jumping to conclusions.


I fully agree with you that this is not very precise. My point is that 
it is still useful to have such broad relationships recorded, for 
example for browsing/filtering of data. Moreover, in this particular 
case I have doubts that narrower properties such as "had first public 
performance in" or "consists of band members that are nationals of" 
would be what people are looking for. Your original proposal of "country 
of origin" seems vague to me as well (what does this mean for a band? 
when does a band "originate"? do they always have an official time and 
place of being founded which is recorded somewhere? -- seems like we are 
just simulating a level of precision that does not exist in "reality").


An "Irish band" is not a mathematical term with an exact definition, but 
I can live with that, as long as we can find a reference that calls U2 
an "Irish band" it is valid for me as data.


I completely agree with you that detailed descriptions are very helpful 
-- you already need this to agree on what a "reference" for a claim is 
(and what isn't). Yet, this is different from narrowing down the use of 
a property to one special case. One can also allow for properties that 
are intentionally broad and approximate as long as this is documented 
clearly enough. In many cases, data with higher precision can be found 
anyway (for example, Wikidata should record the nationality of band 
members, and we could also capture the time and place of the first 
public appearance and the nationality of the record label of the first 
album etc.).


Best regards,

Markus





___
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] Freebase's incompatible types and Property description permissions

[Markus Krötzsch]

Dear Thad,

The second part of your email has good points in it, too. As you say, 
one must allow for adjustments in the intended meaning of a property in 
real life, and adjusting too much could be dangerous. The method you 
suggest (creating a new property and deprecating the old one, rather 
than modifying the meaning of the old one) has been used in Wikidata as 
well. Another thing that is very common in Wikidata are 
community-controlled mass edits: users offer to write conversion tools 
and the community decides how to use them. This can help to convert 
large amounts of data to a new format or to detect and cross-check 
errors. The constraint mechanism you see today is also a 
community-created way of avoiding unintended uses (be they caused by 
changed definitions or by other causes).


Finally, some basic things that you probably know already:

* Property datatypes in Wikidata cannot be changed after creation 
(ensuring that the data always remains structurally valid for this 
type). Technically speaking, this is the only "schema" we have (you 
mentioned SQL: things are similar there; the database schema does not 
include a definition of what you mean by the country column in the band 
table; at best it tells you that the country should be a key in the 
countries table).


* The experience with Wikipedia has led to many mechanisms for 
counteracting spam and vandalism. Patrolling, (semi)protection of pages, 
spam fighting robots and scripts, etc. can similarly be used on Wikidata 
to fight against deliberate attacks on high-visibility pages such a 
properties. In a sense, structured data is making it much easier to 
detect problems with automated tools. This should be effective against 
most deliberate attempts to cause trouble by changing property labels 
etc. (but we will need to do more there I guess).


Cheers,

Markus


On 08.01.2015 20:37, Thad Guidry wrote:
...


And that is my worry.  That the Schema model is publicly editable at any
time.

...


We have the same problem in Freebase, where if by public agreement, we
change the meaning of a Property so much that it might cause erroneous
data statements, then we deprecate that Property and create a new one,
splitting off the various statements into their proper form and letting
the Community know, and also performing the data tasks to subscribe the
old data to the new Schema.

The pollution of data would happen if by agreement P17's Discussion page
drastically changed the intended meaning of it, then all the data that
used P17 would need to be cleaned up.

How does Wikidata intend to deal with those kinds of changes to Property
meanings in the future ? and the data cleanup involved ?



___
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] Freebase's incompatible types and Property description permissions

[Thad Guidry]

Hi Marcus!

Yes, you and I are on the same page.  Yes, I know about the Property-first
view of WIkidata.  No quibbles.  But there is still an issue with
Assumptions for "Country" P17 being used for an instance of Band...so let's
clarify this...

So, I guess things are fuzzy, because I do not jump to assumptions beyond
the meaning of P17 as it states on its Property or Discussion page.  And
the difference is that you are mentally performing a few assumptions.  It
is hard to train a computer to read your mind and answer a question for you
however.  :)  Its better to write those assumptions (meanings) down
somewhere.

Even for Freebase, we found that Properties had to be described very well
for all to understand their meaning with minimal ambiguity, and I was a big
proponent on Freebase to Google for better descriptions.

So, question since you understand the meaning of "Country" on the U2
page as you state... Can you please tell me that meaning...and then let's
see if we can transfer your knowledge to better improve P17 Property and
its description.
___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] Freebase's incompatible types and Property description permissions

[Markus Krötzsch]

On 08.01.2015 20:37, Thad Guidry wrote:
...



Right, Freebase would not stick a Property called "Country" right on an
instance of a Music Band.  We would put Country under the Musical Group
type, and give it a better definition like "The nation or territory that
this item originated from".  Freebase's Properties always live under a
Freebase Type, like "Musical Group".  Which is why on Wikidata, even
seeing P17 on the U2 topic page makes me wonder what kind of schema
Wikidata is trying to pull off.  But it appears that someone did not
really read the description page of P17, like I just did, then they
would see it just is not allowed like that, but instead should have used
P27, but then you can't have a date of birth for a Musical Group (band),
which voids using even P27 on an instance of band.

I understand, there are many holes in Wikidata's schema currently.  I am
one of several Freebase experts coming over that can help Wikidata
identify those problematic Schema. :-)


Dear Thad,

It is important to realize that there is a crucial difference between 
the way schema information is organised in Wikdiata and in Freebase. 
Freebase uses a type-based schema, where types (roughly our "classes") 
are the main organisation unit, with properties being subordinate (like 
attributes of a certain type of object in programming). In contrast, 
Wikidata uses a property-based schema where properties are the 
first-class citizens and types are only one particular kind of value one 
could give to certain properties (like, e.g., in the W3C Resource 
Description Framework).


Both of these approaches have been used in many places, and it would not 
be conclusive to have a discussion about which one is better on 
principled grounds. To be productive together, however, it is important 
to realise that we are translating between two different worlds here. It 
is not about "fixing" one world so it fits the viewpoint of the other, 
but to understand the system that is in place and to adopt to it.


Independent of these things, there are of course plenty of ways to 
improve the data and schema. The case you focussed on is quite typical 
for the general question whether classes/properties should be broader or 
narrower in their scope. Too broad definitions lead to data of unclear 
meaning and little information value. Too narrow definitions lead to 
incomparable "local" data formats that make it hard or impossible to 
combine data on relatively similar things since they use different 
schemas. There is always a tension between the two, and I am sure we 
have cases where we err in either direction.


Note that this problem is not caused by a property-based view -- it's 
just a question of modelling that has to be discussed in each case. As 
for the case of "country" values for bands, it seems to me completely 
natural to use it without any further qualification. It is rather broad, 
I admit, but I understand the meaning just like I understand the 
sentence "U2 are an Irish rock band from Dublin" [1]. I don't think we 
should change this to "U2 are a rock band that has originated in the 
country of Ireland" or "U2 are a rock band whose members are of Irish 
nationality" to clarify this. It is very common to associate 
nationalities with bands and "country" seems to be a sensible name for 
the respective property. If you think that there could be some 
misunderstanding then it might be that we need to use properties with 
narrower meanings, but it is still useful to have a simple broad way of 
displaying bands by country, etc. And as long as it is clear to most 
people which relationships in "real life" this tries to capture, I don't 
think any action is needed.


Cheers,

Markus

[1] https://en.wikipedia.org/wiki/U2





2. How does Wikidata want to handle locking down Property
descriptions
(Freebase uses Permissions and Owners), where the complete
meaning of
something being changed might cause severe wrongful polluted data ?


There is no such thing in wikis.
http://c2.com/cgi/wiki?__WikiDesignPrinciples

https://meta.wikimedia.org/__wiki/The_wiki_way



But Wikidata is not a "wiki" in the true sense, or should not be
purported as one Because it is not Schema-less, but in fact,
prescribes to a publicly editable and agreed upon Schema model.

One thing I did notice is that the Wikidata Schema model is actually
composed of both agreement on the 2 tabs of
https://www.wikidata.org/wiki/Property_talk:P17  both the Property tab,
AND the Discussions tabcombined...give the effective model of the
Property...whereas in Freebase, we would just have the Property, where
all rules and definitions about it are stored (Discussions about a
Property were stored on our wiki and also our mailing list).  I enjoy
the Wikidata way a bit more compared to Freebase, the benefit being a
primary plac

Re: [Wikidata-l] Queries related question : relationship beetween queries

[Thomas Douillard]

Templates can also be coded in lua, which is comparable to javascript in
expressivity. It's not so hard to code a generic lua template that could
act as reasonator, multilingual and that could be imported into every
language versions of Wikipedia.

Here is the interesting thing : this generic version could be, in my
proposition, associated to the query "every item", so it is totally
compatible. But every wikipedia could also overload the mechanism by
associating language specific versions of the template for specific kind on
item.

This leads us to the original question of this thread, as every query's
results is a subset of the result of the query "every item on WIkidata".

2015-01-02 16:08 GMT+01:00 Gerard Meijssen :

> Hoi,
> Absolutely. However, creating functionality that is useful in any language
> for any subject beats considering templates that are useful for only about
> one project. Also automated text is something beyond what templates may
> offer or what Reasonator offers.
>
> Reasonator and its approach is superior because it provides information on
> the strength of the available labels and the ability to understand other
> languages. Templates fall short in every way in that respects.
>
> I am all in favour of understanding what templates are, what queries are,
> the restrictions in either but I am not willing to consider templates a
> real solution that works for Wikidata.
> Thanks,
>   GerardM
>
> On 2 January 2015 at 10:26, Thomas Douillard 
> wrote:
>
>> Generated a grammatically correct same meaning sentence in all language
>> in the planet automatically is way more difficult than finding a user that
>> will write a template is his 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
>
>
___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] Freebase's incompatible types and Property description permissions

[Thad Guidry]

On Thu, Jan 8, 2015 at 12:17 PM, Federico Leva (Nemo) 
wrote:

> Thad Guidry, 08/01/2015 18:58:
>
>> Unless the P17 Country property had an expanded definition of "sovereign
>> state (or originating sovereign state) of this item"
>>
>
> That's more like P27. Both are rather flexible though, see their talk
> pages.
> https://www.wikidata.org/wiki/Property_talk:P17
>
>
>> 1. How does Wikidata want to handle Property / Statement rule
>> enforcement and Freebase's incompatible types ?
>>
>
> I'm not sure how this is an example of "incompatible" type, it sounds more
> like a type Freebase didn't have. Handling such differences is possible by
> tweaking property descriptions and adding constraints. P17 is already
> declared incompatible with "instance of: human". If you make "music band" a
> subclass of "human", then this statement about U2 will be reported by bots
> as a constraint violation.


Right, Freebase would not stick a Property called "Country" right on an
instance of a Music Band.  We would put Country under the Musical Group
type, and give it a better definition like "The nation or territory that
this item originated from".  Freebase's Properties always live under a
Freebase Type, like "Musical Group".  Which is why on Wikidata, even seeing
P17 on the U2 topic page makes me wonder what kind of schema Wikidata is
trying to pull off.  But it appears that someone did not really read the
description page of P17, like I just did, then they would see it just is
not allowed like that, but instead should have used P27, but then you can't
have a date of birth for a Musical Group (band), which voids using even P27
on an instance of band.

I understand, there are many holes in Wikidata's schema currently.  I am
one of several Freebase experts coming over that can help Wikidata identify
those problematic Schema. :-)


>
>> 2. How does Wikidata want to handle locking down Property descriptions
>> (Freebase uses Permissions and Owners), where the complete meaning of
>> something being changed might cause severe wrongful polluted data ?
>>
>
> There is no such thing in wikis.
> http://c2.com/cgi/wiki?WikiDesignPrinciples
> https://meta.wikimedia.org/wiki/The_wiki_way
>
>
But Wikidata is not a "wiki" in the true sense, or should not be purported
as one Because it is not Schema-less, but in fact, prescribes to a
publicly editable and agreed upon Schema model.

One thing I did notice is that the Wikidata Schema model is actually
composed of both agreement on the 2 tabs of
https://www.wikidata.org/wiki/Property_talk:P17  both the Property tab, AND
the Discussions tabcombined...give the effective model of the
Property...whereas in Freebase, we would just have the Property, where all
rules and definitions about it are stored (Discussions about a Property
were stored on our wiki and also our mailing list).  I enjoy the Wikidata
way a bit more compared to Freebase, the benefit being a primary place to
see the defines of the Property as well as the Discussion and questions
about it in the past.


> The errors are corrected after the fact; the central control system is not
> made of permissions, but of checks like the constraint violations bots
> mentioned above. What other pollutions of the data you have in mind?
>
>
And that is my worry.  That the Schema model is publicly editable at any
time.  And constraint violations are only effective against a "Well Defined
Property".  But what if I do not Well Define that property, or worst, I
completely change the meaning of that Property.  Imagine if I suddenly
change the meaning of one of your MySQL table columns... like, PERSON
suddenly becomes FURNITURE.  That can happen with Wikidata's publicly
editable Schema modelif someone maliciously changes the description of
that P17 Country to something very generic like "a state" oh really ?
What kind of state ?  Nations only ? Or territories considered as an
organized political community under one government.? or both ?  it appears
that P17's Discussion clarifies this a bit, and defines it a bit more
narrowly and would not allow just any territory with a political community.

We have the same problem in Freebase, where if by public agreement, we
change the meaning of a Property so much that it might cause erroneous data
statements, then we deprecate that Property and create a new one, splitting
off the various statements into their proper form and letting the Community
know, and also performing the data tasks to subscribe the old data to the
new Schema.

The pollution of data would happen if by agreement P17's Discussion page
drastically changed the intended meaning of it, then all the data that used
P17 would need to be cleaned up.

How does Wikidata intend to deal with those kinds of changes to Property
meanings in the future ? and the data cleanup involved ?
___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] Freebase's incompatible types and Property description permissions

[Federico Leva (Nemo)]

Thad Guidry, 08/01/2015 18:58:

Unless the P17 Country property had an expanded definition of "sovereign
state (or originating sovereign state) of this item"


That's more like P27. Both are rather flexible though, see their talk pages.
https://www.wikidata.org/wiki/Property_talk:P17



1. How does Wikidata want to handle Property / Statement rule
enforcement and Freebase's incompatible types ?


I'm not sure how this is an example of "incompatible" type, it sounds 
more like a type Freebase didn't have. Handling such differences is 
possible by tweaking property descriptions and adding constraints. P17 
is already declared incompatible with "instance of: human". If you make 
"music band" a subclass of "human", then this statement about U2 will be 
reported by bots as a constraint violation.




2. How does Wikidata want to handle locking down Property descriptions
(Freebase uses Permissions and Owners), where the complete meaning of
something being changed might cause severe wrongful polluted data ?


There is no such thing in wikis.
http://c2.com/cgi/wiki?WikiDesignPrinciples
https://meta.wikimedia.org/wiki/The_wiki_way

The errors are corrected after the fact; the central control system is 
not made of permissions, but of checks like the constraint violations 
bots mentioned above. What other pollutions of the data you have in mind?


Nemo

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

[Wikidata-l] Freebase's incompatible types and Property description permissions

[Thad Guidry]

Freebase has mutexes that store incompatible type information.

For instance, in Wikidata I noticed on the U2 band topic, that they have
statements of:

P17 Country - sovereign state of this item.
P740 Location of formation - location where a group or organization was
formed.

In Freebase we have basically that P740, "Place where musical career
began".but not a Country property with that sort of definition.

But having "sovereign state of this item" on an instance of band, seems
weird, and perhaps should not be allowed , or incompatible.  Unless the P17
Country property had an expanded definition of "sovereign state (or
originating sovereign state) of this item"

1. How does Wikidata want to handle Property / Statement rule enforcement
and Freebase's incompatible types ?

2. How does Wikidata want to handle locking down Property descriptions
(Freebase uses Permissions and Owners), where the complete meaning of
something being changed might cause severe wrongful polluted data ?

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

Re: [Wikidata-l] [Mediawiki-api] Freebase like API with an OUTPUT feature ?

[Denny Vrandečić]

Actually, since Wikidata allows now properties on properties, one might
easily create an item "Disambiguating property" and then make a claim
"instance of - Disambiguating property" on the relevant property. there is
no need for any extra implementation work.



On Wed Jan 07 2015 at 9:48:32 AM Thad Guidry  wrote:

> Hi Lydia,
>
> It's more than that.  I can get labels just fine with &props=labels
>
> Ideally there were be a Number 3 a reconcile service, or an API that
> can be USED as a reconcile service.
>
> Given a search string of "Paris", let's say...
>
> 1. Return some disambiguating properties and their labels and values.  For
> reconciling purposes, you don't want to deal with codes like P12345 but
> instead a human understandable description of the property.
>   a. Allow the output of the information returned to be expanded or
> reduced by some parameter values that I mentioned as OUTPUT.
>   b. Allow the use of a (disambiguator) parameter to output only the
> disambiguating properties. (disambiguating properties are those that are
> most important when comparing A = B and given a type).  In Freebase API, we
> had the option of this as shown here:
> http://freebase-search.freebaseapps.com/?query=Texas&output=(disambiguator)&limit=100&scoring=entity&lang=en
>
> The current "disambiguator" with Wikidata is actually the "descriptions".
> Wikidata does not flag or mark properties like P856 (official site) as a
> "disambiguating property", an important property.  Freebase does however.
> It would be nice for Wikidata to begin work on having a disambiguating
> property flag (boolean Y/N) like Freebase does.
>
> The closest starting point for a Reconcile API with the current API
> structure that I can see is hacking a bit on this one:
>
> https://www.wikidata.org/w/api.php?action=wbgetentities&sites=enwiki&titles=Paris&languages=en&props=descriptions|claims
>
> Btw, that closest starting point, only outputs 1 entity for "Paris" in the
> enwiki... where's Paris, Texas ?
>
> Thad
> +ThadGuidry 
>
> ___
> 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] Conflict of Interest policy for Wikidata

[Denny Vrandečić]

Yay! I would love to see it featured on the
Wikidata main page! Let's slashdot ACM :)

On Thu Jan 08 2015 at 6:11:57 AM  wrote:

> Prior to viewing Markus Krötzsch's Wikidata page, I was unaware of the
> "Wikidata: A Free Collaborative Knowledgebase" article [1] written by
> Denny Vrandečić and Markus Krötzsch.  This is a very helpful article
> that in my opinion should be featured on the Wikidata main page.
>
> [1] http://cacm.acm.org/magazines/2014/10/178785-wikidata/fulltext
>
> Regards,
> James Weaver
>
> On Wed, Jan 7, 2015, at 05:14 PM, Markus Krötzsch wrote:
> > Irrespective of the general policy discussion, I have now been bold and
> > changed my item and user page to record that relationship as by my
> > earlier suggestion (as copied below):
> >
> > https://www.wikidata.org/wiki/Q18618630
> >
> > I was wondering if, given that we have single signon, "website account
> > on" should point to "Wikidata" or to "Wikimedia" or something else. But
> > besides this minor point this seems to be a nice way to have COI
> > declarations in the data (would also be interesting to know which living
> > people have official Wikimedia accounts).
> >
> > Cheers,
> >
> > Markus
> >
> > On 07.01.2015 15:25, Markus Krötzsch wrote:
> > ...
> > >
> > > In addition, there should be a template that one can use on one's user
> > > page to disclose that one is the person described in a certain item.
> > > Conversely, we should also use our "website account on" property (P553)
> > > to connect living people to their Wikidata user account, so the COI is
> > > recorded in the data. One could further disclose other COIs on one's
> > > user page in some standard format, but maybe with Wikidata we could
> > > actually derive such COIs automatically (your family members, the
> > > companies you founded, the university you graduated from, etc. can all
> > > be specified in data).
> > >
> > > Cheers,
> > >
> > > Markus
> > >
> > >
> >
> > ___
> > 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] Wikidata CACM article (Was: Conflict of Interest policy for Wikidata)

[Denny Vrandečić]

Yes, CC-BY is great.

On Thu Jan 08 2015 at 7:01:12 AM Markus Krötzsch <
mar...@semantic-mediawiki.org> wrote:

> On 08.01.2015 15:10, ja...@j1w.xyz wrote:
> > Prior to viewing Markus Krötzsch's Wikidata page, I was unaware of the
> > "Wikidata: A Free Collaborative Knowledgebase" article [1] written by
> > Denny Vrandečić and Markus Krötzsch.  This is a very helpful article
> > that in my opinion should be featured on the Wikidata main page.
>
> Glad you liked it. Checking the Wikidata item, I notice that it is
> actually Open Access and not "all rights reserved". It is available for
> free ("forever") from the ACM [1], but it seems they do not define any
> license. However, as we have retained all the rights, we can do what we
> like there.
>
> Denny, shall we use CC-BY?
>
> Markus
>
> [1] http://cacm.acm.org/magazines/2014/10/178785-wikidata/fulltext
>
>
> >
> > [1] http://cacm.acm.org/magazines/2014/10/178785-wikidata/fulltext
> >
> > Regards,
> > James Weaver
> >
> > On Wed, Jan 7, 2015, at 05:14 PM, Markus Krötzsch wrote:
> >> Irrespective of the general policy discussion, I have now been bold and
> >> changed my item and user page to record that relationship as by my
> >> earlier suggestion (as copied below):
> >>
> >> https://www.wikidata.org/wiki/Q18618630
> >>
> >> I was wondering if, given that we have single signon, "website account
> >> on" should point to "Wikidata" or to "Wikimedia" or something else. But
> >> besides this minor point this seems to be a nice way to have COI
> >> declarations in the data (would also be interesting to know which living
> >> people have official Wikimedia accounts).
> >>
> >> Cheers,
> >>
> >> Markus
> >>
> >> On 07.01.2015 15:25, Markus Krötzsch wrote:
> >> ...
> >>>
> >>> In addition, there should be a template that one can use on one's user
> >>> page to disclose that one is the person described in a certain item.
> >>> Conversely, we should also use our "website account on" property (P553)
> >>> to connect living people to their Wikidata user account, so the COI is
> >>> recorded in the data. One could further disclose other COIs on one's
> >>> user page in some standard format, but maybe with Wikidata we could
> >>> actually derive such COIs automatically (your family members, the
> >>> companies you founded, the university you graduated from, etc. can all
> >>> be specified in data).
> >>>
> >>> Cheers,
> >>>
> >>> Markus
> >>>
> >>>
> >>
> >> ___
> >> 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
>
___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

[Wikidata-l] Wikidata CACM article (Was: Conflict of Interest policy for Wikidata)

[Markus Krötzsch]

On 08.01.2015 15:10, ja...@j1w.xyz wrote:

Prior to viewing Markus Krötzsch's Wikidata page, I was unaware of the
"Wikidata: A Free Collaborative Knowledgebase" article [1] written by
Denny Vrandečić and Markus Krötzsch.  This is a very helpful article
that in my opinion should be featured on the Wikidata main page.


Glad you liked it. Checking the Wikidata item, I notice that it is 
actually Open Access and not "all rights reserved". It is available for 
free ("forever") from the ACM [1], but it seems they do not define any 
license. However, as we have retained all the rights, we can do what we 
like there.


Denny, shall we use CC-BY?

Markus

[1] http://cacm.acm.org/magazines/2014/10/178785-wikidata/fulltext




[1] http://cacm.acm.org/magazines/2014/10/178785-wikidata/fulltext

Regards,
James Weaver

On Wed, Jan 7, 2015, at 05:14 PM, Markus Krötzsch wrote:

Irrespective of the general policy discussion, I have now been bold and
changed my item and user page to record that relationship as by my
earlier suggestion (as copied below):

https://www.wikidata.org/wiki/Q18618630

I was wondering if, given that we have single signon, "website account
on" should point to "Wikidata" or to "Wikimedia" or something else. But
besides this minor point this seems to be a nice way to have COI
declarations in the data (would also be interesting to know which living
people have official Wikimedia accounts).

Cheers,

Markus

On 07.01.2015 15:25, Markus Krötzsch wrote:
...


In addition, there should be a template that one can use on one's user
page to disclose that one is the person described in a certain item.
Conversely, we should also use our "website account on" property (P553)
to connect living people to their Wikidata user account, so the COI is
recorded in the data. One could further disclose other COIs on one's
user page in some standard format, but maybe with Wikidata we could
actually derive such COIs automatically (your family members, the
companies you founded, the university you graduated from, etc. can all
be specified in data).

Cheers,

Markus




___
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] Conflict of Interest policy for Wikidata

[james]

Prior to viewing Markus Krötzsch's Wikidata page, I was unaware of the
"Wikidata: A Free Collaborative Knowledgebase" article [1] written by
Denny Vrandečić and Markus Krötzsch.  This is a very helpful article
that in my opinion should be featured on the Wikidata main page. 

[1] http://cacm.acm.org/magazines/2014/10/178785-wikidata/fulltext

Regards,
James Weaver

On Wed, Jan 7, 2015, at 05:14 PM, Markus Krötzsch wrote:
> Irrespective of the general policy discussion, I have now been bold and 
> changed my item and user page to record that relationship as by my 
> earlier suggestion (as copied below):
> 
> https://www.wikidata.org/wiki/Q18618630
> 
> I was wondering if, given that we have single signon, "website account 
> on" should point to "Wikidata" or to "Wikimedia" or something else. But 
> besides this minor point this seems to be a nice way to have COI 
> declarations in the data (would also be interesting to know which living 
> people have official Wikimedia accounts).
> 
> Cheers,
> 
> Markus
> 
> On 07.01.2015 15:25, Markus Krötzsch wrote:
> ...
> >
> > In addition, there should be a template that one can use on one's user
> > page to disclose that one is the person described in a certain item.
> > Conversely, we should also use our "website account on" property (P553)
> > to connect living people to their Wikidata user account, so the COI is
> > recorded in the data. One could further disclose other COIs on one's
> > user page in some standard format, but maybe with Wikidata we could
> > actually derive such COIs automatically (your family members, the
> > companies you founded, the university you graduated from, etc. can all
> > be specified in data).
> >
> > Cheers,
> >
> > Markus
> >
> >
> 
> ___
> 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