search

ntra00 / marc2bibframe

Convert marc to BIBFRAME 1.0 - see lcnetdev/marc2bibframe2 for current release
http://www.loc.gov/bibframe/
Other
64 stars 20 forks source link

camelCased or hypthenated #2

Closed edsu closed 10 years ago

edsu commented 11 years ago

It would be nice if properties were either hyphenated or camelCased, but not both. For example:

from Instance docs.

ntra00 commented 11 years ago

I'll be really excited when that's the level of stuff remaining! Thanks for pointing it out, though.

Nate

Nate Trail LS/TECH/NDMSO Library of Congress ntra@loc.gov 202-707-2193

From: Ed Summers [mailto:notifications@github.com] Sent: Sunday, January 27, 2013 8:18 PM To: lcnetdev/marc2bibframe Subject: [marc2bibframe] camelCased or hypthenated (#2)

It would be nice if properties were either hyphenated or camelCased, but not both. For example:

from Instancehttp://bibframe.org/vocab/Instance.html docs.

— Reply to this email directly or view it on GitHubhttps://github.com/lcnetdev/marc2bibframe/issues/2.

kefo commented 11 years ago

Not saying it's correct (indeed, we should probably choose one or the other) but I think it stems from what might be deemed common practice with respect to source identifier codes, which all use hyphens [1], and "legal-deposit" number is lumped in with those because of the BIB field's (017) association with other identifiers.

Yours, Kevin

[1] http://www.loc.gov/standards/sourcelist/standard-identifier.html

On 01/28/2013 12:56 PM, ntra00 wrote:

I'll be really excited when that's the level of stuff remaining! Thanks for pointing it out, though.

Nate

Nate Trail LS/TECH/NDMSO Library of Congress ntra@loc.gov 202-707-2193

From: Ed Summers [mailto:notifications@github.com] Sent: Sunday, January 27, 2013 8:18 PM To: lcnetdev/marc2bibframe Subject: [marc2bibframe] camelCased or hypthenated (#2)

It would be nice if properties were either hyphenated or camelCased, but not both. For example:

  • supplementaryContentNote
  • legal-deposit

from Instancehttp://bibframe.org/vocab/Instance.html docs.

— Reply to this email directly or view it on GitHubhttps://github.com/lcnetdev/marc2bibframe/issues/2.

— Reply to this email directly or view it on GitHub https://github.com/lcnetdev/marc2bibframe/issues/2#issuecomment-12794578.

jronallo commented 11 years ago

If I were writing something around bibframe in Ruby, I would probably like to be able to use symbols for keys for properties for creating a new instance or other resource. Symbols are used all over the place in Ruby. Making a symbol is as simple as the following when camelCased.

:supplementaryContentNote

Having the hyphens in the property names means I would have to add quotation marks to make a symbol. Otherwise I would get an error.

:'legal-deposit'

This is a little annoyance. No big deal, but how the properties work in programming languages might be another small consideration.

ntra00 commented 11 years ago

That's useful, thanks! Nate Nate Trail LS/TECH/NDMSO Library of Congress ntra@loc.gov 202-707-2193

From: Jason Ronallo [mailto:notifications@github.com] Sent: Monday, January 28, 2013 1:53 PM To: lcnetdev/marc2bibframe Cc: Trail, Nate Subject: Re: [marc2bibframe] camelCased or hypthenated (#2)

If I were writing something around bibframe in Ruby, I would probably like to be able to use symbols for keys for properties for creating a new instance or other resource. Symbols are used all over the place in Ruby. Making a symbol is as simple as the following when camelCased.

:supplementaryContentNote

Having the hyphens in the property names means I would have to add quotation marks to make a symbol. Otherwise I would get an error.

:'legal-deposit'

This is a little annoyance. No big deal, but how the properties work in programming languages might be another small consideration.

— Reply to this email directly or view it on GitHubhttps://github.com/lcnetdev/marc2bibframe/issues/2#issuecomment-12797418.

edsu commented 11 years ago

It's mostly a problem because it's not consistent, which will lead to encoding errors. It should be trivial to fix though.

uogbuji commented 11 years ago

I'd be very careful here. I think the range of BIBFRAME vocabularies is such that we should be light-handed on conventions for representation in implementations. For example, in XML I would strongly recommend " supplementary-content-note" whereas for JSON I would strongly recommend " supplementaryContentNote"

I've always been a big advocate for the idea that vocabularies should deal in language and not codes. I think we should consider naming entities e.g. "supplementary content note" in the abstract BIBFRAME model, and leave it up to implementation and other communities to come up with translations based on naming and design rules. And of course we will want consistency in application of those.

So this is not to counter Ed's point about consistency, but actually to make a more fundamental point to which Ed's leaves.

--Uche

On Mon, Jan 28, 2013 at 2:35 PM, Ed Summers notifications@github.comwrote:

It's mostly a problem because it's not consistent, which will lead to encoding errors. It should be trivial to fix though.

— Reply to this email directly or view it on GitHubhttps://github.com/lcnetdev/marc2bibframe/issues/2#issuecomment-12806212.

Uche Ogbuji http://uche.ogbuji.net Founding Partner, Zepheira http://zepheira.com http://wearekin.org http://www.thenervousbreakdown.com/author/uogbuji/ http://copia.ogbuji.net http://www.linkedin.com/in/ucheogbuji http://twitter.com/uogbuji

edsu commented 11 years ago

I know this is a seemingly small issue, but getting consensus about it early should make development and documentation smoother. I really like @uogbuji's suggestion of keeping documentation oriented for reading by people, and then making xml and json serializations follow the convention that suits them best.

sandsfish commented 11 years ago

Just to add my observations to this, I have much more commonly seen camelCasing used in popular in RDF ontologies. Examples are:

FOAF http://xmlns.com/foaf/spec/#sec-glance

GoodRelations http://www.heppnetz.de/ontologies/goodrelations/v1#dprops

GeoNames http://www.geonames.org/ontology/documentation.html

VOID http://vocab.deri.ie/void/

Second most common would be underscoring. Not frequently hyphen-delimited. I prefer aligning with the examples above.

On Mon, Jan 28, 2013 at 1:53 PM, Jason Ronallo notifications@github.comwrote:

If I were writing something around bibframe in Ruby, I would probably like to be able to use symbols for keys for properties for creating a new instance or other resource. Symbols are used all over the place in Ruby. Making a symbol is as simple as the following when camelCased.

:supplementaryContentNote

Having the hyphens in the property names means I would have to add quotation marks to make a symbol. Otherwise I would get an error.

:'legal-deposit'

This is a little annoyance. No big deal, but how the properties work in programming languages might be another small consideration.

— Reply to this email directly or view it on GitHubhttps://github.com/lcnetdev/marc2bibframe/issues/2#issuecomment-12797418.

kefo commented 10 years ago

Don't know why this doc is here

http://loc.gov/bibframe/docs/vocab-conventions.html

but we went with camel case. If you see otherwise, it's wrong.