Talk:Speeches
From cbwiki.net
Contents |
Marking as obsolete
Admin 13:22, 2 October 2007 (BST): I think it could be a good idea to mark pages from older versions of RSS-CB with an indication that they are not the current version. It is not always clear for users using bookmarks or following links from search engines that some of our specs are out of date. Of course, we should leave these pages on the wiki, as there will always be implementations based on older versions.
Please have a look at how I have done the speeches 1.0 application guide and let me know what you think. If the approach is supported, I'll put it on the other obsolete pages too.
I considered making the message more specific - i.e. directing the user straight to speeches 1.1 - but this would require more maintenance in future. It's a possibility though.
Admin 09:15, 4 October 2007 (BST): I went ahead and did it, lacking objections...
Admin 09:16, 4 October 2007 (BST): ...except I called it "deprecated", rather than "obsolete" as this is more accurate. RSS-CB 1.0 is still usable - and used. But not preferred.
Christine Sommo-FRBNY 22:09, 5 October 2007 (BST) Yes. This is a good idea. I fully support what Admin (aka Steve) is doing.
Talk
Dan Chall-FRBNY 14:33, 15 December 2006 (AST)Question: we talked briefly about the specific needs for announcing policy decisions such as rate changes (or non-changes). Isn't that a distinct category, as something different from from an event which might be testimony or a conference?
Steven Bagshaw-BIS 11:49, 19 December 2006 (AST): I can't find that it in my notes. Maybe it was after I left?
I think we can always add more application types right?
Discussion from Speeches Page
Steven Bagshaw-BIS 10:02, 14 December 2006 (AST): I've changed the headings from <item><cb:title> to <item><dc:title> (and similar for the description field) since there is a Dublin Core element for title. Comments welcome on this - maybe I missed something that was discussed?
- Elena Atayeva-FRBNY 12:06, 14 December 2006 (AST) title, link and descriptions belong to RSS 1.0 itself (for techies: default namespace defined by
xmlns='http://purl.org/rss/1.0/'). I removed namespaces from those three elements completely.
--Nicolas Kessler-SNB 10:53, 14 December 2006 (AST) Is the Speeches, Events, etc. spec an instance of the general RSS-CB spec? Then we shouldn't need to list the "Fields common to each application". If not, then we should include all the fields suggested under "Dublin Core and/or custom namespace elements" of the RSS-CB spec.
--Steven Bagshaw-BIS 11:42, 14 December 2006 (AST) Actually, I was going to ask about that next. I think that is a good idea, but I didn't want to play with the general spec and user guide too much until the application guide was organised. What do others think?
Dan Chall-FRBNY 14:33, 15 December 2006 (AST)It seems to me that a usage guide should focus on the choice of elements to include, and the content of the elements, rather than a redundant specification of the purpose of the field within RSS-CB in general. I'm not sure we've been entirely consistent with that approach.
Christine Sommo-FRBNY 14:47, 15 December 2006 (AST)Were you asking if we agreed with not touching the user guide until the application guide was finished, what the user guide should focus on, or both? Sorry if this is a bit if a dumb question. I'm tired.
Steven Bagshaw-BIS 11:46, 19 December 2006 (AST): Well, I've moved the stuff from here into the User Guide. For now, I just have an example of each. Comments or changes on this structure welcome. I was aiming for a "one stop shop" for developers with the user guide. Maybe it's overkill. But avoiding redundancy is important, yes.
Attributes or elements?
Steven Bagshaw-BIS 11:20, 14 December 2006 (AST): I am going through the notes to the meeting and updating the Wiki, also based on Christine's recent changes.
I came across this reference to needing to record the role of the speaker (e.g. "Deputy Governor"). I wanted to document this, and we already have on the Wiki first name, last name, name as written. Then I thought I would specify the role field as well, but I was wondering how it is proposed to deliver these in XML.
Approach 1
<cb:speaker firstName="Bob" lastName="Dool" nameAsWritten="Reverend Bob J. Dool" role="Super Governor"/>
or
<cb:speaker firstName="Bob" lastName="Dool" role="Super Governor">Reverend Bob J. Dool</cb:speaker>
Approach 2
<cb:speaker> <firstName>Bob</firstName> <lastName>Dool</lastName> <nameAsWritten>Reverend Bob J. Dool</nameAsWritten> <role>Super Governor</role> </cb:speaker>
Approach 3
<cb:person type="speaker" firstName="Bob" lastName="Dool" nameAsWritten="Reverend Bob J. Dool" role="Super Governor"/>
or
<cb:person type="speaker" firstName="Bob" lastName="Dool" role="Super Governor">Reverend Bob J. Dool</cb:person>
(Other types could be "author", "editor" etc)
Approach 4
<cb:person> <type>speaker</type> <firstName>Bob</firstName> <lastName>Dool</lastName> <nameAsWritten>Reverend Bob J. Dool</nameAsWritten> <role>Super Governor</role> </cb:person>
Approaches 5-20
Something else? I'm not sure what people had assumed here.
I quite like #3 myself. It's flexible, not too verbose and can handle multiple individuals nicely. Timo likes the style of #2 and #4. Comments??
Elena Atayeva-FRBNY 11:55, 14 December 2006 (AST) Multiple individuals, yes, but attributes cannot be used to express multiple properties of the same type. I vote for #2/#4 because both of them make the following possible:
<cb:person> <type>speaker</type> <firstName>Elizabeth</firstName> <firstName>Alexandra</firstName> <firstName>Mary</firstName> <lastName>Windsor</lastName> <nameAsWritten>Queen Elizabeth Alexandra Mary Windsor</nameAsWritten> <role>Queen</role> <role>Head of the Commonwealth</role> <role>Lord High Admiral</role> <role>Supreme Governor of the Church of England</role> <role>Lord of Mann</role> <role>Paramount Chief of Fiji</role> </cb:person>
Digression: Dan Chall-FRBNY 14:02, 14 December 2006 (AST)[(I'm a bit concerned about multiple first names in which order matters. Would we want an "order" attribute if we supported that? Otherwise might it not seem wrong to impute significance to the order of sub-elements without documenting it?)] : Elena Atayeva-FRBNY 14:28, 14 December 2006 (AST) Nah, we have "nameAsWritten" to express the order Dan Chall-FRBNY 14:33, 15 December 2006 (AST)So Elizabeth Alexandra Mary is equivalent in the firstname tags to Mary Elizabeth Alexandra? I'm not sure how the firstnames would be used in a manner where order would not matter.
There is no way to express this information in #1/#3.
Steven Bagshaw-BIS 12:15, 14 December 2006 (AST) You forgot Queen of Australia. I doubt we would process multiple roles in RSS-CB applications, but of course... one never knows.
--Nicolas Kessler-SNB 12:29, 14 December 2006 (AST) I'd toss this cb-person-element altogether (here I come again...) and go for foaf:Person (http://xmlns.com/foaf/0.1/#term_Person), the established standard to xmlify people. The role part could be added according to http://xmlns.sehrgut.co.uk/role/original.html. If that suggestion is OT, I would opt for Elena's proposal.
---Timo Laurmaa-BIS 14:43, 14 December 2006 (AST)Hmmm, the link to foaf:Person leads to "A number of naming constructs are under development to provide naming substructure; draft properties include foaf:firstName, foaf:givenname, and foaf:surname. These are not currently stable or consistent". Is foaf:Person or foaf:name actually used in credible places?
My take on the multiple names is that multiple first names, for our purposes, are rather theoretical (I would treat Juan Carlos as one first name, not two), whereas multiple roles are much closer to reality (Governor of the Netherlands Bank and Chairman of Basel Committee). We really need last names (for sorting) and as-written names (for presentation), most likely also the roles. And indeed, I like #4.
Dan Chall-FRBNY 14:33, 15 December 2006 (AST)I like the idea of compound firstnames. It distinguishes between a two-part first name and a two-part last name. However, there may be two-part first names that are never separated, and there are "middle names" or even middle initials that may be used in some contexts but not in others. This might matter if an aggregator wants to know that Daniel Chall is Daniel E. Chall for the purpose of serving up his many publications. The entries may look different to an automated application if the firstnames are not the same. But a missing middle name could be everything between the mandatory portion of the firstname and the lastname.
--Nicolas Kessler-SNB 18:26, 14 December 2006 (AST) The "not stable or consistent" reservation probably applies to most current ontology standardization efforts, and RSS-CB might join the club. I don't think foaf:firstName is worse than cb:firstname; should the former be replaced by something culturally/semantically more consistent, the latter would be put into question just as much. FOAF has been around for a while; some empirical findings regarding its usage (in general, not specifically concerning the firstName etc, fields) can be found in http://portal.acm.org/ft_gateway.cfm?id=1042928&type=external&coll=GUIDE&dl=GUIDE&CFID=7136512&CFTOKEN=91888615.
I am overstressing this matter a bit - for our practical purposes the cb-elements are certainly OK. I just think that, in the long run, it might be preferable to rely as much as possible on prior work.
Dan Chall-FRBNY 13:59, 14 December 2006 (AST) Getting back to one of the original questions, I think a first principle to adopt is that we'd be better off to have all "data" in elements, and reserve attributes for things that modify the elements. For example, if a date were to have different possible representations (YYMMDD or season-year) then the date representation could be an attribute of a date element. If foaf allows us to distinguish between a "durable" name and a name as it appears in a resource, then it may supply all the functionality we need. But if it doesn't meet 100 percent, then I think we'd be better off with an element defined in the CB namespace. (If there's something to be learned from "foaf" then we could use it to inform our final definition.) Also I don't know if "AsWritten" is the perfect description in a heuristic sense. AsPublished?
--Steven Bagshaw-BIS 04:43, 15 December 2006 (AST): I am OK with using the foaf:person structure in principle - or at least adapting it in the cb namespace. It would be best to stick to work already done, as Nicolas points out. It's a shame they don't have a simple way of listing roles... I'd be wary of the approach to roles Nicolas linked to. It's quite convoluted compared to our needs, seems not to have been finished and is perhaps in hibernation?
I am fairly new to these things though, so perhaps the gurus can make a decision and I'd be happy to modify the documentation as fits. This Speeches, Events and News page is now out of sync with the research guides and user guide pages - and the spec itself. I can get them back in agreement with each other, if we could decide on how to approach the Person class. If we go with Elena's approach, could we drop the multiple first names functionality for the sake of simplicity?
Whatever structure is decided for Person would probably also feed into how we do Resources (e.g. PDF, video) etc, which we need to describe with a brief title/description, the type and the link. I assume there is a standard way of doing this - do we use that?
Brent Eades-Bank of Canada 11:08, 15 December 2006 (AST) - Mm, ol' Elizabeth Alexandra Mary Windsor is Queen of Canada too. Anyway, while, like Nicolas, I prefer where feasible to re-use work others have already done, I have doubts that foaf is really suitable for our purposes (nor whether it has any any long-term prospects.) It's my sense that foaf, at present anyway, is of the most interest to the Semantic Web geek crowd; and is best suited to 'social networking' applications. I'd prefer to stick with the cb: namespace, rendered as in Elena's example.
--Steven Bagshaw-BIS 11:39, 15 December 2006 (AST): Seems fair enough to me. So then, does cb:author (as in Research Papers) become cb:person with <type>author</type> - is this the approach we take? To me, this makes sense, so we don't have to document the first name, last name, name as written, role etc. for every instance of referring to an individual. Do we then have a fixed list of valid values - editor, author, speaker etc - or just leave it for free for now? Or just stick with cb:speaker, cb:author etc. etc.?
(i.e. do we take approach 2 or 4... and do we specify the possible values of <type/> if the latter?)
Dan Chall-FRBNY 14:33, 15 December 2006 (AST)Using <person type=author /> seems reasonable, and a good way to economize on definitions. But aren't there resources that have "authors" that are institution names? Maybe that's only a matter of heuristics to insist that the <person/> tag identify only humans.
Steven Bagshaw-BIS 11:48, 19 December 2006 (AST): I've done as Dan suggested. I made a note (in User Guide now) that institutions can be specified - just use the nameAsWritten field. Comments welcome. We could change person to agent or some such term like that if we wanted to be more accurate, I suppose.
