Where do we think we're at?
My sense is we're:
1) comfortable with the contribution stuff and with using DC for a lot
of the other properties
2) unsure about event and org properties
What about the locator properties? Anything else?
Bruce
On this:
> What about the locator properties? Anything else?
You would need locator properties for letters as well (places where
sent/received, linked to a particular author of a particular letter).
I noticed you have nothing for letters here: http://
pingthesemanticweb.com/ontology/bibo/bibliontology.rdfs
Particularly if you're separating documents and events, letter falls
under document, right? (unlike an interview)
Was just wondering if that is coming in future versions.
Thanks,
Elena
> Bruce
>
> >
Bruce D'Arcus wrote:
> I need to try to provide stable mapping from BibTeX to this new ontology
> ASAP for some kind of inclusion in OpenDocument.
Well, let us turn it around: by doing this mapping some issues will pop
up:-) Do you plan some sort of a converter program? We should definitely
test it then on real bib files.
An issue that *might* pop up: I am not sure we cover all the various
publication types that bibtex has. the types/* contains some entries
that Bibtex does not have but I do not see the @inproceedings, @misc,
@unpublished, @inbook, etc. Some of those may be around and can be
expressed with the 'part' trick, but practice will show. Having said
that, adding new types is not a big deal.
Ivan
>
> Where do we think we're at?
>
> My sense is we're:
>
> 1) comfortable with the contribution stuff and with using DC for a lot
> of the other properties
>
> 2) unsure about event and org properties
>
> What about the locator properties? Anything else?
>
> Bruce
>
> >
>
--
Ivan Herman
Bankrashof 108, 1183NW Amstelveen, The Netherlands
tel: +31-641044153;
URL: http://www.ivan-herman.net
> Well, let us turn it around: by doing this mapping some issues will pop
> up:-) Do you plan some sort of a converter program?
I'm not going to write it ;-)
> We should definitely test it then on real bib files.
Sure.
> An issue that *might* pop up: I am not sure we cover all the various
> publication types that bibtex has. the types/* contains some entries
> that Bibtex does not have but I do not see the @inproceedings, @misc,
> @unpublished, @inbook, etc. Some of those may be around and can be
> expressed with the 'part' trick, but practice will show.
Yes, all of those are covered with isPartOf relations and Document.
Bruce
On 7/24/07, Elena Razlogova <elena.r...@gmail.com> wrote:
> > What about the locator properties? Anything else?
>
> You would need locator properties for letters as well (places where
> sent/received, linked to a particular author of a particular letter).
"Places where sent/received"? Really? Also, what do you mean by the last bit?
> I noticed you have nothing for letters here: http://
> pingthesemanticweb.com/ontology/bibo/bibliontology.rdfs
>
> Particularly if you're separating documents and events, letter falls
> under document, right? (unlike an interview)
This brings up an interesting issue. The Zotero guys actually wanted
to treat communication as a separate class. But then this gets
complicated because what do you do with a communication that is also a
document?
> Was just wondering if that is coming in future versions.
Right this second I'm just asking about BiBTeX, which doesn't cover
this sort of stuff. But we definitely need to in our work soon.
Bruce
> I need to try to provide stable mapping from BibTeX to this new ontology
> ASAP for some kind of inclusion in OpenDocument.
>
> Where do we think we're at?
>
> My sense is we're:
>
> 1) comfortable with the contribution stuff and with using DC for a lot
> of the other properties
>
>
Yup
> 2) unsure about event and org properties
>
>
Well, we keep events, but we can introduce a bibo:locality property or
reusing the vcard one for the "string representation" of a locality.
Anyway, events or not, one will always have the possibility to use them.
The question is: do we suggest to use them. Personally I would.
> What about the locator properties? Anything else?
>
>
Its a pending question. Think they have their place.
Also, we will have to redefine:
- bibo:uri as identifier.
Also, Bruce, I took a look at your example modifications.
You will need to add to the ontology these properties that you used in
the examples:
- bibo:department (the domain should probably be bibo:Thesis)
- bibo:physicalLocationDescription (what is the new domain,
rdfs:Resource or bibo:Document? Think it would be always useful to give
the possibility to add it to a wgs84_pos entity)
- bibo:owner (why? is it to make a distinction with dcterms:publisher,
etc? Would need more information about these changes...)
- bibo:place: why that?
- bibo:physicalLocation: where is it now?
Okay Bruce, I would need more information about all these changes
because many things have been changed, and I am really, really not sure
that its the way to go.
particularly about:
- The description of physical places: bibo:place should have a range of
wgs84_pos. Then a dcterms:title (or something similar) would describe
the place. This is really important and would only add one triple. In
fact, if one wants to define lat/long or to reuse geonames or whatever,
it should be able to. With a single string, that is impossible. We have
the possibility to plug things together in a simple way, and we should.
- The web pages: what do we do? I would personally make WebPage subclass
of Article and InternetSite subclass of Periodical. However, is a web
site really a periodical? Don't think so. And is a WebPage an Article?
Not always. So it is possibly why you changed that Bruce? If so, we
should make sure of the description of what is a WebPage and an
InternetSite. In fact, a Web page can be an article, but not always :)
Take care,
Fred
I am curious to see the end result. Do you mean that we may not have a
separate 'type' for, say, conference articles? I am a little bit worried
that if I want to, say, SPARQL search to find conference articles only,
it might be a little bit too convoluted if this is only implicitly
encoded in an isPartOf relationship to something else... But may be I am
wrong. I think making a first converter is indeed the best way of
finding possible problems!
Ivan
...
> Also, Bruce, I took a look at your example modifications.
>
> You will need to add to the ontology these properties that you used in
> the examples:
Oops :-)
> - bibo:department (the domain should probably be bibo:Thesis)
This is one of those I'm still unsure about. I'm wonderig if there's a
more general property we can use for this?
What do people think?
> - bibo:physicalLocationDescription (what is the new domain,
> rdfs:Resource or bibo:Document? Think it would be always useful to give
> the possibility to add it to a wgs84_pos entity)
This is another thing I'm unsure of.
The purpose of the physicalLocation property originally was to
indicate locations in archival collections. In my experience, those
are typically box and folder numbers or names. This is typically how
you find things in old school archives.
But I was uncomfortable with properties like bibo:box and bibo:folder;
hence bibo:physicalLocation.
I don't really like modeling it as a resource because then that's
inconsistent with how other such locators are handled.
> - bibo:owner (why? is it to make a distinction with dcterms:publisher,
> etc? Would need more information about these changes...)
An archive does not publish documents; it owns/stores/holds them.
> - bibo:place: why that?
This is just a place-holder. We need to indicate the address for
archive some way.
> - bibo:physicalLocation: where is it now?
As above; basically gone.
> Okay Bruce, I would need more information about all these changes
> because many things have been changed, and I am really, really not sure
> that its the way to go.
>
> particularly about:
>
> - The description of physical places: bibo:place should have a range of
> wgs84_pos. Then a dcterms:title (or something similar) would describe
> the place. This is really important and would only add one triple. In
> fact, if one wants to define lat/long or to reuse geonames or whatever,
> it should be able to. With a single string, that is impossible. We have
> the possibility to plug things together in a simple way, and we should.
As I said before, I agree this is one major TBD issue. I don't like
calling a place name a title though. Don't worry :-)
> - The web pages: what do we do? I would personally make WebPage subclass
> of Article and InternetSite subclass of Periodical. However, is a web
> site really a periodical? Don't think so. And is a WebPage an Article?
> Not always. So it is possibly why you changed that Bruce? If so, we
> should make sure of the description of what is a WebPage and an
> InternetSite. In fact, a Web page can be an article, but not always :)
I'd be fine with ditching them altogether, particularly WebPage.
But a WebPage is certainly a document; we can't say more than that.
Likewise, some sites (weblogs) have characteristics like periodicals
(what the library people call "seriials") in that they are updated on
a regular basis. But not all are.
But I personally dislike treating web-based resource as somehow special.
Bruce
We could just drop back to the baseline locator property?
bibo:locator "Box 23, Folder 1"
Bruce
On 7/24/07, Frederick Giasson <fr...@fgiasson.com> wrote:
>> - bibo:department (the domain should probably be bibo:Thesis)
>>This is one of those I'm still unsure about. I'm wonderig if there's a
>>more general property we can use for this?
>>What do people think?
Sorry if this repeats the earlier discussion, but maybe bibo:program (as in "Master of Science program at Example University"?) Though, I don't know about modelling things in the range.
Patrick
<http://examples.net/manuscript> a bibo:Manuscript ;
dcterms:title "Manuscript Title"@en ;
dcterms:isPartOf <http://examples.net/collections/1> ;
bibo:locator "Box 12, Folder 3" ;
bibo:contribution [
a bibo:Contribution ;
bibo:role bibo_roles:author ;
bibo:contributor <http://examples.net/contributors/1>
] .
<http://examples.net/collections/1> a bibo:Collection ;
dcterms:title "Manuscript Collection Title"@en ;
bibo:owner <http://examples.net/contributors/5> .
<http://examples.net/places/1> a foaf:Organization ;
foaf:name "XYZ Archive, National University" ;
bibo:adr [ bibo:locality "London" ] .
So use the vcard modeling for addresses (I've kept the bibo namespace
for now, but hope we can change that) and bibo:locator for the box,
etc. stuff.
Is that where we were gong? We then preserve event:place and hope we
can reuse the vcard address properties there too?
Bruce
I guess the problem is that the terminology is so different from one
country to the other in this respect, that anything _very_ specific
becomes misleading... Eg, my PhD was issued by 'Faculty of Mathematics
and Natural Sciences' (of the University of Leiden), in which case
'program' would be meaningless. I just took from my bookshelf two other
PhD-s from different universities and in both of those cases the PhD was
simply given by the University, without mentioning the faculty,
department, or anything else... You can't win...:-(
For a 'thesis', maybe 'school' is the most neutral term.
Ivan
>
> Patrick
> I guess the problem is that the terminology is so different from one
> country to the other in this respect, that anything _very_ specific
> becomes misleading...
True. In my institution we have programs and departments.
> For a 'thesis', maybe 'school' is the most neutral term.
IIRC, BibTeX uses just "organization", which would be fine. I was just
looking for something more verb-like I guess.
Bruce
>
> Elena,
>
> On 7/24/07, Elena Razlogova <elena.r...@gmail.com> wrote:
>
>
>>> What about the locator properties? Anything else?
>>
>> You would need locator properties for letters as well (places where
>> sent/received, linked to a particular author of a particular letter).
>
> "Places where sent/received"? Really? Also, what do you mean by the
> last bit?
example:
John Smith, New York, to Jane Doe, California, telegram, July 24,
1927, box 4, folder 5, John Smith Archive, New York Public Library,
New York.
So there are two addresses, and each needs to be assigned to a
particular contributor.
By the way, for archival location besides box and folder archives
also use "series" and "record group" and many others, so yes,
"locator" is better than "box" & "folder"
>> I noticed you have nothing for letters here: http://
>> pingthesemanticweb.com/ontology/bibo/bibliontology.rdfs
>>
>> Particularly if you're separating documents and events, letter falls
>> under document, right? (unlike an interview)
>
> This brings up an interesting issue. The Zotero guys actually wanted
> to treat communication as a separate class. But then this gets
> complicated because what do you do with a communication that is also a
> document?
Well, you have "transcript" for the interview, which is an event, you
could also add "letter" for communication, which can also be an
event. (I'm not sure about this because I'm not familiar with various
standards discussed on this list).
>> Was just wondering if that is coming in future versions.
>
> Right this second I'm just asking about BiBTeX, which doesn't cover
> this sort of stuff. But we definitely need to in our work soon.
Ok, that's what I thought.
Best,
Elena
> Bruce
>
> >
I guess there is a good reason why bibtex settled on that term:-)
Cheers
ivan
> Bruce
> > "Places where sent/received"? Really? Also, what do you mean by the
> > last bit?
>
> example:
> John Smith, New York, to Jane Doe, California, telegram, July 24,
> 1927, box 4, folder 5, John Smith Archive, New York Public Library,
> New York.
>
> So there are two addresses, and each needs to be assigned to a
> particular contributor.
So I guess contribution is our friend:
bibo:contribution [
a bibo:Contribution ;
bibo:role bibo_roles:recipient ;
bibo:sentFrom [ bibo:locality "New York" ;
bibo:contributor <http://examples.net/contributors/1>
]
Well, something like that; the location as a property of the
contribution (not the contributor, who is mobile!). Might apply too to
interviews I suppose.
Bruce
>IIRC, BibTeX uses just "organization", which would be fine. I was just
>looking for something more verb-like I guess.
I s'pose it makes little different, but for something more verb-like maybe receivedBy or submittedTo?
Patrick
We are making progress here :)
> <http://examples.net/manuscript> a bibo:Manuscript ;
> dcterms:title "Manuscript Title"@en ;
> dcterms:isPartOf <http://examples.net/collections/1> ;
> bibo:locator "Box 12, Folder 3" ;
> bibo:contribution [
> a bibo:Contribution ;
> bibo:role bibo_roles:author ;
> bibo:contributor <http://examples.net/contributors/1>
> ] .
>
> <http://examples.net/collections/1> a bibo:Collection ;
> dcterms:title "Manuscript Collection Title"@en ;
> bibo:owner <http://examples.net/contributors/5> .
>
>
> <http://examples.net/places/1> a foaf:Organization ;
> foaf:name "XYZ Archive, National University" ;
> bibo:adr [ bibo:locality "London" ] .
>
> So use the vcard modeling for addresses (I've kept the bibo namespace
> for now, but hope we can change that) and bibo:locator for the box,
> etc. stuff.
>
Perfect for me (and seems for other). The only thing I would suggest is
to modify the definition of bibo:locator a bit to make sure its clear we
can do that.
> Is that where we were gong? We then preserve event:place and hope we
> can reuse the vcard address properties there too?
>
Yeah sure we preserve event:place since its related to event and there
is no event in that example :)
what is particular with bibo:adr is that it has to be working for
foaf:Organizations and event:Event.
So, by defining it accordingly, we should be ok with it. Possibly
re-using vcard depending on what they choose to do.
that way, in foaf:Organization, we can always re-use the foaf:based_near
property to link to a resource describing that place.
Same for a event:Event but by using event:place instead.
Take care,
Fred
>> I guess the problem is that the terminology is so different from one
>> country to the other in this respect, that anything _very_ specific
>> becomes misleading...
>>
>
> True. In my institution we have programs and departments.
>
>
>> For a 'thesis', maybe 'school' is the most neutral term.
>>
>
> IIRC, BibTeX uses just "organization", which would be fine. I was just
> looking for something more verb-like I guess.
>
so, creating a bibo:organization
domain: bibo:Thesis
range: foaf:Organization
and please write the definition :)
?
Fred
Well, we will have to really write the description of that property :)
However, something weird here. You are creating a bNode only for the
bibo:locality? Its for that exact reason that I wants to put all
relations with a "place" in a
"http://www.w3.org/2003/01/geo/wgs84_pos#SpatialThing"
So, we would have something like:
bibo:contribution [
a bibo:Contribution ;
bibo:role bibo_roles:recipient ;
bibo:sentFrom <http://examples.net/location/1>;
bibo:contributor <http://examples.net/contributors/1>
].
<http://examples.net/location/1> a <http://www.w3.org/2003/01/geo/wgs84_pos#SpatialThing>;
bibo:locality "New York".
# other descriptions of the place
that way you can describe further the number place and you have you string representation of the place via bibo:locality; and the number of triples is the same.
Salutations,
Fred
>> - bibo:owner (why? is it to make a distinction with dcterms:publisher,
>> etc? Would need more information about these changes...)
>>
>
> An archive does not publish documents; it owns/stores/holds them.
>
>
Yup I agree, but the thing, I think, was that we were considering an
owner a contributor in some way (so its why it was a role in a
contribution).
So its why I am asking the question: why creating this property. Is it
to make some separation between the Manifestation and the Items?
>> - The web pages: what do we do? I would personally make WebPage subclass
>> of Article and InternetSite subclass of Periodical. However, is a web
>> site really a periodical? Don't think so. And is a WebPage an Article?
>> Not always. So it is possibly why you changed that Bruce? If so, we
>> should make sure of the description of what is a WebPage and an
>> InternetSite. In fact, a Web page can be an article, but not always :)
>>
>
> I'd be fine with ditching them altogether, particularly WebPage.
>
> But a WebPage is certainly a document; we can't say more than that.
> Likewise, some sites (weblogs) have characteristics like periodicals
> (what the library people call "seriials") in that they are updated on
> a regular basis. But not all are.
>
> But I personally dislike treating web-based resource as somehow special.
>
Agree that in some case, a web page is an article, other time its a
document, other time its a Law, etc. So, web pages is only the medium
used to publish the article.
So, we only have to use the bibo:uri identifier (yet to be integrated
into the owl document) to identify it on the Web.
Is that right?
Salutations,
Fred
> However, something weird here. You are creating a bNode only for the
> bibo:locality? Its for that exact reason that I wants to put all
> relations with a "place" in a
> "http://www.w3.org/2003/01/geo/wgs84_pos#SpatialThing"
First, I really dislike the abstract language of SpatialThing, and I
really want to link into the FRBR ontology. Since it has a Place class
-- and it is a subclass of SpatialThing -- can we use that instead?
<http://vocab.org/frbr/core#term-Place>
I'd also like to draw links to FRBR in other places (owner, producer,
etc.).
> So, we would have something like:
>
> bibo:contribution [
> a bibo:Contribution ;
> bibo:role bibo_roles:recipient ;
> bibo:sentFrom <http://examples.net/location/1>;
> bibo:contributor <http://examples.net/contributors/1>
> ].
>
> <http://examples.net/location/1> a
> <http://www.w3.org/2003/01/geo/wgs84_pos#SpatialThing>;
> bibo:locality "New York".
> # other descriptions of the place
>
> that way you can describe further the number place and you have you
> string representation of the place via bibo:locality; and the number
> of triples is the same.
In my examples, I mostly assuming not entirely smart tools. It seems to
me what is important is that the property is an objectProperty; whether
it's identified or not is secondary.
But sure: would be nice for tools to use standard URIs for this stuff.
Is there not something already out there?? It's hard to believe there
isn't.
Bruce
>
> Hi Bruce,
>
>>> - bibo:owner (why? is it to make a distinction with
>>> dcterms:publisher,
>>> etc? Would need more information about these changes...)
>>>
>>
>> An archive does not publish documents; it owns/stores/holds them.
>>
>>
> Yup I agree, but the thing, I think, was that we were considering an
> owner a contributor in some way (so its why it was a role in a
> contribution).
No, we changed that; remember?
> So its why I am asking the question: why creating this property. Is it
> to make some separation between the Manifestation and the Items?
Exactly!
>>> - The web pages: what do we do? I would personally make WebPage
>>> subclass
>>> of Article and InternetSite subclass of Periodical. However, is a web
>>> site really a periodical? Don't think so. And is a WebPage an
>>> Article?
>>> Not always. So it is possibly why you changed that Bruce? If so, we
>>> should make sure of the description of what is a WebPage and an
>>> InternetSite. In fact, a Web page can be an article, but not always
>>> :)
>>>
>>
>> I'd be fine with ditching them altogether, particularly WebPage.
>>
>> But a WebPage is certainly a document; we can't say more than that.
>> Likewise, some sites (weblogs) have characteristics like periodicals
>> (what the library people call "seriials") in that they are updated on
>> a regular basis. But not all are.
>>
>> But I personally dislike treating web-based resource as somehow
>> special.
>>
>
> Agree that in some case, a web page is an article, other time its a
> document, other time its a Law, etc. So, web pages is only the medium
> used to publish the article.
>
> So, we only have to use the bibo:uri identifier (yet to be integrated
> into the owl document) to identify it on the Web.
>
> Is that right?
That's my preference.
Bruce
>> So, we would have something like:
>>
>> bibo:contribution [
>> a bibo:Contribution ;
>> bibo:role bibo_roles:recipient ;
>> bibo:sentFrom <http://examples.net/location/1>;
>> bibo:contributor <http://examples.net/contributors/1>
>> ].
>>
>> <http://examples.net/location/1> a
>> <http://www.w3.org/2003/01/geo/wgs84_pos#SpatialThing>;
>> bibo:locality "New York".
>> # other descriptions of the place
>>
>> that way you can describe further the number place and you have you
>> string representation of the place via bibo:locality; and the number
>> of triples is the same.
>>
>
> In my examples, I mostly assuming not entirely smart tools. It seems to
> me what is important is that the property is an objectProperty; whether
> it's identified or not is secondary.
>
> But sure: would be nice for tools to use standard URIs for this stuff.
> Is there not something already out there?? It's hard to believe there
> isn't.
>
Okay, but the idea here was to set the range of bibo:sentFrom and its
description :)
Take care,
Fred
> No, we changed that; remember?
>
>
No, at least, don't remember we agreed to clearly change :) But I agree
with that. However, its in this case that it would be important to fix
that on the wiki :) Could you please?
>> Agree that in some case, a web page is an article, other time its a
>> document, other time its a Law, etc. So, web pages is only the medium
>> used to publish the article.
>>
>> So, we only have to use the bibo:uri identifier (yet to be integrated
>> into the owl document) to identify it on the Web.
>>
>> Is that right?
>>
>
> That's my preference.
>
So, should delete both of them, and make two examples: one where the web
page is an article (as we have atm) and where the webpage is a Law (for
example, or a Document, or a Thesis, etc)
So that way people will understand the difference and how we handle web
pages.
Take care,
Fred
What about something like bibo:sponsor, so you could have:
<ahttp://example.edu/thesis/1> [
a bibo:Thesis ;
dc:title "Some thesis title" ;
bibo:sponsor <ahttp://example.edu/department/1> ; ].
<ahttp://example.edu/department/1> [
a foaf:Organization ;
dc:title "Some department" ; ].
Where <ahttp://example.edu/department/1> could be a school,
department, program, or other term for a "sponsoring entity". This
would also follow the "role noun" pattern[0], so you could read this
(indicating resources with their dc:title properties) as:
The thesis "Some thesis title" has sponsor the organization "Some department".
Take care,
John L. Clark
> What about something like bibo:sponsor
Sponsor does have the advantage that is also works for events (e.g. an
organization sponsors a conference).
Not sure if the semantics are quite, but it might work.
What do others think?
Bruce
bibo:organization seems to be neutral enough. I would either be specific
for a thesis (eg, bibo:school) or keep to bibo:organization...
My 2 cents...
Ivan
--