Talk:MetaExtensions - Revision history

Nick: /* geo.position and icbm */ Replied.

2018-01-07T04:51:06Z

geo.position and icbm: Replied.

← Older revision		Revision as of 04:51, 7 January 2018
Line 363:		Line 363:

	The keyword icbm is a synonym for geo.position and geo.position is a synonym for icbm. Both can't be true, but each synonym is listed with "(different value syntax)". So, perhaps neither should be a synonym for the other, but maybe be moved into descriptions as cross-references. What should we do? [[User:Nick\|Nick]] ([[User talk:Nick\|talk]]) 06:52, 3 December 2017 (UTC)		The keyword icbm is a synonym for geo.position and geo.position is a synonym for icbm. Both can't be true, but each synonym is listed with "(different value syntax)". So, perhaps neither should be a synonym for the other, but maybe be moved into descriptions as cross-references. What should we do? [[User:Nick\|Nick]] ([[User talk:Nick\|talk]]) 06:52, 3 December 2017 (UTC)
			:Done. Resolved by delisting each as synonym of other and listing each in description as near-duplicate of other. [[User:Nick\|Nick]] ([[User talk:Nick\|talk]]) 04:51, 7 January 2018 (UTC)

	== ambivalence of synonymy for 2 geo.* keywords ==		== ambivalence of synonymy for 2 geo.* keywords ==

Nick: /* I doubt one synonym can be a synonym for more than one keyword */ Replied.

2018-01-07T04:43:19Z

I doubt one synonym can be a synonym for more than one keyword: Replied.

← Older revision		Revision as of 04:43, 7 January 2018
Line 352:		Line 352:

	[[User:Nick\|Nick]] ([[User talk:Nick\|talk]]) 06:38, 3 December 2017 (UTC)		[[User:Nick\|Nick]] ([[User talk:Nick\|talk]]) 06:38, 3 December 2017 (UTC)
			:With respect to publisher: Done. Added as synonym for dcterms.publisher only.
			:No change with respect to geographic-coverage.
			:[[User:Nick\|Nick]] ([[User talk:Nick\|talk]]) 04:43, 7 January 2018 (UTC)

	== between dc.* and dcterms.*, maybe same specs and definitions and maybe one set should be synonyms for the other ==		== between dc.* and dcterms.*, maybe same specs and definitions and maybe one set should be synonyms for the other ==

Nick: /* want to delete dir-content-pointer as now useless */ Replied.

2018-01-07T04:32:25Z

want to delete dir-content-pointer as now useless: Replied.

← Older revision		Revision as of 04:32, 7 January 2018
Line 328:		Line 328:

	I'd like to depropose dir-content-pointer (which [https://wiki.whatwg.org/index.php?title=MetaExtensions&diff=3727&oldid=3705 I originally proposed]), because HTML has acquired more elements and they can handle the same function, and handle it better. It doesn't look like it would be a good synonym for anything. Should I move it into the Failed Proposals table? or just delete it? [[User:Nick\|Nick]] ([[User talk:Nick\|talk]]) 05:37, 3 December 2017 (UTC)		I'd like to depropose dir-content-pointer (which [https://wiki.whatwg.org/index.php?title=MetaExtensions&diff=3727&oldid=3705 I originally proposed]), because HTML has acquired more elements and they can handle the same function, and handle it better. It doesn't look like it would be a good synonym for anything. Should I move it into the Failed Proposals table? or just delete it? [[User:Nick\|Nick]] ([[User talk:Nick\|talk]]) 05:37, 3 December 2017 (UTC)
			:Done. I moved it without deproposing. [[User:Nick\|Nick]] ([[User talk:Nick\|talk]]) 04:32, 7 January 2018 (UTC)

	== want to fail bot-. . . as useless and as a namespace ==		== want to fail bot-. . . as useless and as a namespace ==

Nick: /* want to fail bot-. . . as useless and as a namespace */ Replied.

2018-01-07T04:26:05Z

want to fail bot-. . . as useless and as a namespace: Replied.

← Older revision		Revision as of 04:26, 7 January 2018
Line 332:		Line 332:

	I'd like to depropose bot-. . ., which [https://wiki.whatwg.org/index.php?title=MetaExtensions&diff=3727&oldid=3705 I originally proposed]. I don't see a use for it or for developing it. Should I move it into the Failed Proposals table? [[User:Nick\|Nick]] ([[User talk:Nick\|talk]]) 05:46, 3 December 2017 (UTC)		I'd like to depropose bot-. . ., which [https://wiki.whatwg.org/index.php?title=MetaExtensions&diff=3727&oldid=3705 I originally proposed]. I don't see a use for it or for developing it. Should I move it into the Failed Proposals table? [[User:Nick\|Nick]] ([[User talk:Nick\|talk]]) 05:46, 3 December 2017 (UTC)
			:Done. I moved it. [[User:Nick\|Nick]] ([[User talk:Nick\|talk]]) 04:26, 7 January 2018 (UTC)

	== twitter:* spec deleted, unsure if found ==		== twitter:* spec deleted, unsure if found ==

