types

CSL Development
1

There’s one other design issue I wanted to clear up before we "finish"
and that is types and mappings.

Right now, CSL has types like “article” and “article-journal.” The
first is the required generic fallback, and the hyphen indicates a
qualifier.

In my implementation, then, I have a function that looks at the source
data and constructs a “type” that should correspond to these
expectations.

So if the processor gets an “article-magazine” it will first look for
that template, and failing that, use the “article” fallback (the source
is also categorized based on class).

This has the benefit of flexibility, but the weakness of potential
fragility.

The other option is to tie typing explicitly to my RDF schema:

<http://purl.org/net/biblio#>

That would mean types like “Article” and “JournalArticle” and
"EditedBook."

Any arguments for changing it now, or shall we just keep things as they
are?

Bruce

2

I prefer the current “article-journal” approach.

Johan

3

Been having some discussion of all the problems with types in formatting
and such over on the xbib dev list. I think the upshot of all of this
discussion is I want to say we need this for the bibo ontology:

  1. the core classes
  2. normalized URIs encoded using dcterms:type. Perhaps these can somehow
    be maintained on the bibo wiki. A resource may have one or more of these.
  3. a bibo:note property for literal descriptions of a source (e.g. where
    a URI does not exist and not convenient to create).

So an example might be:

http://www.aclu.org/freespeech/protest/11238prs20050502.html
a bibo:Document ;
dcterms:title “ACLU Applauds New D.C. Law Protecting Protest
Rights”@en ;
dcterms:issued “2005-05-02”^^xsd:date ;
dcterms:type http://purl.org/ontology/types#press_release .

… or simply:

http://www.aclu.org/freespeech/protest/11238prs20050502.html
a bibo:Document ;
dcterms:title “ACLU Applauds New D.C. Law Protecting Protest
Rights”@en ;
dcterms:issued “2005-05-02”^^xsd:date ;
bibo:note “press release”@en .

… or:

http://ex.net/1
a bibo:Document ;
dcterms:title “ideas on relativity”@en ;
dcterms:issued “1921-09-23”^^xsd:date ;
bibo:note “lab notes”@en .

An editing application can then use the URI to configure a form, or a
citation processor can use it to map to formatting templates (often a
note would be printed in the bibliography).

I don’t really see any way around needing these.

Bruce

4

Hi Bruce,

Been having some discussion of all the problems with types in formatting
and such over on the xbib dev list. I think the upshot of all of this
discussion is I want to say we need this for the bibo ontology:

  1. the core classes
  2. normalized URIs encoded using dcterms:type. Perhaps these can somehow
    be maintained on the bibo wiki. A resource may have one or more of these.

I never been against these types. Ivan said that it was more intuitive
to use rdf:type instead of dcterms:type, and I always agree with that.

So, there is what I suggest so that you get what you want so that Ivan
remain happy :slight_smile:

What I suggest is to create a bibo_types namespace, as you suggest
above. However, instead of defining individuals as we already thought
about, we would simply create new subclasses of the bibo (core) ontology.

This new bibo_types namespace will be in fact an extension module of the
ontology where more specialized classes will be defined.

What do you think?

  1. a bibo:note property for literal descriptions of a source (e.g. where
    a URI does not exist and not convenient to create).

Okay, I could accept that, however how would you describe that property?

Salutations,

Fred

5

Frederick Giasson wrote:

Hi Bruce,

Been having some discussion of all the problems with types in formatting
and such over on the xbib dev list. I think the upshot of all of this
discussion is I want to say we need this for the bibo ontology:

  1. the core classes
  2. normalized URIs encoded using dcterms:type. Perhaps these can somehow
    be maintained on the bibo wiki. A resource may have one or more of these.

I never been against these types. Ivan said that it was more intuitive
to use rdf:type instead of dcterms:type, and I always agree with that.

So, there is what I suggest so that you get what you want so that Ivan
remain happy :slight_smile:

Well, I think Ivan needs to first understand what kind of variety of
resources we’re dealing with; the use cases.

The Zotero developers are getting a lot of requests for users to be able
to store custom styles. This is for the scientist that wants to store
lab notes, the medievalist who wants to store “medieval chants”, the
historians who wants to store “postcards”, etc.

They’re actually planning to allow these custom types to be defined, and
for them to be shared.

I could easily see an explosion of such types, in totally unpredictable
ways that are fairly orthogonal to our more careful modeling. So …

What I suggest is to create a bibo_types namespace, as you suggest
above. However, instead of defining individuals as we already thought
about, we would simply create new subclasses of the bibo (core) ontology.

… while I definitely think we need to provide room for extending the
core classes, I a) think that won’t be enough, and b) we might as well
do it in the main namespace.

