User talk:Vicarage

Mass destruction weapon

Hello, why these not subclass of weapon? Infovarius (talk) 19:49, 5 January 2024 (UTC)[reply]

They were a range of discursive articles about the weapons of the countries, they are not weapons themselves, hence the use of facet of (P1269). Vicarage (talk) 20:02, 5 January 2024 (UTC)[reply]

Weapon vs firearm model

Hi, can I ask you to explain more about your rationale for removing the more specific subclass of (P279) statement of firearm model (Q22704163) and replacing it with weapon model (Q15142894) as seen in this diff [1] for example? It appears we are losing information with this approach. Thanks. - Fuzheado (talk) 20:25, 5 January 2024 (UTC)[reply]

See https://www.wikidata.org/wiki/Wikidata_talk:WikiProject_Military_History#merging_the_firearm_model,_model_series,_family_etc_into_weapon_model,_series,_family Vicarage (talk) 20:32, 5 January 2024 (UTC)[reply]

Siege tools

Hi, I see you're interested into history. What about Category:Siege engines^(Q6012851) and Category:Siege weapons^(Q8743609) ? Bouzinac ^{💬●✒️●💛} 21:08, 5 January 2024 (UTC)[reply]

I've certainly seen issues about the distinction between siege engines (big wooden things with ropes), siege artillery (big guns), things used for sieges (towers, picks). I see enwiki has siege equipment, we ought to add that with siege engine (Q655697) and siege artillery (Q815231) under it, and drop the alias "siege weapon". One issue is how we handle boarding ramps for ships, which I saw were siege weapons, but aren't really weapons. Vicarage (talk) 21:16, 5 January 2024 (UTC)[reply]

siege equipment (Q124694131) created. Siege engines includes towers and ramps. Vicarage (talk) 10:14, 29 February 2024 (UTC)[reply]

P921 vs P136

It looks as though you have tagged several science fiction magazines with main subject (P921) instead of genre (P136). Using property main subject (P921) science fiction (Q24925) means that the magazine contains information about science fiction. Whereas using property genre (P136) science fiction (Q24925) means that the magazine contains stories that are science fiction. --EncycloPetey (talk) 13:14, 13 July 2024 (UTC)[reply]

@EncycloPetey That makes sense, so there is a distinction between a critical work and a fanzine on one side, and a SF magazine on the other. For the latter its an instance of a magazine, should be it have genre science fiction or science fiction literature or science fiction magazine? I've seen all in use. I was changing things which had a main subject of science fiction magazine, when they were one.

On a separate thing, you've reverted my claim that a novel is a literary work. Does that mean that I can expect all the literary works by an author (as opposed to their critical works, articles etc). should have have a top level {instance of (P31) of that, and not merely be novel/short story etc? Vicarage (talk) 14:39, 13 July 2024 (UTC)[reply]

Also why doesn't science fiction magazine (Q3399338) have a genre of science fiction? Vicarage (talk) 14:56, 13 July 2024 (UTC)[reply]

It probably should. --EncycloPetey (talk) 14:57, 13 July 2024 (UTC)[reply]

Correct on both counts.

However, it is possible for a science fiction magazine to be a mix of stories and articles about the field. This is why I did not remove any instances of main subject (P921). I checked one of the magazines, and found that it does have articles about the subject, and not just science fiction stories.

And yes, nearly every data item for a novel or short story should have a top-level instance of (P31) using literary work, with "novel" / "short story" as the form of creative work (P7937). There are some dta items where this gets complicated because the work is a collection of novels or a collection of short stories. We don't yet have a standard way to represent those items. --EncycloPetey (talk) 14:56, 13 July 2024 (UTC)[reply]

Nearly all SF magazines have critical work, even if its just a book review or letters column or news section.

I will use science_fiction for genre from now on if a magazine contains fiction.

Thanks for your help. I'm producing a SF website http://sfnal.info to use this stuff, and will see what anomalies occur with my queries. Vicarage (talk) 15:06, 13 July 2024 (UTC)[reply]