Nick: /* copyright in (non-WHATWG-wiki) spec copying content from WHATWG Wiki */ new section

2017-12-03T07:29:36Z

← Older revision		Revision as of 07:29, 3 December 2017
Line 373:		Line 373:

	FSDateCreation and FSDatePublish, in the Meta Name Extensions table, have the same description: "[m]entions the date when this web page was created". The spec gives the same meaning for both: "[t]he date when this web page was created". Presumably, one description and one meaning are wrong, rather than that one name is a synonym for the other. I have emailed the organization behind the spec, asking whether FSDatePublish should be defined as "[t]he date when this web page was published" (and, by implication, whether the description at MetaExtensions should be "[m]entions the date when this web page was published" for FSDatePublish to avoid redundancy with FSDateCreation). I've invited their response here or at the MetaExtensions page and anyone else may wish to respond as well. [[User:Nick\|Nick]] ([[User talk:Nick\|talk]]) 07:04, 3 December 2017 (UTC)		FSDateCreation and FSDatePublish, in the Meta Name Extensions table, have the same description: "[m]entions the date when this web page was created". The spec gives the same meaning for both: "[t]he date when this web page was created". Presumably, one description and one meaning are wrong, rather than that one name is a synonym for the other. I have emailed the organization behind the spec, asking whether FSDatePublish should be defined as "[t]he date when this web page was published" (and, by implication, whether the description at MetaExtensions should be "[m]entions the date when this web page was published" for FSDatePublish to avoid redundancy with FSDateCreation). I've invited their response here or at the MetaExtensions page and anyone else may wish to respond as well. [[User:Nick\|Nick]] ([[User talk:Nick\|talk]]) 07:04, 3 December 2017 (UTC)

			== copyright in (non-WHATWG-wiki) spec copying content from WHATWG Wiki ==

			In writing specifications that are copied significantly from the WHATWG Wiki (I had written significantly into the wiki, which is under CC0 or (possibly for some older portions by other contributors) the MIT license), I think the law requires that the spec also be under CC0 or the MIT license. A short phrase is not copyrightable, so a short phrase can be copied without invoking this duty. Some other kinds of content are not copyrightable and thus can be freely copied. Fair use may or may not apply. Whether CC0 or the MIT license would apply to the spec depends on whether CC0 or the MIT license, respectively, applied to what is being copied from the wiki. (Identifying MIT-licensed content is complicated by the need to identify its author and then whether the author replaced the MIT license with CC0.) This is regardless of where the spec is published or hosted or by whom the spec is created. This may be true only in the U.S. or in other nations; I don't know about other nations' laws. This does not apply to an underlying concept or information but to the expression of it, so writing in original words generally allows other treatment of copyright. While CC0 might not have to apply to portions of the spec that were not copied from CC0 material, the MIT license might have to be applied to the entire spec. In general, CC0 or the MIT license would have to apply to some or all of an off-Wiki spec that is liberally copied from the Wiki, even to portions that were not themselves copied. (If that were not true, then I could photocopy the original works of Shakespeare and Mozart and, with or without making a few modern changes, secure a new copyright for myself on what they wrote, making a fortune from the process.) [[User:Nick\|Nick]] ([[User talk:Nick\|talk]]) 07:29, 3 December 2017 (UTC)

Nick: /* FSDateCreation and FSDatePublish have exact same meaning */ new section

2017-12-03T07:04:09Z

FSDateCreation and FSDatePublish have exact same meaning: new section

← Older revision		Revision as of 07:04, 3 December 2017
Line 369:		Line 369:

	[[User:Nick\|Nick]] ([[User talk:Nick\|talk]]) 06:57, 3 December 2017 (UTC)		[[User:Nick\|Nick]] ([[User talk:Nick\|talk]]) 06:57, 3 December 2017 (UTC)

			== FSDateCreation and FSDatePublish have exact same meaning ==

			FSDateCreation and FSDatePublish, in the Meta Name Extensions table, have the same description: "[m]entions the date when this web page was created". The spec gives the same meaning for both: "[t]he date when this web page was created". Presumably, one description and one meaning are wrong, rather than that one name is a synonym for the other. I have emailed the organization behind the spec, asking whether FSDatePublish should be defined as "[t]he date when this web page was published" (and, by implication, whether the description at MetaExtensions should be "[m]entions the date when this web page was published" for FSDatePublish to avoid redundancy with FSDateCreation). I've invited their response here or at the MetaExtensions page and anyone else may wish to respond as well. [[User:Nick\|Nick]] ([[User talk:Nick\|talk]]) 07:04, 3 December 2017 (UTC)