This new bibo_types namespace will be in fact an extension module of the
ontology where more specialized classes will be defined.

What do you think?

  1. a bibo:note property for literal descriptions of a source (e.g. where
    a URI does not exist and not convenient to create).

Okay, I could accept that, however how would you describe that property?

I think if we use note, we just borrow the definition from BibTeX.

“Any additional information that can help the reader.”

Or something like that.

Bruce

Bruce

6

Hi Bruce,

Well, I think Ivan needs to first understand what kind of variety of
resources we’re dealing with; the use cases.

The Zotero developers are getting a lot of requests for users to be able
to store custom styles. This is for the scientist that wants to store
lab notes, the medievalist who wants to store “medieval chants”, the
historians who wants to store “postcards”, etc.

They’re actually planning to allow these custom types to be defined, and
for them to be shared.

I could easily see an explosion of such types, in totally unpredictable
ways that are fairly orthogonal to our more careful modeling. So …

I don’t have to say that its certainly not a good idea for the long term
considering what it means.

However, it won’t be the goal of bibo:note?

What I suggest is to create a bibo_types namespace, as you suggest
above. However, instead of defining individuals as we already thought
about, we would simply create new subclasses of the bibo (core) ontology.

… while I definitely think we need to provide room for extending the
core classes, I a) think that won’t be enough, and b) we might as well
do it in the main namespace.

Yes we should certainly do it, however does it worth to clutter the main
ontology with them? We finally agreed on a good and well deifned base of
Classes from which we can extend to more specialized classes. We should
try to make the main ontology as easy to understand as possible. And its
why I would put these specialization in another namespace
(http://purl.org/ontology/bibo/types/)

This new bibo_types namespace will be in fact an extension module of the
ontology where more specialized classes will be defined.

What do you think?

  1. a bibo:note property for literal descriptions of a source (e.g. where
    a URI does not exist and not convenient to create).

Okay, I could accept that, however how would you describe that property?

I think if we use note, we just borrow the definition from BibTeX.

“Any additional information that can help the reader.”

Or something like that.

Well, its loose enough to put anything :slight_smile:

I probably don’t have to say that I don’t like these properties that
open the backdore for anything: kind of “generic” and “misc” properties
that say nothing.

However, in some case, in closed system where a nomenclature is used to
support that property, this could be useful.

At least, I would replace “reader” by “consumer” since it can be used by
any systems/agents (not only humans).

Salutations,

Fred

7

Frederick Giasson wrote:

Hi Bruce,

Well, I think Ivan needs to first understand what kind of variety of
resources we’re dealing with; the use cases.

The Zotero developers are getting a lot of requests for users to be able
to store custom styles. This is for the scientist that wants to store
lab notes, the medievalist who wants to store “medieval chants”, the
historians who wants to store “postcards”, etc.

They’re actually planning to allow these custom types to be defined, and
for them to be shared.

I could easily see an explosion of such types, in totally unpredictable
ways that are fairly orthogonal to our more careful modeling. So …

I don’t have to say that its certainly not a good idea for the long term
considering what it means.

I know, I know. [shrug]

However, it won’t be the goal of bibo:note?

No. This is more for machines; note (or whatever) for humans.

What I suggest is to create a bibo_types namespace, as you suggest
above. However, instead of defining individuals as we already thought
about, we would simply create new subclasses of the bibo (core) ontology.

… while I definitely think we need to provide room for extending the
core classes, I a) think that won’t be enough, and b) we might as well
do it in the main namespace.

Yes we should certainly do it, however does it worth to clutter the main
ontology with them? We finally agreed on a good and well deifned base of
Classes from which we can extend to more specialized classes. We should
try to make the main ontology as easy to understand as possible. And its
why I would put these specialization in another namespace
(http://purl.org/ontology/bibo/types/)

That’s fine; I have no strong opinion.

This new bibo_types namespace will be in fact an extension module of the
ontology where more specialized classes will be defined.

What do you think?

  1. a bibo:note property for literal descriptions of a source (e.g. where
    a URI does not exist and not convenient to create).

Okay, I could accept that, however how would you describe that property?

I think if we use note, we just borrow the definition from BibTeX.

“Any additional information that can help the reader.”

Or something like that.

Well, its loose enough to put anything :slight_smile:

I probably don’t have to say that I don’t like these properties that
open the backdore for anything: kind of “generic” and “misc” properties
that say nothing.

However, in some case, in closed system where a nomenclature is used to
support that property, this could be useful.

At least, I would replace “reader” by “consumer” since it can be used by
any systems/agents (not only humans).

I agree it’s loose, but its purpose is human consumption; not machine.
The type URIs are for the machines.

Bruce