Ignyte Awards (Q108782497)

@Vicarage:

Ignyte Awards (Q108782497) is an instance of itself? How can that be? Peter F. Patel-Schneider (talk) 10:26, 29 July 2024 (UTC)[reply]

@Peter F. Patel-Schneider Brain fart, reverted. Vicarage (talk) 11:09, 29 July 2024 (UTC)[reply]

Thanks Peter F. Patel-Schneider (talk) 11:09, 29 July 2024 (UTC)[reply]

SPARQL and "mul"

Hi,

I'm curious, what is your software you mentioned on Help_talk:Default_values_for_labels_and_aliases#SPARQL_querying (in 90% of the queries, the SERVICE is enough).

Cheers, VIGNERON (talk) 14:33, 22 August 2024 (UTC)[reply]

I'm concerned about the clumsy logic you yourself proposed to replace

OPTIONAL {?item ?keys ?k. ?k rdfs:label ?keywordlist. FILTER (LANG(?keywordlist) = "en")}

with

OPTIONAL { ?c rdfs:label ?labelEN. FILTER ( lang(?labelEN) = 'en' ) }

OPTIONAL { ?c rdfs:label ?labelMUL. FILTER ( lang(?labelMUL) = 'mul' ) }

BIND(IF(BOUND(?labelEN),?labelEN,?labelMUL) AS ?cLabel).

Its harder to read and debug, could take queries over length limits, is probably slower, and would need to be introduced in so many places. Vicarage (talk) 14:41, 22 August 2024 (UTC)[reply]

My proposition (which is just one among many possible) was for Peter F. Patel-Schneider specific problem (where he wanted "'en' if there is one, 'mul' if not,"), other situation probably need other solution ; as I said in 90% of the case the SERVICE wikibase:label is enough. So, what is *your* need? Cheers, VIGNERON (talk) 15:15, 22 August 2024 (UTC)[reply]

My need is as Peter's, "'en' if there is one, 'mul' if not, which is what I expect everyone using rdfs:label will be caught out by if there native language is replaced by mul. I have 27 usages of this in my https://help.expounder.info websites, and there are dozens in the SPARQL examples page

I've very much in favour of mul, but I can hear the screams of protest when the mass-deletion of native language labels occurs and breaks rdfs:label without the trivial rollover that SERVICE allows. We need a one line FILTER rule, preferably one that uses the SERVICE statement. Vicarage (talk) 15:28, 22 August 2024 (UTC)[reply]

Talking to Peter, it seems he doesn't need it after all ; the example he gave me is about classes, while "mul" is mostly for instance.

Do you use FILTER or the SERVICE wikibase:label ? Because, if you use the SERVICE wikibase:label, you can just replace SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". } by SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],mul,en". } (Peter can't use it because he's using QLever instead of WDQS).

Also, when I look at your website, it looks like you should use the API instead of SPARQL queries (especially as there is concern that WDQS are overused and might disappear entirely), have you considered it?

And yeah, I can imagine some screams too (not that much, only a few people actually need to query the labels, most people just need to display it and the SERVICE can easily do that), hence why I'm trying to help them.

Cheers, VIGNERON (talk) 15:59, 22 August 2024 (UTC)[reply]

You are losing my support here. I have good reasons for writing my site as I do, and am constantly pushing the boundaries of WDQS, so I hardly want to be forced off it by queries that are too long and time out into the hands of QLever, especially if it handles the mul logic even worse. I would strongly urge you to take stock of mul's progress, and be very wary of removing any en label until you are sure there will be no screams. Vicarage (talk) 16:05, 22 August 2024 (UTC)[reply]

Sorry to hear that. WDQS will probably disappear at some point, it's (almost) not a question of "if" but of "when". "mul" is an independent point (one of the motivation of "mul" is to push back the end of WDQS, but still - one way or the other - it will end some day). I do follow the progress of "mul" for more than a year now and I will never massively remove any labels (that a task for bots). There will be screams anyway, this is unavoidable, I just want to mitigate it as much as I can. Cheers, VIGNERON (talk) 16:19, 22 August 2024 (UTC)[reply]

