SCHOOL (important for listing the school a thesis was written at)
HOWPUBLISHED (can't quite squeeze this into a dcterms:publisher)
NOTE (I think there's a mechanism for this, but I'm not sure)
KEY (May just shove this into a BibTeX extension vocab)
ADDRESS (particularly problematic for booklets, which lack a
publisher, Otherwise, I was thinking something along the lines of:
:whatever dcterms:publisher :publisher .
:publisher a foaf:Agent ;
foaf:isBasedNear [ a spacenamespace:Space ;
spacenamespace:name "BibTeX-Address" ] .
Perhaps with some sort of attempt at parsing out an address to get
more semantic information out (e.g. City, Province, country)
ORGANIZATION (I'm thinking bibo:organizer(?))
INSTITUTION (Used with tech reports. bibo:producer?)
CHAPTER (this is why we need bibo:chapter)
TYPE (used with tech report.)
I'm also not sure if I like how InBook/InCollection would have to be
mapped right now (to bibo:Article, when something like a bibo:Chapter
would be more appropriate)
Ian
P.S. Sorry for the disorganized nature of the content here. I'm
just writing out stuff as I generate it.
Pipian wrote:
> I'm starting to map BibTeX to the ontology (the same mapping will in
> theory be used to reverse from the ontology back to BibTeX) but there
> are a few fields of BibTeX that I'm trying to figure out how they'll
> map, namely:
>
> SCHOOL (important for listing the school a thesis was written at)
We talked about this here before on the list. Honestly, I don't recall
what became of that. There are a lot of different ways to model things
like dissertations:
1) flat, a la BibTeX:
<http://ex.net/1> a bibo:Dissertation ;
bibo:school "Harvard" ;
bibo:degree "PhD" .
2) treat degree and institutions as resources:
<http://ex.net/1> a bibo:Dissertation ;
bibo:degree <http://ex.net/2> .
<http://ex.net/2> a edu:PhDDegree ;
bibo:awardingInstitution <http://ex.net/3> .
<http://ex.net/3> a foaf:Organization ;
foaf:name "Harvard" .
etc.
> HOWPUBLISHED (can't quite squeeze this into a dcterms:publisher)
No, we don't really have anything for that. Would be nice to see some
examples of actual data for this field.
> NOTE (I think there's a mechanism for this, but I'm not sure)
Another "thing we've discussed but not resolved."
> KEY (May just shove this into a BibTeX extension vocab)
Yes, I don't want this here, because it's really a user tag. It does not
really belong as a property of the resource per se.
> ADDRESS (particularly problematic for booklets, which lack a
> publisher, Otherwise, I was thinking something along the lines of:
>
> :whatever dcterms:publisher :publisher .
> :publisher a foaf:Agent ;
> foaf:isBasedNear [ a spacenamespace:Space ;
> spacenamespace:name "BibTeX-Address" ] .
We have the locality property for this. Another one of those details I'm
not entirely sure about/comfortable with.
> Perhaps with some sort of attempt at parsing out an address to get
> more semantic information out (e.g. City, Province, country)
>
> ORGANIZATION (I'm thinking bibo:organizer(?))
The organizer property is to link associated agents to an event. A
conference, for example, has an organizer.
<http://ex.net/1> a bibo:Paper ;
bibo:presentedAt <http://ex.net/2> .
<http://ex.net/2> a bibo:Conference ;
bibo:organizer <http://ex.net/3> .
<http://ex.net/3> a foaf:Organization ;
foaf:name "ABC Corp." .
> INSTITUTION (Used with tech reports. bibo:producer?)
Yeah, probably.
> CHAPTER (this is why we need bibo:chapter)
Huh? I don't think chapter in bibtex is used as Fred intended
bibo:chapter to be used. The former is the chapter *title*; isn't it?
The bibo:chapter property would be the chapter number.
> TYPE (used with tech report.)
Another TBD issue. We did talk about the need for a literal to describe
types (of letters, reports, etc.). But he hadn't resolved how. It seems
a little silly to call it "type."
> I'm also not sure if I like how InBook/InCollection would have to be
> mapped right now (to bibo:Article, when something like a bibo:Chapter
> would be more appropriate)
You know, I could have sworn we had a bibo:Chapter (or BookSection)
class! Don't know what happened to that. We need to fix that.
Bruce
I think the latter is a bit more accurate to the concepts, so it
might be better to go at it that way (and in the process, remove the
individuals of the degrees).
>> HOWPUBLISHED (can't quite squeeze this into a dcterms:publisher)
>
> No, we don't really have anything for that. Would be nice to see some
> examples of actual data for this field.
I haven't seen any either. If I find some I'll give an example.
>> NOTE (I think there's a mechanism for this, but I'm not sure)
>
> Another "thing we've discussed but not resolved."
I figured as much. (rdfs:comment?)
>> KEY (May just shove this into a BibTeX extension vocab)
>
> Yes, I don't want this here, because it's really a user tag. It
> does not
> really belong as a property of the resource per se.
You're most likely correct, but on the other hand, having a sort-by
tag (since that's essentially what it is) might be beneficial.
>> ADDRESS (particularly problematic for booklets, which lack a
>> publisher, Otherwise, I was thinking something along the lines of:
>>
>> :whatever dcterms:publisher :publisher .
>> :publisher a foaf:Agent ;
>> foaf:isBasedNear [ a spacenamespace:Space ;
>> spacenamespace:name "BibTeX-Address" ] .
>
> We have the locality property for this. Another one of those
> details I'm
> not entirely sure about/comfortable with.
That could be a use of it. I wasn't sure about how that property was
being used so...
>> ORGANIZATION (I'm thinking bibo:organizer(?))
>
> The organizer property is to link associated agents to an event. A
> conference, for example, has an organizer.
>
> <http://ex.net/1> a bibo:Paper ;
> bibo:presentedAt <http://ex.net/2> .
>
> <http://ex.net/2> a bibo:Conference ;
> bibo:organizer <http://ex.net/3> .
>
> <http://ex.net/3> a foaf:Organization ;
> foaf:name "ABC Corp." .
That's tricky then, because PROCEEDINGS doesn't actually have a link
to the actual conference, so the conference itself would have to be
(virtually) a bnode. Doable, but not as helpful as it could be. :)
>> INSTITUTION (Used with tech reports. bibo:producer?)
>
> Yeah, probably.
>
>> CHAPTER (this is why we need bibo:chapter)
>
> Huh? I don't think chapter in bibtex is used as Fred intended
> bibo:chapter to be used. The former is the chapter *title*; isn't it?
>
> The bibo:chapter property would be the chapter number.
The BibTeX CHAPTER property is supposed to be the chapter number. If
the chapter is identified by a name, it should probably be
INCOLLECTION instead of INBOOK.
>> TYPE (used with tech report.)
>
> Another TBD issue. We did talk about the need for a literal to
> describe
> types (of letters, reports, etc.). But he hadn't resolved how. It
> seems
> a little silly to call it "type."
It certainly does. I figured this was pretty vague and hadn't been
specified though.
>> I'm also not sure if I like how InBook/InCollection would have to be
>> mapped right now (to bibo:Article, when something like a bibo:Chapter
>> would be more appropriate)
>
> You know, I could have sworn we had a bibo:Chapter (or BookSection)
> class! Don't know what happened to that. We need to fix that.
Sounds good to me.
Ian
>> HOWPUBLISHED (can't quite squeeze this into a dcterms:publisher)
>>
>
> No, we don't really have anything for that. Would be nice to see some
> examples of actual data for this field.
>
>
What is that?
>> NOTE (I think there's a mechanism for this, but I'm not sure)
>>
>
> Another "thing we've discussed but not resolved."
>
>
Well, I thought we did.
Please read this blog post to see how I use Notes:
>> KEY (May just shove this into a BibTeX extension vocab)
>>
>
> Yes, I don't want this here, because it's really a user tag. It does not
> really belong as a property of the resource per se.
>
>
>> ADDRESS (particularly problematic for booklets, which lack a
>> publisher, Otherwise, I was thinking something along the lines of:
>>
>> :whatever dcterms:publisher :publisher .
>> :publisher a foaf:Agent ;
>> foaf:isBasedNear [ a spacenamespace:Space ;
>> spacenamespace:name "BibTeX-Address" ] .
>>
>
> We have the locality property for this. Another one of those details I'm
> not entirely sure about/comfortable with.
>
>
you should describe the place using
wgs84_pos:SpatialThing
then you can plugin a bibo:locality to write the string describing it.
And you have to plug this place description from your resource, to the place's resource using something like bibo:place (event:place) or whatever.
Bruce: we did we choose to delete bibo:place?
>> Perhaps with some sort of attempt at parsing out an address to get
>> more semantic information out (e.g. City, Province, country)
>>
>> ORGANIZATION (I'm thinking bibo:organizer(?))
>>
>
> The organizer property is to link associated agents to an event. A
> conference, for example, has an organizer.
>
> <http://ex.net/1> a bibo:Paper ;
> bibo:presentedAt <http://ex.net/2> .
>
> <http://ex.net/2> a bibo:Conference ;
> bibo:organizer <http://ex.net/3> .
>
> <http://ex.net/3> a foaf:Organization ;
> foaf:name "ABC Corp." .
>
>
>> INSTITUTION (Used with tech reports. bibo:producer?)
>>
>
> Yeah, probably.
>
>
>> CHAPTER (this is why we need bibo:chapter)
>>
>
> Huh? I don't think chapter in bibtex is used as Fred intended
> bibo:chapter to be used. The former is the chapter *title*; isn't it?
>
> The bibo:chapter property would be the chapter number.
>
>
>> TYPE (used with tech report.)
>>
>
> Another TBD issue. We did talk about the need for a literal to describe
> types (of letters, reports, etc.). But he hadn't resolved how. It seems
> a little silly to call it "type."
>
>
>> I'm also not sure if I like how InBook/InCollection would have to be
>> mapped right now (to bibo:Article, when something like a bibo:Chapter
>> would be more appropriate)
>>
Take care,
Fred
>
>>> NOTE (I think there's a mechanism for this, but I'm not sure)
>>>
>> Another "thing we've discussed but not resolved."
>>
>
> I figured as much. (rdfs:comment?)
>
>
No :)
As I said previously, check the blog post.
I reuses Annotea, etc.
Fred
...
>>> CHAPTER (this is why we need bibo:chapter)
>> Huh? I don't think chapter in bibtex is used as Fred intended
>> bibo:chapter to be used. The former is the chapter *title*; isn't it?
>>
>> The bibo:chapter property would be the chapter number.
>
> The BibTeX CHAPTER property is supposed to be the chapter number. If
> the chapter is identified by a name, it should probably be
> INCOLLECTION instead of INBOOK.
Ah, OK. It appears a little vague though:
"A chapter (or section or whatever) number."
I guess in that case, we might consider adding it back.
Bruce
...
>>> HOWPUBLISHED (can't quite squeeze this into a dcterms:publisher)
>>>
>> No, we don't really have anything for that. Would be nice to see some
>> examples of actual data for this field.
>>
>>
> What is that?
See:
<http://artis.imag.fr/~Nicolas.Holzschuch/bibtex.html>
>>> NOTE (I think there's a mechanism for this, but I'm not sure)
>>>
>> Another "thing we've discussed but not resolved."
>
> Well, I thought we did.
>
> Please read this blog post to see how I use Notes:
No, the BibTeX "note" is a simple literal that always gets added to a
citation. Again, see link above.
I'm looking for some really good examples of BiBTeX files that use these
fields. Here's one that at least qualifies as OK:
<http://www.tug.org/pracjourn/2006-4/fenn/ptj-bibtex.bib>
...
> you should describe the place using
>
> wgs84_pos:SpatialThing
We went through this before. I don't want to use that vocabulary
directly. It's hopelessly abstract/ugly. I think I recall preferring to
reuse frbr:Place.
> then you can plugin a bibo:locality to write the string describing it.
>
> And you have to plug this place description from your resource, to the place's resource using something like bibo:place (event:place) or whatever.
>
> Bruce: we did we choose to delete bibo:place?
I don't remember. I've a cold, so life is a little fuzzy now, but ...
I think this part is frankly a mess. We have a variety of different ways
to represent the same thing, each from different vocabularies.
We're dealing with organizations and events, and the places and/or
addresses where they are (respectively) located or held.
So what are the examples we need to handle:
1) theses. Ian's impulse is to use bibo:producer, and describe the
location of the department using FOAF. But I'm not sure a department
quite produces a thesis. It is the institutional body to which one
submits the document for approval, and which in turn grants approval and
the subsequent degree.
It might be that we just need a property like bibo:submittedTo and to
describe the department and school using FOAF.
BTW, Ian, we decided we needed degrees as individuals because there are
quite a diversity of degrees.
2) other unpublished or informally publisher resources where you might
want to include where it came from. I believe Elena gave the example of
a letter. See this post and subsequent discussion:
3) events like conferences and hearings; I'm fine with using the event
properties for this I guess. I'm uncomfortable with the confusion in all
this.
Bruce
Well, you can use the bibo:Note as do within my foaf profile
You can even detect if the note is a URL only, then handling it like any
other web pages related to a document (see examples)
> We went through this before. I don't want to use that vocabulary
> directly. It's hopelessly abstract/ugly. I think I recall preferring to
> reuse frbr:Place.
>
>
yeah, but remember that it is the root :) So from there, you can use
anything else.
>> then you can plugin a bibo:locality to write the string decribing it.
>>
>> And you have to plug this place description from your resource, to the place's resource using something like bibo:place (event:place) or whatever.
>>
>> Bruce: we did we choose to delete bibo:place?
>>
>
> I don't remember. I've a cold, so life is a little fuzzy now, but ...
>
> I think this part is frankly a mess. We have a variety of different ways
> to represent the same thing, each from different vocabularies.
>
>
Yup :)
And it is why we can't do anything against it. What we can do is to
propose something and to add properties if needed.
It is why I suggested to reuse the Event ontology for events
(conferences), etc.
> We're dealing with organizations and events, and the places and/or
> addresses where they are (respectively) located or held.
>
> So what are the examples we need to handle:
>
> 1) theses. Ian's impulse is to use bibo:producer, and describe the
> location of the department using FOAF. But I'm not sure a department
> quite produces a thesis. It is the institutional body to which one
> submits the document for approval, and which in turn grants approval and
> the subsequent degree.
>
> It might be that we just need a property like bibo:submittedTo and to
> describe the department and school using FOAF.
>
> BTW, Ian, we decided we needed degrees as individuals because there are
> quite a diversity of degrees.
>
> 2) other unpublished or informally publisher resources where you might
> want to include where it came from. I believe Elena gave the example of
> a letter. See this post and subsequent discussion:
>
> <http://groups.google.com/group/bibliographic-ontology-specification-group/browse_frm/thread/e245575791704c38/9720d298cc2f9c51?lnk=gst&q=elena+letter+new+york&rnum=1#9720d298cc2f9c51>
>
> 3) events like conferences and hearings; I'm fine with using the event
> properties for this I guess. I'm uncomfortable with the confusion in all
> this.
>
>
Yeah, we should document it properly to make things clearer.
Take care,
Fred