Nick: /* ambivalence of synonymy for 2 geo.* keywords */ new section

2017-12-03T06:57:50Z

ambivalence of synonymy for 2 geo.* keywords: new section

← Older revision		Revision as of 06:57, 3 December 2017
Line 358:		Line 358:

	The keyword icbm is a synonym for geo.position and geo.position is a synonym for icbm. Both can't be true, but each synonym is listed with "(different value syntax)". So, perhaps neither should be a synonym for the other, but maybe be moved into descriptions as cross-references. What should we do? [[User:Nick\|Nick]] ([[User talk:Nick\|talk]]) 06:52, 3 December 2017 (UTC)		The keyword icbm is a synonym for geo.position and geo.position is a synonym for icbm. Both can't be true, but each synonym is listed with "(different value syntax)". So, perhaps neither should be a synonym for the other, but maybe be moved into descriptions as cross-references. What should we do? [[User:Nick\|Nick]] ([[User talk:Nick\|talk]]) 06:52, 3 December 2017 (UTC)

			== ambivalence of synonymy for 2 geo.* keywords ==

			Two names in geo.* seem to be only ambivalent synonyms:

			* "geo.region": "Superseded by either geo.country alone or geo.country plus geo.a1. Name of geographic region to which the page is related. Content is specified by ISO-3166." Therefore, geo.region is a synonym, but of what?
			* "geo.placename": "Superseded by geo.lmk. Name of geographic place to which the page is related."/"<meta name='geo.placename' content='London, Ontario'>" Therefore, geo.placename is a synonym, but the example seems to make it a synonym of geo.a3, not of geo.lmk.

			What should we do?

			[[User:Nick\|Nick]] ([[User talk:Nick\|talk]]) 06:57, 3 December 2017 (UTC)

Nick: /* geo.position and icbm */ new section

2017-12-03T06:52:35Z

geo.position and icbm: new section

