Spam at http://bibliontology.com/tracker

[Dan Scott]

While I've meant to join the list for some time because I'm deeply interested in bibliographic ontologies, and am working as part of the Schema.org Bibliographic Extension community group [1] to improve the state of things over in schema.org, sadly my primary motivation for finally doing it is to report the spam at http://bibliontology.com/tracker.

Looks like it's just one account and from some time ago, but hopefully someone can make it go away and stop!

Thanks,
Dan

1. http://www.w3.org/community/schemabibex/

[Bruce D'Arcus]

Thanks Dan, and welcome.

And yes, I definitely see bibo have a lot of conceptual overlap with
schema.org.

I've been involved in a lot of earlier discussions around embedded
bibliographic markup (with, say, the microformat community). I will
say, based on that, that the key design question is whether you go
flat key-value (which is often the initial impulse), or whether you
have some level of relational design. BIBO tries to hit a sweet-spot
that works for the vast majority of citation-oriented use cases (many
of which the flat approaches, that start with bibtex, ignore).

Shout if you have any questions.

> --
> You received this message because you are subscribed to the Google Groups "Bibliographic Ontology Specification Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to bibliographic-ontology-spec...@googlegroups.com.
> To post to this group, send email to bibliographic-ontolog...@googlegroups.com.
> Visit this group at http://groups.google.com/group/bibliographic-ontology-specification-group.
> For more options, visit https://groups.google.com/groups/opt_out.

[Dan Scott]

On Monday, December 9, 2013 12:17:50 PM UTC-5, Bruce D'Arcus wrote:

Thanks Dan, and welcome.

Thanks!

 

And yes, I definitely see bibo have a lot of conceptual overlap with
schema.org.

I've been involved in a lot of earlier discussions around embedded
bibliographic markup (with, say, the microformat community). I will
say, based on that, that the key design question is whether you go
flat key-value (which is often the initial impulse), or whether you
have some level of relational design. BIBO tries to hit a sweet-spot
that works for the vast majority of citation-oriented use cases (many
of which the flat approaches, that start with bibtex, ignore).

Shout if you have any questions.

Thanks for the open offer! Since you mentioned flatness vs. relational design, that happens to be a very hot topic in #schemabibex land right now.

We're currently mulling over Periodical / Article relationships. The proposals on the table are to have Periodical / PeriodicalVolume / PeriodicalIssue / Article (with direct relationships possible between Periodical and Article), or a much flatter Periodical -> Article approach.

At this point, I'm in favour of the more relational approach (confession: I wrote most of it), but now that I've seen what Bibo has done (thanks to Ross Singer for the nudge) with the Periodical -> Issue -> Article, I'm willing to cut out PeriodicalVolume so that our ontologies can more or less line up. Before doing that, though, I'd like to ask if there are any strong regrets about not breaking out Volume as its own class. I'm guessing no, as you probably would have modified the schema if a compelling use case had turned up, but given that you offered, I thought it was worthwhile confirming before we forge ahead :)

Thanks,

Dan 

[Bruce D'Arcus]

On Mon, Dec 9, 2013 at 7:34 PM, Dan Scott <den...@gmail.com> wrote:

[snip]

> At this point, I'm in favour of the more relational approach (confession: I
> wrote most of it), but now that I've seen what Bibo has done (thanks to Ross
> Singer for the nudge) with the Periodical -> Issue -> Article, I'm willing
> to cut out PeriodicalVolume so that our ontologies can more or less line up.
> Before doing that, though, I'd like to ask if there are any strong regrets
> about not breaking out Volume as its own class. I'm guessing no, as you
> probably would have modified the schema if a compelling use case had turned
> up, but given that you offered, I thought it was worthwhile confirming
> before we forge ahead :)

As you probably realize, there's trade-offs, and costs to complexity.

A volume is a level of abstraction that I would say is largely
meaningless for purposes of citations. So I don't think it's worth the
extra modeling complexity, and so we capture what we need with a
simple data property (text string).

So no, I don't miss it.

But I'm a scholar. I'm guessing library folks here may have another view though?

Bruce

[Frederick Giasson]

Hi Dan,

Sorry about that, and thanks for reporting. I just finished to clean the
site and everything should be back to normal.

Thanks,

Fred