Multichill added a comment.
Also mentioned at
https://commons.wikimedia.org/wiki/Commons_talk:Structured_data/Modeling/Author#Datatype_for_Commons_photographers
TASK DETAIL
https://phabricator.wikimedia.org/T127929
EMAIL PREFERENCES
daniel added a comment.
In T127929#3675923, @TheDJ wrote:
Anonymous or unknown creator (legally can be different from: 'not known to us')
That's why we have somevalue and novalue snaks in Wikibase.
Pseudonymous creator (worse, a pseudonym whose name from a certain date became known ?)
In
TheDJ added a comment.
Other considerations
Anonymous creator
Pseudonymous creator (worse, a pseudonym whose name later became a known author)
Multi party copyright/creators
hierarchies ? For instance JPL lab images are often credited as NASA/JPL/Project/Person
TASK
Aleksey_WMDE added a comment.
His solution will also buy us time to eventually think an expansion of the approach, instead of immediately creating new namespaces in MediaInfo.
Cannot really agree, because it seems that we might be stuck with this solution for quiet a long time as soon as
Sannita added a comment.
I would argue against a X### solution, and support Daniel's initial solution: for the time being, we don't know how many authors we need to host and link to external sources. His solution will also buy us time to eventually think an expansion of the approach, instead of
Ghouston added a comment.
The same problem of notability will turn up if the subjects of images are going to be linked to Wikidata items, since there are plenty of images of things like buildings that may not be notable for Wikidata. At present, there's no problem having a category for the
Jarekt added a comment.
In T127929#3443235, @Ghouston wrote:
Technically, I suspect this would be easiest if Wikidata was allowed to hold all the items that Commons needs to store information about.
That would mean allowing any user that ever uploaded his file to Commons to have an item on
Ghouston added a comment.
Technically, I suspect this would be easiest if Wikidata was allowed to hold all the items that Commons needs to store information about. Maybe there could be a way to restrict particular Wikidata items to a limited subset of properties, so that URLs etc., could be stored
Aleksey_WMDE added a comment.
I like @Jarekt's idea.
There could be X### items of a new type (like User/Person/Author...) which could be restricted to only have a name and a set of URLs/URIs (wikidata item, user page, Flickr/Facebook/Twitter/... account) that can identify the "person" (no
Bugreporter added a comment.
Entries starts with M# are only for MediaInfo entry of an existing file, where # is page id. They are not normal items.TASK DETAILhttps://phabricator.wikimedia.org/T127929EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To:
Jarekt added a comment.
I am new to this discussion and I have not read every word above, but the easiest solution to me seems to allow every author to have their own M-code item on structured-common. Than the new datatype would allow either a q-code or m-code as its value. We could also have
Ghouston added a comment.
Maybe it's not even right to consider Department of Immigration and Citizenship to be the copyright holder in that example, and it's a file with Australian Government crown copyright. In that case, it's not clear what role DIAC is filling, if not the author or copyright
Ghouston added a comment.
On Commons, we currently tend to confuse author and copyright holder. It's the copyright holder who can release a file with a free license, and in practice chooses the attribution. We have a lot of files like
Ghouston added a comment.
I had the idea from the demo system that such records would exist (http://structured-commons.wmflabs.org/wiki/Q2). Oh well. With a system of credit string + URI it will be problematic in some cases to find all the works by a particular author. Credit string could be all
daniel added a comment.
@Ghouston there are currently no plans to have any items on commons, only media info entities on file description pages. All items are managed on wikidata. The current inclusion criteria for wikidata would not allow an item to be created for any random flickr user - and
Ghouston added a comment.
I'm not sure why you'd want a URI to an external site in a field like this. Is it not possible to assume that every person referred to will have an item either on Wikidata or on Commons? Then this field only needs to link to one of those places, where links to Flickr
daniel added a comment.
@Jan_Dittrich I think one important thing to consider here is integration with the Upload Wizard. The UI and workflow for manual upload is potentially completely separate from the generic editing interface for MediaInfo.
On a related note: in the UploadWizard, it makes
Jan_Dittrich added a comment.
@daniel: Thanks!
I wrote a (from-the-users-view) scenario:
Melissa wants to upload an image to commons. She uploads the image. In the upload form, she is asked to provide the name of the image’s creator. She made the picture, so it is her name. Also, she can provide
daniel added a comment.
In T127929#2604613, @Jan_Dittrich wrote:
You usually have the URL (or URI) of the author, but not the name? That seems strange to me, can you give examples? Or do you just have a source URL for the image?
Yes, if I import images from flickr, I can find the URL of the
Jan_Dittrich added a comment.
You usually have the URL (or URI) of the author, but not the name? That seems strange to me, can you give examples? Or do you just have a source URL for the image?
Yes, if I import images from flickr, I can find the URL of the uploader’s profile with one click, but
daniel added a comment.
In T127929#2604421, @Jan_Dittrich wrote:
@daniel You said that we have the plain name but want to find the URL. From my experience of adding images, which I did not create, to commons, I usually have the URL but not the Name. Or is this not covered by the issue?
You
Izno added a comment.
In T127929#2580320, @daniel wrote:
daniel added a subscriber: Izno.
I'm watching the project, but thank you. :D
That is indeed one of the main issues
Hmm, okay. I'd personally be a little less leery of WD:N cross this functionality at this point in time because it
Izno added a comment.
I'm sitting here puzzled, because nothing in the rationale indicates to me that this can't already be done using existing datatypes (item) and properties (birth name, perhaps a new 'full name' parameter in case someone wants to be attributed as something other than their
daniel added a comment.
Here's a straw man idea for the approach using qualifiers:
Scenario:
we assume that we typically have the plain text name, and use it to find a URI, not the other way around
we have a "person" data type that uses plain string values
we have a single well known property
daniel added a comment.
The central idea is: We want to be able to use the same property for all the different ways we may want to use to identify a person.
During our last discussion it turned out that the primary information we need to include is a plain text name, to cover the legal
Lydia_Pintscher added a comment.
In T127929#2503330, @Pigsonthewing wrote:
What if the creator is none of these? For example, a non notable individual who puts images on their own website, with a CC licence?
We need an "other" option at least that lets people enter a link to some other profile
Lydia_Pintscher added a comment.
In T127929#2503322, @Pigsonthewing wrote:
Has anyone considered the alternative of having a "creator type" property, qualified by one of the three kinds of ID discussed above?
Alternatively, have one type, which takes either an existing Wikidata item or one of
Pigsonthewing added a comment.
What if the creator is none of these? For example, a non notable individual who puts images on their own website, with a CC licence?TASK DETAILhttps://phabricator.wikimedia.org/T127929EMAIL
Pigsonthewing added a comment.
Has anyone considered the alternative of having a "creator type" property, qualified by one of the three kinds if ID discussed above?TASK DETAILhttps://phabricator.wikimedia.org/T127929EMAIL
Josve05a added a comment.
What ever happens, just make sure to cover bases on where a creator might be
covered by all tree of these. Have a user account, but uploaded it on Flickr
and have a Wikidata item about themselfs.
TASK DETAIL
https://phabricator.wikimedia.org/T127929
EMAIL
gerritbot added a comment.
Change 281585 merged by jenkins-bot:
Fix source field on partial refunds
https://gerrit.wikimedia.org/r/281585
TASK DETAIL
https://phabricator.wikimedia.org/T127929
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To:
gerritbot added a comment.
Change 281585 had a related patch set uploaded (by Eileen):
Fix source field on partial refunds
https://gerrit.wikimedia.org/r/281585
TASK DETAIL
https://phabricator.wikimedia.org/T127929
EMAIL PREFERENCES
Lydia_Pintscher added a comment.
It would also require having different properties to express the same thing
based on where it is which is something I want to avoid.
TASK DETAIL
https://phabricator.wikimedia.org/T127929
EMAIL PREFERENCES
Micru added a comment.
They could be different properties: "file creator on Commons", "file creator
on Flickr", etc. however that would require more data types...
TASK DETAIL
https://phabricator.wikimedia.org/T127929
EMAIL PREFERENCES
mkroetzsch added a comment.
+1 sounds like a workable design
TASK DETAIL
https://phabricator.wikimedia.org/T127929
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: mkroetzsch
Cc: mkroetzsch, Aklapper, daniel, Steinsplitter, Lydia_Pintscher, Izno,
35 matches
Mail list logo