← Older revision		Revision as of 06:52, 3 December 2017
Line 354:		Line 354:

	In the Meta Name Extensions table, entries for dc.publisher and dcterms.publisher link to the same spec; likewise for dc.created and dcterms.created and dc.creator and dcterms.creator. That's enough sampling. I thought there's an error in one set of links (for either dc.* or dcterms.*), but then I read what the proponent of both sets (DCMI (Dublin Core)) said at an archived page (https://github.com/dcmi/repository/blob/master/mediawiki_wiki/FAQ/DC_and_DCTERMS_Namespaces.md as accessed 11-25-17 ("[i]mplementers may freely choose to use these fifteen properties either in their original dc: variant (e.g., http://purl.org/dc/elements/1.1/creator) or in the dcterms: variant (e.g., http://purl.org/dc/terms/creator) depending on application requirements")) and I'm confused by the page. It looks like, for WHATWG purposes, one set of keywords should be made into synonyms for the other, except that DCMI supports using either set for new pages and not just for legacy content. I've had problems with DCMI's lack of clarity before, on various aspects, and I don't think emailing them will help, although they've changed some of their people over the years. What do you think? [[User:Nick\|Nick]] ([[User talk:Nick\|talk]]) 06:42, 3 December 2017 (UTC)		In the Meta Name Extensions table, entries for dc.publisher and dcterms.publisher link to the same spec; likewise for dc.created and dcterms.created and dc.creator and dcterms.creator. That's enough sampling. I thought there's an error in one set of links (for either dc.* or dcterms.*), but then I read what the proponent of both sets (DCMI (Dublin Core)) said at an archived page (https://github.com/dcmi/repository/blob/master/mediawiki_wiki/FAQ/DC_and_DCTERMS_Namespaces.md as accessed 11-25-17 ("[i]mplementers may freely choose to use these fifteen properties either in their original dc: variant (e.g., http://purl.org/dc/elements/1.1/creator) or in the dcterms: variant (e.g., http://purl.org/dc/terms/creator) depending on application requirements")) and I'm confused by the page. It looks like, for WHATWG purposes, one set of keywords should be made into synonyms for the other, except that DCMI supports using either set for new pages and not just for legacy content. I've had problems with DCMI's lack of clarity before, on various aspects, and I don't think emailing them will help, although they've changed some of their people over the years. What do you think? [[User:Nick\|Nick]] ([[User talk:Nick\|talk]]) 06:42, 3 December 2017 (UTC)

			== geo.position and icbm ==

			The keyword icbm is a synonym for geo.position and geo.position is a synonym for icbm. Both can't be true, but each synonym is listed with "(different value syntax)". So, perhaps neither should be a synonym for the other, but maybe be moved into descriptions as cross-references. What should we do? [[User:Nick\|Nick]] ([[User talk:Nick\|talk]]) 06:52, 3 December 2017 (UTC)

Nick: /* between dc.* and dcterms., maybe same specs and definitions and maybe one set should be synonyms for the other / new section

2017-12-03T06:42:50Z

between dc.* and dcterms.*, maybe same specs and definitions and maybe one set should be synonyms for the other: new section

← Older revision		Revision as of 06:42, 3 December 2017
Line 350:		Line 350:

	[[User:Nick\|Nick]] ([[User talk:Nick\|talk]]) 06:38, 3 December 2017 (UTC)		[[User:Nick\|Nick]] ([[User talk:Nick\|talk]]) 06:38, 3 December 2017 (UTC)

			== between dc.* and dcterms.*, maybe same specs and definitions and maybe one set should be synonyms for the other ==

			In the Meta Name Extensions table, entries for dc.publisher and dcterms.publisher link to the same spec; likewise for dc.created and dcterms.created and dc.creator and dcterms.creator. That's enough sampling. I thought there's an error in one set of links (for either dc.* or dcterms.*), but then I read what the proponent of both sets (DCMI (Dublin Core)) said at an archived page (https://github.com/dcmi/repository/blob/master/mediawiki_wiki/FAQ/DC_and_DCTERMS_Namespaces.md as accessed 11-25-17 ("[i]mplementers may freely choose to use these fifteen properties either in their original dc: variant (e.g., http://purl.org/dc/elements/1.1/creator) or in the dcterms: variant (e.g., http://purl.org/dc/terms/creator) depending on application requirements")) and I'm confused by the page. It looks like, for WHATWG purposes, one set of keywords should be made into synonyms for the other, except that DCMI supports using either set for new pages and not just for legacy content. I've had problems with DCMI's lack of clarity before, on various aspects, and I don't think emailing them will help, although they've changed some of their people over the years. What do you think? [[User:Nick\|Nick]] ([[User talk:Nick\|talk]]) 06:42, 3 December 2017 (UTC)

Nick: /* I doubt one synonym can be a synonym for more than one keyword */ new section

2017-12-03T06:38:16Z

I doubt one synonym can be a synonym for more than one keyword: new section

← Older revision		Revision as of 06:38, 3 December 2017
Line 340:		Line 340:

	The description for twitter:domain used to say, "the domain of the website (added w/ API 1.1)". I thought that meant example.com for a website at http://example.com and surely Twitter has the technology to parse a URL to extract the host domain of anyone's website. But it turns out that the meta name may be for a different purpose. See https://twittercommunity.com/t/twitter-domain/64463 (as accessed 11-29-17). I rewrote accordingly but without much detail and not based on a spec. I did not find a spec for that name. When I sampled some dates for that link's URL at archive.org for twitter:domain I did not find the meta name there and probably wouldn't want to use a deleted spec anyway. [[User:Nick\|Nick]] ([[User talk:Nick\|talk]]) 06:26, 3 December 2017 (UTC)		The description for twitter:domain used to say, "the domain of the website (added w/ API 1.1)". I thought that meant example.com for a website at http://example.com and surely Twitter has the technology to parse a URL to extract the host domain of anyone's website. But it turns out that the meta name may be for a different purpose. See https://twittercommunity.com/t/twitter-domain/64463 (as accessed 11-29-17). I rewrote accordingly but without much detail and not based on a spec. I did not find a spec for that name. When I sampled some dates for that link's URL at archive.org for twitter:domain I did not find the meta name there and probably wouldn't want to use a deleted spec anyway. [[User:Nick\|Nick]] ([[User talk:Nick\|talk]]) 06:26, 3 December 2017 (UTC)

			== I doubt one synonym can be a synonym for more than one keyword ==

			Two situations:

			There was a metatag name "publisher". I [https://wiki.whatwg.org/index.php?title=MetaExtensions&diff=3624&oldid=3540 proposed] it. It was [https://wiki.whatwg.org/index.php?title=MetaExtensions&diff=9424&oldid=9423 deleted]. I have written a [http://brittlebit.org/specifications/html-meta-publisher/specification-for-html-meta-element-with-name-value-publisher.html spec] which is more precise than that for dc.publisher, dcterms.publisher, or citation_publisher, but now that spec looks unnecessary. I would like to put the word back into MetaExtensions, but as a synonym, which doesn't need a spec. This could be a synonym for more than one present-day keyword. Should I add it to all of them or only to one and, if only to one, to which one? Possibilities are citation_publisher, dc.publisher, and dcterms.publisher. My guess is the last, but that's a flimsy guess.

			The metatg name "geographic-coverage", which I introduced, did not meet requirements for registration, and should not be developed further, could be a synonym for any value in the geo.* enumerated names or for dcterms.spatial. I chose the last. If there's another preference, please edit or reply.

			[[User:Nick\|Nick]] ([[User talk:Nick\|talk]]) 06:38, 3 December 2017 (UTC)