Making A 'Manageable' Ontology
Pipian
I have, especially with regards to 'implementability'.
1. There are a LOT of terms, many of which are unnecessary for a core
language. While I doubt there's too much of a problem with the
actual vocabulary supporting this many terms, I think benefit would
be gained by specifying a subset of the vocabulary a 'core
vocabulary' that is more or less necessary for implementation of a
minimally satisfactory bibliography. (e.g. many of the Law classes,
and likewise, Science classes, should probably not be included. Only
include those present in almost all fields, e.g. bibo:Book,
bibo:Journal, bibo:Magazine, bibo:Article, and maybe a few more.)
Many of the relations too are also rather serving specific niches,
and might be better served by being removed from a core vocabulary.
Having a smaller core vocabulary may also encourage extension of the
vocabulary (like that of FOAF), uptake of the vocabulary (as the
smaller subset can be standardized more quickly), and, most
importantly, help to bring larger producers of this sort of data
(e.g. libraries, Citeseer, etc.) into the fold to help promote the
vocab. I mean, client-side vocabs are nice and all, but if there's
no significant server-side production of this vocabulary,
standardization will never happen.
Other advantages include the fact that a smaller core vocabulary
means that the vocabulary itself can be used for more use cases than
even we can think up. For example, we don't need to cover 'how many
chapters this book has', but someone else can worry about that.
Likewise, libraries can go ahead and extend the vocab with a
'checkedout/reserved' property without our intervention. I think
this vocab should really have those interested in individual use
cases focus on those parts separately, rather than trying to throw
everything and the kitchen sink into the vocabulary.
Finally, a smaller core vocabulary can make ontology mapping much
much easier. Remember that there are a good number of vocabularies
out there that attempt only to map BibTeX to RDF. The simpler the
core is, the easier it is to map ontologies (even if they're lossy).
2. Many of the ranges that do not reference specific classes
reference rdfs:Literal without being more specific. Can we type more
properties with XML Schema Datatypes?
3. For use cases that do not have some sort of authoritative human
input, it's liable that, to be completely accurate, excessive
foaf:Person bnodes will need to be created due to an inability to use
a heuristic to combine authors of works. Is there some way to be
able to semantically imply a 'disambiguation' element for names of
people rather than defining however many bnodes, or is this an
implementation problem?
4. In relation to 2, several of the properties can be specified in
more than one way. For example, a DOI generally only has context in
a digital environment, together with a URL. BibTeX files are rather
vague in particular on that property, with some files using only the
number, and others using some sort of dereferenceable URL that
describes the DOI. This makes a conversion between BibTeX and the
ontology somewhat more complicated.
5. A one-to-one mapping between BibTeX and this ontology is
difficult. In particular, the semantics of each BibTeX type implies,
usually, a bibo:Article, with some implication as to the type of the
object of its dcterms:partOf statement. This introduces some
ambiguity to translations.
6. While status and thesis degree type seem simple enough to be
individuals, I'm not sure event types should be considered instances,
as there's really no significant gain to be had from not making them
simply subclasses of event:Event. The roles are also somewhat
questionable, but in a way, I suspect it makes more sense, because a
foaf:Person may have more than one role in a set of different documents.
7. I'm not sure if bibo:position will be satisfactory for all SPARQL
queries (e.g. "find me titles of papers where an author with the name
of 'X' is first", or likewise, but "where the name of 'X' comes
before 'Y' and 'X' is one of the first three contributors")
8. I think one possible large usecase requires bibo:cites and
bibo:citedBy properties (owl:inverseProperties of course), so as to
take advantage of the sorts of links that FOAF does well at
describing (e.g. foaf:knows).
Ian Jacobi
Bruce D'Arcus
> 1. There are a LOT of terms, many of which are unnecessary for a core
> language. While I doubt there's too much of a problem with the
> actual vocabulary supporting this many terms, I think benefit would
> be gained by specifying a subset of the vocabulary a 'core
> vocabulary' that is more or less necessary for implementation of a
> minimally satisfactory bibliography. (e.g. many of the Law classes,
> and likewise, Science classes, should probably not be included. Only
> include those present in almost all fields, e.g. bibo:Book,
> bibo:Journal, bibo:Magazine, bibo:Article, and maybe a few more.)
>
> Many of the relations too are also rather serving specific niches,
> and might be better served by being removed from a core vocabulary.
I'm rather agnostic about this. I agree the focus is to encourage
adoption. Whether it's with using one namespace with a lot of URIs, or
two or more, I'm not sure. I see pros and cons to each. Really depends
on what developers (you included) think.
But I would not support dropping terms altogether.
...
> Finally, a smaller core vocabulary can make ontology mapping much
> much easier. Remember that there are a good number of vocabularies
> out there that attempt only to map BibTeX to RDF. The simpler the
> core is, the easier it is to map ontologies (even if they're lossy).
Just a personal note on my background that might explain some of my
thinking on this. I am a publishing scholar who works at the border of
the social sciences and humanities. I have always been intensely
frustrated by the lossyness of BibTeX. E.g. I started on this ontology
precisely to avoid all of the limitations I found in all the stuff out
there based on BibTeX.
Still, that doesn't preclude splitting the vocabulary if people think it
a good idea.
> 2. Many of the ranges that do not reference specific classes
> reference rdfs:Literal without being more specific. Can we type more
> properties with XML Schema Datatypes?
Fred seems to be rather down on datatyping in general, but it makes
sense to me.
> 3. For use cases that do not have some sort of authoritative human
> input, it's liable that, to be completely accurate, excessive
> foaf:Person bnodes will need to be created due to an inability to use
> a heuristic to combine authors of works. Is there some way to be
> able to semantically imply a 'disambiguation' element for names of
> people rather than defining however many bnodes, or is this an
> implementation problem?
Use dc:creator? You're hitting on the more tricky problems we've had to
deal with. We went through a variety of different ideas, and this seemed
like the least bad one.
> 4. In relation to 2, several of the properties can be specified in
> more than one way. For example, a DOI generally only has context in
> a digital environment, together with a URL. BibTeX files are rather
> vague in particular on that property, with some files using only the
> number, and others using some sort of dereferenceable URL that
> describes the DOI. This makes a conversion between BibTeX and the
> ontology somewhat more complicated.
As we use it, the DOI should be a number without any prefix. I guess
you're saying it might be hard to take a BibTeX (or other legacy format)
file that has it encoded as a URL and convert it to that?
If yes, then perhaps an alternative is to dump it into the URI property
instead?
> 5. A one-to-one mapping between BibTeX and this ontology is
> difficult. In particular, the semantics of each BibTeX type implies,
> usually, a bibo:Article, with some implication as to the type of the
> object of its dcterms:partOf statement. This introduces some
> ambiguity to translations.
It is not a design goal to support 1-1 mapping to BibTeX at the expense
of support for other formats (RIS, Refer, MARC, the new OOXML format,
etc.), or general clarity.
I suppose you're saying you'd prefer to have subclasses like
JournalArticle and MagazineArticle rather than to have to look at the
related container class?
I don't have a strong opinion on this, though have at until now
preferred not to do that. I could probably be convinced otherwise.
> 6. While status and thesis degree type seem simple enough to be
> individuals, I'm not sure event types should be considered instances,
> as there's really no significant gain to be had from not making them
> simply subclasses of event:Event.
I agree.
> The roles are also somewhat questionable, but in a way, I suspect it makes more sense, because a
> foaf:Person may have more than one role in a set of different documents.
Exactly.
> 7. I'm not sure if bibo:position will be satisfactory for all SPARQL
> queries (e.g. "find me titles of papers where an author with the name
> of 'X' is first", or likewise, but "where the name of 'X' comes
> before 'Y' and 'X' is one of the first three contributors")
Not sure what you're getting at here.
> 8. I think one possible large usecase requires bibo:cites and
> bibo:citedBy properties (owl:inverseProperties of course), so as to
> take advantage of the sorts of links that FOAF does well at
> describing (e.g. foaf:knows).
Agree.
Bruce
Pipian
On Sep 22, 2007, at 3:20 PM, Bruce D'Arcus wrote:
>
> Pipian wrote:
>
>> 1. There are a LOT of terms, many of which are unnecessary for a core
>> language. While I doubt there's too much of a problem with the
>> actual vocabulary supporting this many terms, I think benefit would
>> be gained by specifying a subset of the vocabulary a 'core
>> vocabulary' that is more or less necessary for implementation of a
>> minimally satisfactory bibliography. (e.g. many of the Law classes,
>> and likewise, Science classes, should probably not be included. Only
>> include those present in almost all fields, e.g. bibo:Book,
>> bibo:Journal, bibo:Magazine, bibo:Article, and maybe a few more.)
>>
>> Many of the relations too are also rather serving specific niches,
>> and might be better served by being removed from a core vocabulary.
>
> I'm rather agnostic about this. I agree the focus is to encourage
> adoption. Whether it's with using one namespace with a lot of URIs, or
> two or more, I'm not sure. I see pros and cons to each. Really depends
> on what developers (you included) think.
>
> But I would not support dropping terms altogether.
And with the flexibility of RDF, there's no reason we should. Move
into another 'extension' ontology, perhaps. Include as 'non-core',
perhaps, but I agree that there's really no reason to never implement
these terms.
>> Finally, a smaller core vocabulary can make ontology mapping much
>> much easier. Remember that there are a good number of vocabularies
>> out there that attempt only to map BibTeX to RDF. The simpler the
>> core is, the easier it is to map ontologies (even if they're lossy).
>
> Just a personal note on my background that might explain some of my
> thinking on this. I am a publishing scholar who works at the border of
> the social sciences and humanities. I have always been intensely
> frustrated by the lossyness of BibTeX. E.g. I started on this ontology
> precisely to avoid all of the limitations I found in all the stuff out
> there based on BibTeX.
>
> Still, that doesn't preclude splitting the vocabulary if people
> think it
> a good idea.
I'm merely mentioning BibTeX because of its prevalence in my field
(CS/Physics), and the fact that it does cover many cases that are
prevalent in almost all citations. It may handle court cases (and
other humanities papers) horribly, but there are core terms common to
both.
Basically, what I'm suggesting is that we formalize a core vocabulary
as the intersection of both science and humanities needs (which may
also end up being a subset of all other bibliographic data stores as
well), rather than the union (and then extending it as needed for
each case). This allows for minimizing base vocabulary and
maximizing the extension capabilities for each field.
>> 3. For use cases that do not have some sort of authoritative human
>> input, it's liable that, to be completely accurate, excessive
>> foaf:Person bnodes will need to be created due to an inability to use
>> a heuristic to combine authors of works. Is there some way to be
>> able to semantically imply a 'disambiguation' element for names of
>> people rather than defining however many bnodes, or is this an
>> implementation problem?
>
> Use dc:creator? You're hitting on the more tricky problems we've
> had to
> deal with. We went through a variety of different ideas, and this
> seemed
> like the least bad one.
That is an option, after paging through some documents that mention
the differences between dc:creator and, say, foaf:maker (i.e.
DatatypeProperty and ObjectProperty). This could be a usable (if not
necessarily perfect) solution, especially considering that any
dc:creator properties are unlikely to actually have to be revoked
through the addition of an actual bibo:contributor link.
>> 4. In relation to 2, several of the properties can be specified in
>> more than one way. For example, a DOI generally only has context in
>> a digital environment, together with a URL. BibTeX files are rather
>> vague in particular on that property, with some files using only the
>> number, and others using some sort of dereferenceable URL that
>> describes the DOI. This makes a conversion between BibTeX and the
>> ontology somewhat more complicated.
>
> As we use it, the DOI should be a number without any prefix. I guess
> you're saying it might be hard to take a BibTeX (or other legacy
> format)
> file that has it encoded as a URL and convert it to that?
>
> If yes, then perhaps an alternative is to dump it into the URI
> property
> instead?
That's certainly an option.
>> 5. A one-to-one mapping between BibTeX and this ontology is
>> difficult. In particular, the semantics of each BibTeX type implies,
>> usually, a bibo:Article, with some implication as to the type of the
>> object of its dcterms:partOf statement. This introduces some
>> ambiguity to translations.
>
> It is not a design goal to support 1-1 mapping to BibTeX at the
> expense
> of support for other formats (RIS, Refer, MARC, the new OOXML format,
> etc.), or general clarity.
>
> I suppose you're saying you'd prefer to have subclasses like
> JournalArticle and MagazineArticle rather than to have to look at the
> related container class?
>
> I don't have a strong opinion on this, though have at until now
> preferred not to do that. I could probably be convinced otherwise.
There's certainly a benefit to doing so. I don't necessarily think
that we can map back to BibTeX losslessly in every case, but I think
that a mechanism should be built in so that we don't actually lose
data when we go BibTeX -> bibo -> BibTeX. (Which is quite possible
if, say, we don't actually specify any data in a dcterms:isPartOf
property.)
In this case, we'll almost certainly need to have some sort of bnode
only with its rdf:type specified in order to definitively determine
this... Something like?
:somearticle a bibo:Article;
dcterms:isPartOf [ a bibo:Proceedings ];
for @inproceedings, if no other information about the proceedings is
provided...
I'm not so concerned about trying to map data INTO BibTeX, as much as
retaining all information from BibTeX so that it can be translated
losslessly, rather than making sure that EVERYTHING in bibo can be
translated losslessly.
So I guess I'm hoping for an inverse mapping from bibo to BibTeX such
that the MAXIMUM amount of data is conserved.
>> 7. I'm not sure if bibo:position will be satisfactory for all SPARQL
>> queries (e.g. "find me titles of papers where an author with the name
>> of 'X' is first", or likewise, but "where the name of 'X' comes
>> before 'Y' and 'X' is one of the first three contributors")
>
> Not sure what you're getting at here.
I'm wondering if it's possible to craft a SPARQL query on an RDF
dataset using the bibo vocabulary for these more difficult queries
(assuming that we follow the standard range/domain)
Ian Jacobi
Pipian
> expense
> of support for other formats (RIS, Refer, MARC, the new OOXML format,
> etc.), or general clarity.
<snip>
Forgot to add to my last message: There's certainly nothing wrong
with the idea of making the BibTeX-full-mapping an extension to the
vocabulary, and could be one excellent example of how a core
vocabulary (and perhaps some limited 'common' extensions) could be
very flexible so as to allow lossless conversion of BibTeX data.
Ian Jacobi
Bruce D'Arcus
...
> I'm merely mentioning BibTeX because of its prevalence in my field
> (CS/Physics), and the fact that it does cover many cases that are
> prevalent in almost all citations. It may handle court cases (and
> other humanities papers) horribly, but there are core terms common to
> both.
And there are types in BibTeX which are specific to the sciences (the
proceedings stuff, technical report, and one or two others perhaps). So
if we were to split the ontology, I'd vote for splitting this stuff out
as well. ;-)
> Basically, what I'm suggesting is that we formalize a core vocabulary
> as the intersection of both science and humanities needs (which may
> also end up being a subset of all other bibliographic data stores as
> well), rather than the union (and then extending it as needed for
> each case). This allows for minimizing base vocabulary and
> maximizing the extension capabilities for each field.
My immediate use case is having a complete solution for use in Zotero
and OpenDocument/OpenOffice. Both of those need to cover the full range.
The question here is ultimately a social question more than a technical
one, so am happy to hear what others have to say about it.
>>> 3. For use cases that do not have some sort of authoritative human
>>> input, it's liable that, to be completely accurate, excessive
>>> foaf:Person bnodes will need to be created due to an inability to use
>>> a heuristic to combine authors of works. Is there some way to be
>>> able to semantically imply a 'disambiguation' element for names of
>>> people rather than defining however many bnodes, or is this an
>>> implementation problem?
>> Use dc:creator? You're hitting on the more tricky problems we've
>> had to
>> deal with. We went through a variety of different ideas, and this
>> seemed
>> like the least bad one.
>
> That is an option, after paging through some documents that mention
> the differences between dc:creator and, say, foaf:maker (i.e.
> DatatypeProperty and ObjectProperty). This could be a usable (if not
> necessarily perfect) solution, especially considering that any
> dc:creator properties are unlikely to actually have to be revoked
> through the addition of an actual bibo:contributor link.
Right. We also, BTW, once had a property something like
bibo:authorSortString, but that has other problems.
...
True, though I'd presume you'd always know the title of the proceedings
at least?
> I'm not so concerned about trying to map data INTO BibTeX, as much as
> retaining all information from BibTeX so that it can be translated
> losslessly, rather than making sure that EVERYTHING in bibo can be
> translated losslessly.
>
> So I guess I'm hoping for an inverse mapping from bibo to BibTeX such
> that the MAXIMUM amount of data is conserved.
But how do you reconcile that with the same desire for other formats?
I'm my field, RIS (or Endnote) is far more common legacy exchange format
than BibTeX, and it has some pretty funky types that don't make much
sense in the context of a new ontology. Does that mean we should create
classes for every one of them just to preserve lossless mapping of types?
I don't have a big problem with JournalArticle, for example, but I do
have a problem if we have to invent full subclasses for every possible
relation out there.
>>> 7. I'm not sure if bibo:position will be satisfactory for all SPARQL
>>> queries (e.g. "find me titles of papers where an author with the name
>>> of 'X' is first", or likewise, but "where the name of 'X' comes
>>> before 'Y' and 'X' is one of the first three contributors")
>> Not sure what you're getting at here.
>
> I'm wondering if it's possible to craft a SPARQL query on an RDF
> dataset using the bibo vocabulary for these more difficult queries
> (assuming that we follow the standard range/domain)
I'm not much of an expert on SPARQL, so hopefully someone else can help
with this. Will say this was originally recommended to me as likely be
the solution most suitable to SPARQL querying (as opposed to using
rdf:Seq or rdf:List).
Bruce
Pipian
On Sep 22, 2007, at 8:17 PM, Bruce D'Arcus wrote:
>
> Pipian wrote:
>
> ...
>
>> I'm merely mentioning BibTeX because of its prevalence in my field
>> (CS/Physics), and the fact that it does cover many cases that are
>> prevalent in almost all citations. It may handle court cases (and
>> other humanities papers) horribly, but there are core terms common to
>> both.
>
> And there are types in BibTeX which are specific to the sciences (the
> proceedings stuff, technical report, and one or two others
> perhaps). So
> if we were to split the ontology, I'd vote for splitting this stuff
> out
> as well. ;-)
As would I. :-)
>> Basically, what I'm suggesting is that we formalize a core vocabulary
>> as the intersection of both science and humanities needs (which may
>> also end up being a subset of all other bibliographic data stores as
>> well), rather than the union (and then extending it as needed for
>> each case). This allows for minimizing base vocabulary and
>> maximizing the extension capabilities for each field.
>
> My immediate use case is having a complete solution for use in Zotero
> and OpenDocument/OpenOffice. Both of those need to cover the full
> range.
>
> The question here is ultimately a social question more than a
> technical
> one, so am happy to hear what others have to say about it.
Exactly. There's really no qualms with having the terms for use in
Zotero and ODF, it's just a semantic matter for OTHER uses that may
not need the full range (and for that matter, it may also bring
others into the fold by making the matter less confusing. A primer
for the base, then look at the extensions as needed. Zotero and ODF
can require larger sets of terminology extensions, but maybe not the
'cites/citedBy' extension. Citation sites may focus more on science
citations or humanities citations and USE the 'cites/citedBy'
extension. Libraries may not use some of the periodical details...
Well hopefully, but I'm not certain there's anything in BibTeX that
requires this, and that's a theoretical problem. :-)
>> I'm not so concerned about trying to map data INTO BibTeX, as much as
>> retaining all information from BibTeX so that it can be translated
>> losslessly, rather than making sure that EVERYTHING in bibo can be
>> translated losslessly.
>>
>> So I guess I'm hoping for an inverse mapping from bibo to BibTeX such
>> that the MAXIMUM amount of data is conserved.
>
> But how do you reconcile that with the same desire for other formats?
> I'm my field, RIS (or Endnote) is far more common legacy exchange
> format
> than BibTeX, and it has some pretty funky types that don't make much
> sense in the context of a new ontology. Does that mean we should
> create
> classes for every one of them just to preserve lossless mapping of
> types?
Perhaps (back to the above topic), extensions for non-general types
(e.g. JournalArticle/ProceedingsArticle) that subclass the more
general types and may give implications via OWL (e.g. subclass
bibo:Article and add a restriction that implies ":somearticle
dcterms:isPartOf [ a bibo:Proceedings ];")
> I don't have a big problem with JournalArticle, for example, but I do
> have a problem if we have to invent full subclasses for every possible
> relation out there.
That ought to be left to interested parties in their extensions of
the core vocab. We don't need to make complete interoperability, but
we should have the core vocab from which complete interoperability
can be constructed (but no more than necessary).
>> I'm wondering if it's possible to craft a SPARQL query on an RDF
>> dataset using the bibo vocabulary for these more difficult queries
>> (assuming that we follow the standard range/domain)
>
> I'm not much of an expert on SPARQL, so hopefully someone else can
> help
> with this. Will say this was originally recommended to me as likely be
> the solution most suitable to SPARQL querying (as opposed to using
> rdf:Seq or rdf:List).
That's what I figured after reading up a bit on it. rdf:Seq suffers
from too many terms and no SPARQL abstractions (so we can ask 'where
something is the 6th', but not 'where something is before something
else'). rdf:List has SPARQL abstractions (and since it has a limited
set of terms) and we can ask something like 'where something is 3
before something-else', but not so much exact positions, or, again,
'where something is before something else').
Ian
David Wilson
A way of dealing with this issue would be to produce recommended mappings
between BibTeX and this ontology, rather than leaving it to implementers to
come up with divergent mappings. It would be sensible to do this for RIS,
Refer, MARC, and the OOXML format as well for the same reason.
Doing this would also help to give potential implementers some confidence that
the ontology 'works' and that we are not leaving all the problems of
conversion for them to deal with.
david
On Sun, 23 Sep 2007, Pipian wrote:
> >> 5. A one-to-one mapping between BibTeX and this ontology is
> >> difficult. In particular, the semantics of each BibTeX type implies,
> >> usually, a bibo:Article, with some implication as to the type of the
> >> object of its dcterms:partOf statement. This introduces some
> >> ambiguity to translations.
> >
> > It is not a design goal to support 1-1 mapping to BibTeX at the
> > expense
> > of support for other formats (RIS, Refer, MARC, the new OOXML format,
> > etc.), or general clarity.
> >
> > I suppose you're saying you'd prefer to have subclasses like
> > JournalArticle and MagazineArticle rather than to have to look at the
> > related container class?
> >
> > I don't have a strong opinion on this, though have at until now
> > preferred not to do that. I could probably be convinced otherwise.
>
> There's certainly a benefit to doing so. I don't necessarily think
> that we can map back to BibTeX losslessly in every case, but I think
> that a mechanism should be built in so that we don't actually lose
> data when we go BibTeX -> bibo -> BibTeX. (Which is quite possible
> if, say, we don't actually specify any data in a dcterms:isPartOf
> property.)
>
> In this case, we'll almost certainly need to have some sort of bnode
> only with its rdf:type specified in order to definitively determine
> this... Something like?
>
> :somearticle a bibo:Article;
>
> dcterms:isPartOf [ a bibo:Proceedings ];
>
> for @inproceedings, if no other information about the proceedings is
> provided...
>
> I'm not so concerned about trying to map data INTO BibTeX, as much as
> retaining all information from BibTeX so that it can be translated
> losslessly, rather than making sure that EVERYTHING in bibo can be
> translated losslessly.
>
> So I guess I'm hoping for an inverse mapping from bibo to BibTeX such
> that the MAXIMUM amount of data is conserved.
--
-------------------
David N. Wilson
Co-Project Lead for the Bibliographic
OpenOffice.org Project
http://bibliographic.openoffice.org
-------------------------------------------------------
Bruce D'Arcus
...
> Exactly. There's really no qualms with having the terms for use in
> Zotero and ODF, it's just a semantic matter for OTHER uses that may
> not need the full range (and for that matter, it may also bring
> others into the fold by making the matter less confusing. A primer
> for the base, then look at the extensions as needed. Zotero and ODF
> can require larger sets of terminology extensions, but maybe not the
> 'cites/citedBy' extension. Citation sites may focus more on science
> citations or humanities citations and USE the 'cites/citedBy'
> extension. Libraries may not use some of the periodical details...
So I wonder: is this just a question of documentation for you, or must
the core be in its own namespace apart from the others?
I blogged about related issues awhile ago, complete with nice diagram.
<http://netapps.muohio.edu/blogs/darcusb/darcusb/archives/2006/09/26/reference-types>
...
> Perhaps (back to the above topic), extensions for non-general types
> (e.g. JournalArticle/ProceedingsArticle) that subclass the more
> general types and may give implications via OWL (e.g. subclass
> bibo:Article and add a restriction that implies ":somearticle
> dcterms:isPartOf [ a bibo:Proceedings ];")
This it a road I really don't want to go down. You're basically
wanting to flatten the type modeling to correspond to old key-value
formats. If we go this way, we end with an explosion of types. Off the
top of my head, I could easily see:
NewsletterArticle
EnclopediaArticle
WeblogArticle
WikiArticle
That strikes me as a bad idea. They're all articles.
> > I don't have a big problem with JournalArticle, for example, but I do
> > have a problem if we have to invent full subclasses for every possible
> > relation out there.
>
> That ought to be left to interested parties in their extensions of
> the core vocab. We don't need to make complete interoperability, but
> we should have the core vocab from which complete interoperability
> can be constructed (but no more than necessary).
This starts to sound like hand-waving. :-)
Who are the "interested parties" if not people on this list?
I'm the co-project lead for the OpenOffice bibliographic project, and
was majorly involved in the effort to bring RDF to OpenDocument. I
want to use this work directly in that context. So my concerns are
both practical and immediate. As far as I'm concerned, if this
ontology (whether monolithic or core + extension) cannot represent my
data, we have failed.
I suggest we make sure in any case that the ontology is sound such
that we *could* easily split off a core. I'd say the very top-level of
the ontology and perhaps the first level subclasses might well qualify
(and we need to add something like bibo:Recording).
Bruce
Pipian
On Sep 23, 2007, at 11:09 AM, Bruce D'Arcus wrote:
>
> On 9/22/07, Pipian <pip...@pipian.com> wrote:
>
> ...
>
>> Exactly. There's really no qualms with having the terms for use in
>> Zotero and ODF, it's just a semantic matter for OTHER uses that may
>> not need the full range (and for that matter, it may also bring
>> others into the fold by making the matter less confusing. A primer
>> for the base, then look at the extensions as needed. Zotero and ODF
>> can require larger sets of terminology extensions, but maybe not the
>> 'cites/citedBy' extension. Citation sites may focus more on science
>> citations or humanities citations and USE the 'cites/citedBy'
>> extension. Libraries may not use some of the periodical details...
>
> So I wonder: is this just a question of documentation for you, or must
> the core be in its own namespace apart from the others?
>
> I blogged about related issues awhile ago, complete with nice diagram.
>
> <http://netapps.muohio.edu/blogs/darcusb/darcusb/archives/
> 2006/09/26/reference-types>
I think it's more documentation than it is actual namespacing. I
can't think, offhand, any reasons why they couldn't be in the same
namespace (at least the first two 'levels'). I think, however, that
the specificity of the third level should probably be in separate
field-oriented namespaces, so as to allow the bottom two levels to
become stable more quickly (because there will always be work on the
details and deeper levels).
>> Perhaps (back to the above topic), extensions for non-general types
>> (e.g. JournalArticle/ProceedingsArticle) that subclass the more
>> general types and may give implications via OWL (e.g. subclass
>> bibo:Article and add a restriction that implies ":somearticle
>> dcterms:isPartOf [ a bibo:Proceedings ];")
>
> This it a road I really don't want to go down. You're basically
> wanting to flatten the type modeling to correspond to old key-value
> formats. If we go this way, we end with an explosion of types. Off the
> top of my head, I could easily see:
>
> NewsletterArticle
> EnclopediaArticle
> WeblogArticle
> WikiArticle
>
> That strikes me as a bad idea. They're all articles.
Very true, but with OWL inferencing added on through an extension
vocab, the model used in the data store becomes irrelevant, as it can
written one way, and interpreted the other, provided that you have a
good inferencer. All I'm saying is that it would be possible to do
this either way, not that it would be necessary to flatten the data
model.
>>> I don't have a big problem with JournalArticle, for example, but
>>> I do
>>> have a problem if we have to invent full subclasses for every
>>> possible
>>> relation out there.
>>
>> That ought to be left to interested parties in their extensions of
>> the core vocab. We don't need to make complete interoperability, but
>> we should have the core vocab from which complete interoperability
>> can be constructed (but no more than necessary).
>
> This starts to sound like hand-waving. :-)
>
> Who are the "interested parties" if not people on this list?
Well, I'm imagining that interested parties would be on this list,
but everyone on this list has their own goals for the vocabulary on
top of the goals in common (e.g. you want it as a client-side core
for OpenDocument, Frederick wants it for client-side on Zotero (I
believe), I'm playing around with server-side for my applications)
and those disparate goals should, I believe, be spun off into
extension vocabularies rather than put into the bibo vocab at large,
to allow stability of the vocabulary to come sooner rather than later.
> I'm the co-project lead for the OpenOffice bibliographic project, and
> was majorly involved in the effort to bring RDF to OpenDocument. I
> want to use this work directly in that context. So my concerns are
> both practical and immediate. As far as I'm concerned, if this
> ontology (whether monolithic or core + extension) cannot represent my
> data, we have failed.
>
> I suggest we make sure in any case that the ontology is sound such
> that we *could* easily split off a core. I'd say the very top-level of
> the ontology and perhaps the first level subclasses might well qualify
> (and we need to add something like bibo:Recording).
I absolutely agree, and there's already a pretty solid core (though
obviously, things are still a bit in flux on it as bibo:Recording's
status shows). If we encounter heated arguments on the semantics and
structure of something, however, I suspect it might not necessarily
be something to be in the 'core', and might be best set aside for a
bit to make sure that the top levels can be solidified.
Ian
Bruce D'Arcus
concrete so we can see how all the pieces would fall together.
I think we agree on the basic approach of having a solid general
ontology, with finer details (in particular classes) added as needed.
Indeed, that's what we have now, except a) the documentation doesn't
allow one to easily see this, and b) the more specific classes and
such are a bit unstable. b reinforces a, as we haven't released a
formal draft yet as we get more comfortable stabilizing the remaining
pieces.
To add a complicating factor to this that illustrates the real world
problems I'm grappling with, consider that I am also in charge of a
project for a citation style language (CSL). It's an XML language to
represent citation styles, and includes within it its own model of
sorts that is influenced by this work, but different. The Zotero
project uses it for their citation formatting.
So take a case like Zotero. They have a list of 30 or so types that
they present to their users, and store in their database. CSL has its
own list of 30 or types that share a fair bit of overlap, but also
have some differences. This ontology has still another -- really more
general I think -- logic.
So the Zotero devs have to map between three different type models.
See, for example:
To top it off, they are actually interested in users being able to
create custom types (!). [also, they're planing to move to a more
relational model that is close to this ontology]
So in the face of all this, plus the reality of different projects
with different foci, how do we keep this all together? How do we do it
technically, and how do we do it in social or infrastructure terms?
I could see one possible solution:
1. define the clear/tight core; Document, Book, Article, Periodical, etc.
2. split off the rest into an extended section, which can in turn
provide hooks for further extension
3. fill out the subclasses to include the flattened types we see in
CSL, Zotero, and what you are looking for
4. switch the type list for both Zotero and CSL to using the union of
1-3, os that there is no mapping really.
5. create a social infrastructure that encourages extension of 3.
The primary downside of this approach would be that the extension
ontology would likely get very long and potentially incoherent
(because different people use different criteria to do typing). And
when type lists get like this, it gets confusing for users too. Also,
and related, there'd be some transition pains for CSL styles and -- in
particular -- Zotero users (though they'd find similar in switching
the new more hierarchical model anyone, so better to do at once).
The primary advantage, of course, is there'd be less need for
potentially lossy mapping between data representation, GUIs, and
output formats.
I'm not sure this is a good idea, but it might be worth considering. I
wouldn't want to do this without people (particularly the Zotero guys)
stepping up and committing to it though.
Bruce
Pipian
On Sep 23, 2007, at 2:36 PM, Bruce D'Arcus wrote:
>
> This is all sensible, but I think we need to start making this
> concrete so we can see how all the pieces would fall together.
>
> I think we agree on the basic approach of having a solid general
> ontology, with finer details (in particular classes) added as needed.
> Indeed, that's what we have now, except a) the documentation doesn't
> allow one to easily see this, and b) the more specific classes and
> such are a bit unstable. b reinforces a, as we haven't released a
> formal draft yet as we get more comfortable stabilizing the remaining
> pieces.
Exactly. There's really nothing preventing us from putting out some
firm documentation regarding the general ontology at this point, but
the focus on the more specific classes as of right now is perhaps
distracting from that goal. Perhaps if one of us (e.g. myself or
such) worked on the general documentation, we'd be a bit further
along with the goal (for my projects, the *details* of the ontology
are irrelevant, and the core data model is of a greater concern.
Details can always be mapped to better properties later on.)
> To add a complicating factor to this that illustrates the real world
> problems I'm grappling with, consider that I am also in charge of a
> project for a citation style language (CSL). It's an XML language to
> represent citation styles, and includes within it its own model of
> sorts that is influenced by this work, but different. The Zotero
> project uses it for their citation formatting.
>
> So take a case like Zotero. They have a list of 30 or so types that
> they present to their users, and store in their database. CSL has its
> own list of 30 or types that share a fair bit of overlap, but also
> have some differences. This ontology has still another -- really more
> general I think -- logic.
And, I imagine, the goal of this ontology is, in the long run, to
separate style from content in these cases, with this ontology having
the content, and whatever other interpreter (CSL/BibTeX/Zotero)
handling the 'styling.' Since RDF can be serialized many ways, it's
really an ideal 'intermediate' format that is independent of style
and serialization.
> So the Zotero devs have to map between three different type models.
> See, for example:
>
> <http://sourceforge.net/mailarchive/forum.php?
> thread_name=348CC73C-4238-4BA2-B75E-59856848405F%
> 40simonster.com&forum_name=xbiblio-devel>
>
> To top it off, they are actually interested in users being able to
> create custom types (!). [also, they're planing to move to a more
> relational model that is close to this ontology]
Well, styling them would be outside the scope of this project I
imagine, but the flexibility that RDF provides in extending classes
is really (from what I can tell) what the project needs. Of course,
some arbitrary XML format could too, but this format would,
hopefully, be more interoperable and offer some advantages that a
simple XML data structure format (sans-style) would create.
> So in the face of all this, plus the reality of different projects
> with different foci, how do we keep this all together? How do we do it
> technically, and how do we do it in social or infrastructure terms?
>
> I could see one possible solution:
>
> 1. define the clear/tight core; Document, Book, Article,
> Periodical, etc.
More or less complete as it is, though there's still a little bit of
formalization (bibo:Recording, etc.) left to it...
> 2. split off the rest into an extended section, which can in turn
> provide hooks for further extension
Right. This is what some (but not all) of the focus currently seems
to be on (from my guess)
> 3. fill out the subclasses to include the flattened types we see in
> CSL, Zotero, and what you are looking for
These would be project-specific in many ways (since it has a lot to
do with 'style' over content) and, hopefully, outside the immediate
scope of the ontology 'workgroup' thus far.
> 4. switch the type list for both Zotero and CSL to using the union of
> 1-3, os that there is no mapping really.
i.e. Enable both to use the ontology as the content and customize the
styling as necessary.
> 5. create a social infrastructure that encourages extension of 3.
Really, this can happen as soon as we get to stage 3, because I see
stage 3 as already being 'application-specific' (whereas, I gather
that you don't quite see it that way).
> The primary downside of this approach would be that the extension
> ontology would likely get very long and potentially incoherent
> (because different people use different criteria to do typing).
Really, I foresee many different extensions. Not so much one
'extension-level-3' document as many (see above where I mention that
I see level 3 being 'application-specific'). While some confusion
and different architectures might appear, this isn't much different
from how the fringes of FOAF extensions work right now. Eventually,
if enough people need interoperability, they'll handle standardizing
their level-3 extensions among themselves, but level 3 is, I believe,
outside the immediate scope of this ontology (though there's nothing
wrong with encouraging and directing people to extensions that seem
particularly well designed, and so on.)
> And
> when type lists get like this, it gets confusing for users too. Also,
> and related, there'd be some transition pains for CSL styles and -- in
> particular -- Zotero users (though they'd find similar in switching
> the new more hierarchical model anyone, so better to do at once).
Not if they handle graceful degradation and simply deprecate (rather
than remove) support for existing formats. If they have the flat-
mapping extensions, it should be lossless in converting from current
styles, and the current users should expect no change, while power
users would get the extensibility they need (I imagine.) This seems
very much like an application-specific issue.
> The primary advantage, of course, is there'd be less need for
> potentially lossy mapping between data representation, GUIs, and
> output formats.
Exactly. The core data model in RDF would then be interchangeable
independent of the program using it, which is a good goal.
> I'm not sure this is a good idea, but it might be worth considering. I
> wouldn't want to do this without people (particularly the Zotero guys)
> stepping up and committing to it though.
I think separating style from content is a primary goal of this
ontology. After all, if it's user-task oriented along the 'find',
'identify', 'select', and 'obtain' tasks, style is going to differ
greatly from task to task.
'Find' tends to be independent from style. It's about the data, not
the way it's presented. 'Identify' is all about style. There are
different citation formats (Chicago, MLA, etc.) and while each one
presents the same data, they're all formatted differently. 'Select'
may have limited styling content because of the human interaction
related to selection. 'Obtain' may also have some limited styling
(after all, libraries need to pretty print their 'availability' pages).
It's best to unify the disparate storage mechanisms, and separate
ourselves from thinking of this vocabulary in terms of how it looks
on the printed page (something that BibTeX does not do, and thus
leading to its extremely flat structure) and instead view these as
describing books, etc. themselves, not the citations... Though I'm
certain we agree on this much already. :)
All this is is a data model to be used for any number of purposes (I
read this bibo:Book. This paper cites that bibo:Article. The
library has this bibo:Recording available. This bibo:Periodical has
bibo:Articles with similar topics as that bibo:Book.) and how its
used is up to the application developer and (I believe) outside the
scope of this group. :)
Ian
Frederick Giasson
> A way of dealing with this issue would be to produce recommended mappings
> between BibTeX and this ontology, rather than leaving it to implementers to
> come up with divergent mappings. It would be sensible to do this for RIS,
> Refer, MARC, and the OOXML format as well for the same reason.
>
> Doing this would also help to give potential implementers some confidence that
> the ontology 'works' and that we are not leaving all the problems of
> conversion for them to deal with.
>
Totally agree with David here. Think it would be the way to go. Since we
don't have (and probably won't have) a one-to-one mapping with these
legacy formats.
This is exactly why at the beginning I said that The Bibliographic
Ontology would also be a "best practice guides" for describing
bibliographic things on the semantic web.
Take care,
Fred
Alan Ruttenberg
ontology.
Let me see if I've got the claims
1) It's easier to map to a vocabulary with fewer terms.
2) It's easier to come to agreement about a vocabulary with fewer
terms.
3) One encourages "extension" of the vocabulary if it is small
4) Smaller core vocabulary can be used for more use cases
5) Allowing for details in the ontology requires those details to be
supplied
I don't think I buy it in general, though 2) has some truth in my
experience. It's uncertain whether it will be an issue in this case.
Let me take the claims one at a time:
1) It's easier to map to a vocabulary with fewer terms.
If the source vocabulary is smaller than the target, then one maps to
only the appropriate target term for each source term. This seems
unproblematic.
2) It's easier to come to agreement about a vocabulary with fewer
terms.
I agree. But how do we balance this against other requirements, like
scope, likelyhood of correct usage, etc.
3) One encourages "extension" of the vocabulary if it is small
Two parts to this. First, on ontologies that are really large, like
the NCI thesaurus, current technology does in deed make it unwieldy to
extend them. However this ontology won't be very big by any standard,
and in any case the advance of tools and technologies such as
automatic ontology segmentation will probably make these issues go
away in a few years.
Second, what kinds of extension do we want to encourage? If each
extensions tend to overlap because the core is small, we actually hurt
interoperability because we now different ways that the same thing can
be said (the overlaps).
4) Smaller core vocabulary can be used for more use cases
I don't see how the additional terms prevent use in any use cases.
5) Allowing for details in the ontology requires those details to be
supplied
The semantic web languages are open world. Any detail can be omitted,
in which case it is understood to be unknown. So there is no
requirement that unknown details be filled out.
I'm quite interested to here if I've misunderstood, or if you have
some examples that would elucidate what the issues are.
Regards,
Alan
Alan Ruttenberg
I haven't seen a case yet where pushing this task onto the consumer of
the ontology has worked.
-Alan
Frederick Giasson
> 1. define the clear/tight core; Document, Book, Article, Periodical, etc.
> 2. split off the rest into an extended section, which can in turn
> provide hooks for further extension
> 3. fill out the subclasses to include the flattened types we see in
> CSL, Zotero, and what you are looking for
> 4. switch the type list for both Zotero and CSL to using the union of
> 1-3, os that there is no mapping really.
> 5. create a social infrastructure that encourages extension of 3.
>
>
This is a good plan, but I would take care, are you said bellow. First,
I think we currently have the core ontology with current documents
classes. The only exception, as I already said, is to remove all things
related to law documents (make it in its own namespace, etc).
Otherwise, in this "core" ontology we already have 3 namespaces: the
core, status and types.
I would suggest to kind of "crystalize" the current work we have; we
talking at lenght about all this stuff and I think we resolved most of
the issues after about 700 mails.
Then from this core, we have to produce the documentation and usecase
examples (best practice guide). The examples are random examples such as
the one I have in my foaf, or the ones like the one I created for the
Open Library. Other would be to explain how to map legacy formats using
bibo.
Then we will have a good basis to extend with new types, news extensions
for specialized domains, etc.
I think we have all the anchor points to express nearly (if not all) the
domain.
Take care,
Fred
Frederick Giasson
> Exactly. There's really nothing preventing us from putting out some
> firm documentation regarding the general ontology at this point, but
> the focus on the more specific classes as of right now is perhaps
> distracting from that goal. Perhaps if one of us (e.g. myself or
> such) worked on the general documentation, we'd be a bit further
> along with the goal (for my projects, the *details* of the ontology
> are irrelevant, and the core data model is of a greater concern.
> Details can always be mapped to better properties later on.)
>
>
>
> More or less complete as it is, though there's still a little bit of
> formalization (bibo:Recording, etc.) left to it...
>
>
As I previously said, not sure we need to consider this for now. Let us
concentrate on the current task: bibliography, so documents. Then we
will check if we include records and such.
BTW, did you take a look at musicontology.com; check mo:Record :)
>> 3. fill out the subclasses to include the flattened types we see in
>> CSL, Zotero, and what you are looking for
>>
>
> These would be project-specific in many ways (since it has a lot to
> do with 'style' over content) and, hopefully, outside the immediate
> scope of the ontology 'workgroup' thus far.
>
>
Agree
> I think separating style from content is a primary goal of this
> ontology. After all, if it's user-task oriented along the 'find',
> 'identify', 'select', and 'obtain' tasks, style is going to differ
> greatly from task to task.
>
> 'Find' tends to be independent from style. It's about the data, not
> the way it's presented. 'Identify' is all about style. There are
> different citation formats (Chicago, MLA, etc.) and while each one
> presents the same data, they're all formatted differently. 'Select'
> may have limited styling content because of the human interaction
> related to selection. 'Obtain' may also have some limited styling
> (after all, libraries need to pretty print their 'availability' pages).
>
> It's best to unify the disparate storage mechanisms, and separate
> ourselves from thinking of this vocabulary in terms of how it looks
> on the printed page (something that BibTeX does not do, and thus
> leading to its extremely flat structure) and instead view these as
> describing books, etc. themselves, not the citations... Though I'm
> certain we agree on this much already. :)
>
> All this is is a data model to be used for any number of purposes (I
> read this bibo:Book. This paper cites that bibo:Article. The
> library has this bibo:Recording available. This bibo:Periodical has
> bibo:Articles with similar topics as that bibo:Book.) and how its
> used is up to the application developer and (I believe) outside the
> scope of this group. :)
>
>
I am not that sure. Why do we suggest to re-use foaf, dcterms, etc?
Because bibo is a best practice guide to describe bibliographic things.
So, should this group suggest how to use the ontology and related
ontologies? I think so; at least it is how I started this group months
ago; it is what I had in mind. It is sure that people can do what they
want; but people need some guidelines too.
Take care,
Fred
> Ian
>
>
> >
>
Frederick Giasson
Totally agree with what you said bellow.
Take care,
Fred
Bruce D'Arcus
...
> I would suggest to kind of "crystalize" the current work we have; we
> talking at lenght about all this stuff and I think we resolved most of
> the issues after about 700 mails.
>
> Then from this core, we have to produce the documentation and usecase
> examples (best practice guide). The examples are random examples such as
> the one I have in my foaf, or the ones like the one I created for the
> Open Library. Other would be to explain how to map legacy formats using
> bibo.
>
> Then we will have a good basis to extend with new types, news extensions
> for specialized domains, etc.
>
> I think we have all the anchor points to express nearly (if not all) the
> domain.
OK, to that end, I've gone through the ontology and tweaked definitions,
and tagged everything in question with the "unstable" status (some have
"experimental" too).
I feel the need to keep emphasizing that bibliographic workflows and
formats DO NOT only cover textual documents. Moreover, documents are not
necessarily just textual. As I said to Ian, as far as I'm concerned, if
this ontology cannot represent my citation data -- all of it -- then
it's not done.
I have changed the definition of Document in the ontology to borrow the
definition from wikipedia to make this clear:
A document (noun) is a bounded physical representation of body of
information designed with the capacity (and usually intent) to
communicate. A document may manifest symbolic, diagrammatic or
sensory-representational information.
I have also added AudioDocument and AudioVisualDocument subclasses.
So I think to release the first draft we at least need to be able to
stabilize all of the properties. Classes that we cannot move to stable,
then, definitely need testing and further scrutiny. If in that process
we don't feel comfortable calling a class stable, then I guess it has to
wait.
I suggest we shoot for a complete first draft (with examples, clear
document, and hopefully BibTeX mapping) end-of-October.
Finally, I do not want to move the legal stuff to another namespace. The
sole exception might be classes like Brief and Dissent (not there yet,
but should be). In any case, I don't want to worry about that now. We
need that stuff to support RIS and Endnote.
Bruce
Frederick Giasson
> OK, to that end, I've gone through the ontology and tweaked definitions,
> and tagged everything in question with the "unstable" status (some have
> "experimental" too).
>
>
> I feel the need to keep emphasizing that bibliographic workflows and
> formats DO NOT only cover textual documents. Moreover, documents are not
> necessarily just textual. As I said to Ian, as far as I'm concerned, if
> this ontology cannot represent my citation data -- all of it -- then
> it's not done.
>
>
Well, when I read dictionary definitions, I mostly read: writing of
information. So it is why I alway say: it really depends on the
definition of a Document, and we should change the definition of a
document if needed.
Also, we should be consistent with other ontologies too (foaf:Document,
etc).
> I have changed the definition of Document in the ontology to borrow the
> definition from wikipedia to make this clear:
>
> A document (noun) is a bounded physical representation of body of
> information designed with the capacity (and usually intent) to
> communicate. A document may manifest symbolic, diagrammatic or
> sensory-representational information.
>
This is what I was meaning by changing the definition :)
I like this one!
> I have also added AudioDocument and AudioVisualDocument subclasses.
>
>
Good. Considering the definition above, I agree with them. They will
gives the anchor points within the core ontology to extend them further
later.
> So I think to release the first draft we at least need to be able to
> stabilize all of the properties. Classes that we cannot move to stable,
> then, definitely need testing and further scrutiny. If in that process
> we don't feel comfortable calling a class stable, then I guess it has to
> wait.
>
Exact
> I suggest we shoot for a complete first draft (with examples, clear
> document, and hopefully BibTeX mapping) end-of-October.
>
>
Good for me.
I have been really busy in September with development work at Zitgist. I
should hav emore time for BIBO in october, so we are working toward that
date.
> Finally, I do not want to move the legal stuff to another namespace. The
> sole exception might be classes like Brief and Dissent (not there yet,
> but should be). In any case, I don't want to worry about that now. We
> need that stuff to support RIS and Endnote.
>
>
Okay
Take care,
Fred
> B