W3C home > Mailing lists > Public > public-vocabs@w3.org > May 2014

Re: Better description for 'keywords' property

From: Karen Coyle <kcoyle@kcoyle.net>
Date: Tue, 20 May 2014 07:33:15 -0700
Message-ID: <537B67AB.1080700@kcoyle.net>
To: public-vocabs@w3.org
Dan, it is my experience that library systems do NOT use the term 
"keywords" for subject headings,[1] they use the term "subjects" or some 
variation thereof. So if there are some that use "keywords" I suspect 
they are in the minority, and that should not influence the use in 
schema.org. Comma-delimited keywords are very common on the Web and in 
software, and have become a kind of de facto standard.

kc

[1] Some examples from major vendors:

LC (Voyager):

Subjects: 	Republican Party (U.S. : 1854- )
	United States --Politics and government --2001-2009.

OCLC:

Subjects 	

     Snowden, Edward J., -- 1983-
     United States. -- National Security Agency/Central Security Service.
     Leaks (Disclosure of information) -- United States.

(III):

Subject 	
Iraq War, 2003-2011
Intelligence service -- United States
United States -- Politics and government -- 2001-

etc.

On 5/20/14, 6:59 AM, Dan Scott wrote:
> On Tue, May 20, 2014 at 02:17:12PM +0100, Dan Brickley wrote:
>> On 17 May 2014 06:31, Stéphane Corlosquet <scorlosquet@gmail.com> wrote:
>>> From previous conversations on this list, it looks like
>>> http://schema.org/keywords is meant to hold a list of comma-separated
>>> keywords, like the RDFa on this page:
>>> http://arc.lib.montana.edu/msu-photos/item/286:
>>>
>>> <span property="keywords">john burke, msc, football, team</span>
>>>
>>> If this is correct, the description for this property, which
>>> currently reads
>>> "The keywords/tags used to describe this content", could be a bit more
>>> detailled. I suggest:
>>>
>>> A comma-separated list of keywords/tags used to describe this content.
>>
>> This sounds reasonable to me. The only objections I can think of
>> involve trying to stretch this property too far, e.g. phrases that
>> contain commas within them. Let's keep it simple...
>>
>> Does anyone here think that this change would not be an improvement?
>
> More specificity in defintions is certainly an improvement, but in the
> absence of a "simple SKOS" mechanism, I know that software in the
> library domain typically uses "keywords" (with its range of Text) to
> express hierarchical subject headings.
>
> (Rationale: "description" seems much more appropriate for written
> abstracts or
> phrase-like constructions, while "keywords/tags" is a better match for
> the typically 1-3 word subject headings used in libraries, and nothing
> else had a range of Text that seemed like any kind of a match.)
>
> So there are currently hundreds and, as sites upgrade, will be thousands
> of library Web sites that express "keywords" like:
>
> * keywords: Linux.
> * keywords: Internet programming.
> * keywords: Web sites > Design.
> * keywords: Electronic mail systems > Security measures.
>
> This is because we augment the existing display of subject headings like
> so:
>
> <div property="keywords">
>   <a href="search?email">Electronic mail systems</a> &gt;  <a
> href="search?email+security">Security measures.</a>
> </div>
>
> If we get a simple SKOS mechanism in schema.org, we can address that in
> the software that doesn't adhere to the stricter "comma-separated list"
> definition that has been proposed, but please be aware that there are
> known sites that will not be adhering to that definition for some time
> to come.
>
> Overly long story short; how about a softened definition such as:
>
> "Keywords or tags used to describe this content. Multiple entries in a
> keywords list are typically delimited by commas."
>
> That way, we would provide guidance to future implementations without
> invalidating existing practice and making those implementers feel shamed
> about their past decisions...
>
>

-- 
Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
m: 1-510-435-8234
skype: kcoylenet
Received on Tuesday, 20 May 2014 14:33:45 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:29:41 UTC