Mulled official names

Good evening. Probably best not to include the ship prefices in the property for official names. For NoCGS Bjørnøya (Q124300634) "NoCGS" is actually an anglification of "KV" which is a uniquely norwegian ship prefix. Not sure what they do in the different countries, but if using "mul" then it would be easier to just use the name without a prefix or considering what the local custom is? Norwegian custom would be name without prefix AFAIK or that is what "Sjøfartsdirektoratet" use in their digital archives.

No point in doing any reverts IMO, but we all probably should have a consensus wrt. "mul" naming going forward. I look forward to doing some batch jobs like this myself. Regards. Infrastruktur (talk) 16:10, 3 September 2024 (UTC)[reply]

I was using https://en.wikipedia.org/wiki/Ship_prefix as guidance, and setting the mul value to the internationally accepted name of the ship, so for Swedish ship sare HSwMS, while also adding the sv version as HMS as the local name differs. The official name of a ship should certainly include its prefix for some countries (UK and USA for example) and never for others (France and Spain). Its a surprisingly tricky process given the poor quality of the label field, and inconsistency in the sources. I'd like to finish the process, and then we can review the results, and on-mass add or remove prefixes.

There are lots of edge cases where ships change countries, or navies within a country within a regime change, so its going to take a long time for me to have a consistent dataset for review.

I'm doing this partly in anticipation of https://www.wikidata.org/wiki/Help_talk:Default_values_for_labels_and_aliases, as the the mul values can be back-ported into the mul label and its aliases as a exemplar of the new approach.

Any suggestions how I could document these prefixes for the navies themselves? No existing properties seem to match. Vicarage (talk) 16:40, 3 September 2024 (UTC)[reply]

NoCGS in the english _label_ is fine IMO. The style guide on nowiki actually recommends prefix+the name in quotes for titles of articles, although personally I think that looks silly on Wikidata especially when they add all those aliases MS Skibladner, M/S Skibladner and MS «Skibladner», so I much prefer the name without quotes on Wikidata. I also think if an item uses different labels then replacing them with "mul" is not advisable. If that should include the ship prefix I'm not sure. I still don't think the prefix is suitable for native label or official name properties however as they should reflect what is the native or official name, and clearly a translation can be neither. If it is customary to include the prefix in the official name in the native language, then that's fine of course. Infrastruktur (talk) 05:43, 4 September 2024 (UTC)[reply]

transferred to https://www.wikidata.org/wiki/Wikidata_talk:WikiProject_Ships#Mulled_official_names for wider visibility. Vicarage (talk) 07:09, 4 September 2024 (UTC)[reply]

design/function/model/...

Got your message. I'll look at the RfC this afternoon. Peter F. Patel-Schneider (talk) 17:39, 20 September 2024 (UTC)[reply]

@Vicarage I updated https://www.wikidata.org/wiki/Wikidata:Requests_for_comment/object_vs_design_class_vs_functional_class_for_manufactured_objects again. Take a look. The examples section still needs some work, I think. Peter F. Patel-Schneider (talk) 14:06, 25 September 2024 (UTC)[reply]

magazine capacity

Would you mind replacing the examples with the ones you listed? Trade (talk) 13:50, 26 September 2024 (UTC)[reply]

Main subject vs field of work

Why did you change BirtwistleWiki (Q123690679) from having main subject (P921) to field of work (P101)? I think the former is more correct for a website. Sam Wilson 03:07, 21 November 2024 (UTC)[reply]

I think field of work (P101) is better for organisations and people, main subject (P921) for publications. But we have entries for websites that clearly are both organisation and publication. I've reverted my change as marginal. Vicarage (talk) 08:04, 21 November 2024 (UTC)[reply]

Ah, that makes sense, good distinction! But yeah, I think this one is mainly a publication rather than an organisation. Sam Wilson 09:42, 21 November 2024 (UTC)[reply]