Model: research-dump/bge-base-en-v1.5_wikidata_pr_masked_wikidata_pr_masked
Author: research-dump
Pipeline: text-classification
Library: setfit
Tags: setfit, safetensors, bert, sentence-transformers, text-classification, generated_from_setfit_trainer, arxiv:2209.11055, base_model:BAAI/bge-base-en-v1.5, base_model:finetune:BAAI/bge-base-en-v1.5, region:us
Base models (finetune): id: BAAI/bge-base-en-v1.5
Card metadata: tags: setfit, sentence-transformers, text-classification, generated_from_setfit_trainer
widget: ###Instruction: Multi-class classification, answer with one of the labels: [deleted, keep, no_consensus] : ###Input:  Microsoft_Academic_ID_(P6366):   Kept .  Consensus to [MASK] this.  Thanks.  ( ) Kept .  Consensus to [MASK] this.  Thanks.  ( ) As a side note, the Microsoft Academic IDs on Wikidata are all messed up with Wayback Machine.  For example, check , the archive.org link leads to Plant & Food Research in New Zealand.  This occurs for all the entries I checked.  In addition, the references, which are all from gric.ac) are invalid because grid.ac has dropped Microsoft Academic ID. ( ) I agree on the observation, so Delete ( ) As there are snapshots of Microsoft Academic Graph we should first get some data of how consistent the data is.-- ( ) As I checked, all snapshots are oddly wrong because of JavaScript process. In any case, the snapshots are useless here. Next years, it is meaningless to have a link showing citations until 2021. There are other resources showing the same information. ( ) I think with "snapshop", GZWDer meant database dumps. What you seems to bother are broken links to archive.org. This is being fixed. --- My bad then!  The available database dumps are much older, and back to a few years ago when Microsoft decided to abandon the project.  It is unlikely to capture anything meaningful from those database dumps because Microsoft Academic was not producing any new contents in the first place.  The best case scenario is that someone create a website from the latest database dumps and change the URL of the property to redirect to the new website.  Otherwise, the current archive.org links are incorrect and misleading, and should be avoided at any cost.  ( ) They should be gone in a couple of days.  Let's [MASK] this then.  --- I agree on the observation, so Delete ( ) As there are snapshots of Microsoft Academic Graph we should first get some data of how consistent the data is.-- ( ) As I checked, all snapshots are oddly wrong because of JavaScript process.  In any case, the snapshots are useless here.  Next years, it is meaningless to have a link showing citations until 2021.  There are other resources showing the same information.  ( ) I think with "snapshop", GZWDer meant database dumps.  What you seems to bother are broken links to archive.org.  This is being fixed.  --- My bad then! The available database dumps are much older, and back to a few years ago when Microsoft decided to abandon the project. It is unlikely to capture anything meaningful from those database dumps because Microsoft Academic was not producing any new contents in the first place. The best case scenario is that someone create a website from the latest database dumps and change the URL of the property to redirect to the new website. Otherwise, the current archive.org links are incorrect and misleading, and should be avoided at any cost. ( ) They should be gone in a couple of days. Let's [MASK] this then. --- As I checked, all snapshots are oddly wrong because of JavaScript process.  In any case, the snapshots are useless here.  Next years, it is meaningless to have a link showing citations until 2021.  There are other resources showing the same information.  ( ) I think with "snapshop", GZWDer meant database dumps.  What you seems to bother are broken links to archive.org.  This is being fixed.  --- My bad then! The available database dumps are much older, and back to a few years ago when Microsoft decided to abandon the project. It is unlikely to capture anything meaningful from those database dumps because Microsoft Academic was not producing any new contents in the first place. The best case scenario is that someone create a website from the latest database dumps and change the URL of the property to redirect to the new website. Otherwise, the current archive.org links are incorrect and misleading, and should be avoided at any cost. ( ) They should be gone in a couple of days. Let's [MASK] this then. --- I think with "snapshop", GZWDer meant database dumps.  What you seems to bother are broken links to archive.org.  This is being fixed.  --- My bad then! The available database dumps are much older, and back to a few years ago when Microsoft decided to abandon the project. It is unlikely to capture anything meaningful from those database dumps because Microsoft Academic was not producing any new contents in the first place. The best case scenario is that someone create a website from the latest database dumps and change the URL of the property to redirect to the new website. Otherwise, the current archive.org links are incorrect and misleading, and should be avoided at any cost. ( ) They should be gone in a couple of days. Let's [MASK] this then. --- My bad then!  The available database dumps are much older, and back to a few years ago when Microsoft decided to abandon the project.  It is unlikely to capture anything meaningful from those database dumps because Microsoft Academic was not producing any new contents in the first place.  The best case scenario is that someone create a website from the latest database dumps and change the URL of the property to redirect to the new website.  Otherwise, the current archive.org links are incorrect and misleading, and should be avoided at any cost.  ( ) They should be gone in a couple of days.  Let's [MASK] this then.  --- They should be gone in a couple of days. Let's [MASK] this then. --- [MASK] OpenAlex took the last available dump of MAG and has published it as an open database, and will continue maintaining the data, see .  There's also discussion how to migrate the identifier values: OpenAlex IDs are same as MAG ID, but with a prefix letter indicating the kind of item (Author, Institution, Venue, Work, Concept).  So we need to [MASK] it until it's migrated.  -- ( ) It's wonderful to have a new project distributing the data, but there are two problems: (1) I anticipate major data discrepancies. Having the old data is not sufficient to continue producing the same data. The OpenAlex project needs the exact same program Microsoft used for identifying authors, institutions, etc. (2) If OpenAlex simply visualizes the Microsoft Academic data until 2021, it is fine to redirect the Microsoft Academic ID to OpenAlex. Otherwise, it is misleading to use the Microsoft brand for another project. As I checked the official website, OpenAlex uses different sources including Microsoft Academic. The purpose of the present proposal is to avoid misleading over the dead project of Microsoft Academic Graph. ( ) It's wonderful to have a new project distributing the data, but there are two problems: (1) I anticipate major data discrepancies. Having the old data is not sufficient to continue producing the same data. The OpenAlex project needs the exact same program Microsoft used for identifying authors, institutions, etc. (2) If OpenAlex simply visualizes the Microsoft Academic data until 2021, it is fine to redirect the Microsoft Academic ID to OpenAlex. Otherwise, it is misleading to use the Microsoft brand for another project. As I checked the official website, OpenAlex uses different sources including Microsoft Academic. The purpose of the present proposal is to avoid misleading over the dead project of Microsoft Academic Graph. ( ) [MASK] no reason to delete. maybe a mirror will be stood up using the dump. even without a mirror it's fine to [MASK]. ( ) [MASK] until the question around OpenAlex (or other mirrors) is resolved. As long as the data is useful (to someone) it should not be [MASK]. -- ( ) ###Output: , ###Instruction: Multi-class classification, answer with one of the labels: [deleted, keep, no_consensus] : ###Input:  Property:P10809:   Don't need to delete ( ) Don't need to delete ( ) Seems use of this property have started in some qualifyers.  No longer asking deletion.  ● ● ###Output: , ###Instruction: Multi-class classification, answer with one of the labels: [deleted, keep, no_consensus] : ###Input:  Property:P8981:   Delete and replace with ( ) Delete and replace with ( ) Delete per nom.  Furthermore, it seems that the only support the proposal received was from editors that the nominator blatantly canvassed.  And that proposal was only made after was rejected with only a single supporter.  The objectors on the original proposal were not pinged when the second one was made; and neither were the relevant projects (who were pinged for the first proposal).  [MASK] See above on Martian coordinates.  I don't recall any of the details Andy mentions, but really, property proposals are announced every week in the newsletter, is pinging so critical?  ( ) Also see my reply at .  Looking back at the newsletter, this was buried amongst other proposals and was very easy to miss (I completely missed it).  Thanks.  ( ) All of the details I mentioned are gleanable from the pages mentioned, which is where I found them on the 24th.  The issue in this case was the partisan pinging.  Also see my reply at .  Looking back at the newsletter, this was buried amongst other proposals and was very easy to miss (I completely missed it).  Thanks.  ( ) All of the details I mentioned are gleanable from the pages mentioned, which is where I found them on the 24th.  The issue in this case was the partisan pinging.  Delete .  With the creation of Bamyer's globe tool (see discussion at ) and a bot being created to convert incorrect uses of (see ), there is no need for this property or anymore.  Ok, no longer voting to [MASK].  Fine if it's [MASK] with the coordinates moved to P625.  ( ) Thanks for closing it.  I should be able to migrate values over soon.  Thanks.  ( ) @ : reminder ^ ( ) @ : As I said at , this is currently stuck as I don't have an easy way to migrate them while keeping the reference.  Thanks.  ( ) @ : reminder ^ ( ) @ : As I said at , this is currently stuck as I don't have an easy way to migrate them while keeping the reference.  Thanks.  ( ) @ : As I said at , this is currently stuck as I don't have an easy way to migrate them while keeping the reference.  Thanks.  ( ) @ , : Manual replacement has been completed.  Sourced from .  -- ( ) Done -- ( ) Done -- ( ) ###Output: , ###Instruction: Multi-class classification, answer with one of the labels: [deleted, keep, no_consensus] : ###Input:  contains_the_administrative_territorial_entity_(P150):   After dragging out for far, far too long, it's clear that there's not a consensus for deleting this.  If anything, there's a weak consensus for keeping it.  After dragging out for far, far too long, it's clear that there's not a consensus for deleting this.  If anything, there's a weak consensus for keeping it.  Delete Redundant.  — Delete .  -- ( ) This one desperately needs to be [MASK], not least because of the fact that it is a reciprocal but also because it slows down the rendering of pages like or (I'm sure) the item for the United States. The relation can be inferred for now. -- ( ) Seeing as we're suggesting this one for deletion as a reciprocal of another property currently up for deletion, that one should close as [MASK] immediately.  Both should not be up for deletion at the same time.  On hold per TCN7JM.  -- ( ) Would just like to suggest in advance the same thing I suggested above for P527: We only use this for cases where there's no separate list of subdivisions, and otherwise we'd instead use a "list of subdivisions" property. But obviously this'll be a moot point if P131 is [MASK] (in which case my !vote would be to merge this to P527). — If/once P131 is kept, Delete . Today, I do not think P131 has to be [MASK], but it's purpose has to be more obvious. -- ( ) Today, I do not think P131 has to be [MASK], but it's purpose has to be more obvious.  -- ( ) I thought that Wikidata was created to make it useful in Wikipedia-articles?!  Please, tell me how "reciprocal" properties will be fetched in Wikipedia!  I can find them with a bot, but as far as I can see, not from Wikipedia.  -- ( ) The main purpose of Wikidata was and is to help Wikipedia, but it also lives stand-alone.  So we should not sacrifice scalability (which only a database can offer) just for the sake of infoboxes.  In few months Wikipedia (and all sisters) should have much more power with data.  -- "In few months Wikipedia ... should have much more power with data." - How?  I am starting to belive it was a mistake to let us start to edit in this project before all mayor tools were available.  As long as we do not see those tools and the benefits they have, it is impossible for me to see the benefit for Wikipedia (and sisters).  And without that benefit, my interest in contributing here is nill.  -- ( ) I completely agree.  Phase II started way too early, but that's how it is now and we have to deal with it.  That doesn't change it's a bad idea to postpone our work on data structure, because if a system consolidates it becomes hard to overhaul, even if it is inconsistent and redundant and therefore less useful.  — The main purpose of Wikidata was and is to help Wikipedia, but it also lives stand-alone.  So we should not sacrifice scalability (which only a database can offer) just for the sake of infoboxes.  In few months Wikipedia (and all sisters) should have much more power with data.  -- "In few months Wikipedia ... should have much more power with data." - How?  I am starting to belive it was a mistake to let us start to edit in this project before all mayor tools were available.  As long as we do not see those tools and the benefits they have, it is impossible for me to see the benefit for Wikipedia (and sisters).  And without that benefit, my interest in contributing here is nill.  -- ( ) I completely agree.  Phase II started way too early, but that's how it is now and we have to deal with it.  That doesn't change it's a bad idea to postpone our work on data structure, because if a system consolidates it becomes hard to overhaul, even if it is inconsistent and redundant and therefore less useful.  — "In few months Wikipedia ... should have much more power with data." - How?  I am starting to belive it was a mistake to let us start to edit in this project before all mayor tools were available.  As long as we do not see those tools and the benefits they have, it is impossible for me to see the benefit for Wikipedia (and sisters).  And without that benefit, my interest in contributing here is nill.  -- ( ) I completely agree. Phase II started way too early, but that's how it is now and we have to deal with it. That doesn't change it's a bad idea to postpone our work on data structure, because if a system consolidates it becomes hard to overhaul, even if it is inconsistent and redundant and therefore less useful. — I completely agree. Phase II started way too early, but that's how it is now and we have to deal with it. That doesn't change it's a bad idea to postpone our work on data structure, because if a system consolidates it becomes hard to overhaul, even if it is inconsistent and redundant and therefore less useful. — I do not see how this one is redundant even if P131 is kept. There is no easy way to get this info on Wikidata and add it to Wikipedia articles.-- ( ) [MASK] How else can I say that have subdivisions , and ?  I am not against merging with , if will be systematically merged all "almost similar" properties.  And yes, if there exists separate "list of municipalities in distric XYZ", it sholud be linked instead of all members.  ( ) [MASK] as Ymblanter.  -- ( ) I have to say, I'd be against merging this with P527. "Consists of" can have a much wider meaning. For example, South Dakota consists of about 830,000 residents, but subdivides into 66 counties, all of which should contain "is in the administrative unit" → "South Dakota". I'm not proposing to delete this property for being redundant with : I simply find nonsensical to have < > , , when we should have " → " for each of , and . -- but → should be also in many different items, e.g. , ... and if I open , I can not see which parts have - only use , where are many other links.  ( ) I never said you were proposing that.  I was replying to the person who mentioned P527 above.  I'm not proposing to delete this property for being redundant with : I simply find nonsensical to have < > , , when we should have " → " for each of , and .  -- but → should be also in many different items, e.g. , ... and if I open , I can not see which parts have - only use , where are many other links.  ( ) I never said you were proposing that.  I was replying to the person who mentioned P527 above.  but → should be also in many different items, e.g. , ... and if I open , I can not see which parts have - only use , where are many other links.  ( ) but → should be also in many different items, e.g. , ... and if I open , I can not see which parts have - only use , where are many other links.  ( ) I never said you were proposing that.  I was replying to the person who mentioned P527 above.  Delete .  Now that is kept, this is pretty much redundant.  (P131 was proposed for deletion not because it's the inverse of this one, but because it was similar to .) ( ) [MASK] For now it's impossible to have all administrative divisions in a item without this property.  I can change my vote it this possibility will be added.  -- ( ) Delete -- ( ) [MASK] It is not redundand, remember this project is primary made for bot and there is the need to scroll fluency up and down tree of data ( ) [MASK] not redundant; can contain everything (a city district, a theatre, a mountain etc), but should contain only administrative subdivisions.  ( ) That's not that large an issue.  Any item which something is in should have a subclass of .  Checks and queries can be based on that fact.  -- ( ) That's not that large an issue. Any item which something is in should have a subclass of . Checks and queries can be based on that fact. -- ( ) [MASK] I agree with , this property is needed.  If you want you may fuse with this property or eliminate, but this property must stay.  - ( ) 14:41, 18 August 2013 (UTC) Comment I was reconsidering my vote: as said, and this property are not reciprocal (which I agree), so this property is completely useless.  The only was we can describe not just actual administrative subdivisions, but also historic subdivisions (using time qualifiers).  If one articles contains (for example) 100 administrative divisions which it subdivides, more 300 other historic subdivisions, the item would be huge and confusing.  I prefer don't vote for now, because of this.  - ( ) ###Output: , ###Instruction: Multi-class classification, answer with one of the labels: [deleted, keep, no_consensus] : ###Input:  P616_(P616):   delete this property.  Duplicate of P1369, but much less used.  -- ( ) delete this property. Duplicate of P1369, but much less used. -- ( ) Why not delete the higher numbered one then?  -- ( ) The first one had some technical problems! That is the bot is working on the second one.-- ( ) In these examples you see that they have the same values even from the same sources: , , , , . -- ( ) The first one had some technical problems! That is the bot is working on the second one.-- ( ) In these examples you see that they have the same values even from the same sources: , , , , . -- ( ) ###Output: 
metrics: accuracy
pipeline_tag: text-classification
library_name: setfit
inference: yes
base_model: BAAI/bge-base-en-v1.5
Likes: 0 | All-time downloads: 9
Created: 2025-02-07 05:22:47