Zotero BIBO mapping and URIs
Bruce D'Arcus
social-networking functionality. Could people please take a look and
comment on the mappings ..
<http://www.zotero.org/trac/wiki/BiboMapping>
... and the URI schema?
<http://www.zotero.org/trac/wiki/URIScheme>
The tricky part here is how to model and identify Zotero items.
Bruce
Frederick Giasson
Really good!
Here are some questions about this page
(https://www.zotero.org/trac/wiki/URIScheme):
1- What is the relation between a group of items created by a user, and
a "collection" (if any)?
2- Will all items created by a user accessible by everybody? (So, is
there permissions for each created item?)
3- Are items "sharable" between multiple users? (any chance of having
one item create and maintained by multiple users?)
To the question "how to define an item", I would answer by asking
another question:
"What is such an item? What describes these items (properties)?"
Depending how we answer this question, I could suggest creating a
"zotero:Item" that would describe it. Otherwise, is it a bookmark, is it
a tag, etc.... personally I think we should consider creating a
zotero:Item if needed (not necessarly re-using something else if it
doesn't fit perfectly for this task).
About this page now (https://www.zotero.org/trac/wiki/BiboMapping):
1- For the serialization, the Zotero developers should consider testing
third parties JS libraries for parsing N3 files. There are a couple that
are already existing (one from Tabulator I think; and one with Ubiquity
(Mark's Ubiquity project)).
Otherwise about your SIOC comment, we should really check if it make
sense considering the current description of both SIOC and BIBO. I
remember I asked to check if we could make sioc:Post for example a
subClassOf a bibo:Document, but I think it is still on ice, so we
should make sure that this doesn't create inconsistencies in the Zotero
dataset.
However I think the current mapping is good; next step would be to
create actual resource descriptions of Zotero items by using this mapper
and to check if it is still that good :)
Thanks for sharing this Bruce!
Take care,
Fred
Bruce D'Arcus
...
> Here are some questions about this page
> (https://www.zotero.org/trac/wiki/URIScheme):
>
> 1- What is the relation between a group of items created by a user, and
> a "collection" (if any)?
A user has one library. Each library has zero-or-more items, and
zero-or-more collections.
Each item may belong to zero-or-more collections.
Collection may have child collections.
A group is a new feature, and it works as it does in social-networking
apps like Flickr or Twitter. One may add a personal item to a group,
so that there's a group reference list. See:
<http://www.zotero.org/blog/zotero-2mothership-lands/>
> 2- Will all items created by a user accessible by everybody? (So, is
> there permissions for each created item?)
No. Permissions can vary.
> 3- Are items "sharable" between multiple users? (any chance of having
> one item create and maintained by multiple users?)
Yes, via groups.
> To the question "how to define an item", I would answer by asking
> another question:
>
> "What is such an item? What describes these items (properties)?"
>
> Depending how we answer this question, I could suggest creating a
> "zotero:Item" that would describe it. Otherwise, is it a bookmark, is it
> a tag, etc.... personally I think we should consider creating a
> zotero:Item if needed (not necessarly re-using something else if it
> doesn't fit perfectly for this task).
In the Zotero UI, an item is all the properties of a source (article,
etc.), plus tags, plus notes, plus attachments, etc. All of these data
are specific to a user.
My point is these should be split into three resources:
a) something like a bookmark which includes the notes, tags, etc., and
points to both ..
b) the source
c) the user data about b, if it differs
I know this sounds obtuse, but consider that individual users often
create and maintain the source metadata, and if you have twenty
different users with the same source in the library, there may be
subtle differences between them. So you have to account for that.
> About this page now (https://www.zotero.org/trac/wiki/BiboMapping):
>
> 1- For the serialization, the Zotero developers should consider testing
> third parties JS libraries for parsing N3 files. There are a couple that
> are already existing (one from Tabulator I think; and one with Ubiquity
> (Mark's Ubiquity project)).
>
> Otherwise about your SIOC comment, we should really check if it make
> sense considering the current description of both SIOC and BIBO. I
> remember I asked to check if we could make sioc:Post for example a
> subClassOf a bibo:Document, but I think it is still on ice, so we
> should make sure that this doesn't create inconsistencies in the Zotero
> dataset.
Yes. How should we do that?
> However I think the current mapping is good; next step would be to
> create actual resource descriptions of Zotero items by using this mapper
> and to check if it is still that good :)
Yes.
Bruce
Bruce D'Arcus
On Tue, May 26, 2009 at 10:02 AM, Bruce D'Arcus <bda...@gmail.com> wrote:
....
> My point is these should be split into three resources:
>
> a) something like a bookmark which includes the notes, tags, etc., and
.. where at least the notes are separate resources, with their own URIs.
Bruce
Bruce D'Arcus
this list or not):
<http://forums.zotero.org/discussion/6966/uris-again/#Item_32>
Bruce
Frederick Giasson
>> Here are some questions about this page
>> (https://www.zotero.org/trac/wiki/URIScheme):
>>
>> 1- What is the relation between a group of items created by a user, and
>> a "collection" (if any)?
>>
>
> A user has one library. Each library has zero-or-more items, and
> zero-or-more collections.
>
> Each item may belong to zero-or-more collections.
>
> Collection may have child collections.
>
Good.
> A group is a new feature, and it works as it does in social-networking
> apps like Flickr or Twitter. One may add a personal item to a group,
> so that there's a group reference list. See:
>
> <http://www.zotero.org/blog/zotero-2mothership-lands/>
>
Would this information be available in RDF? So, are we talking about
creating RDF out of two things:
1- Zotero, the standalone FF addon
2- Zotero Server (where all this group information is archived I guess)
If not the two, which one of them?
>> 2- Will all items created by a user accessible by everybody? (So, is
>> there permissions for each created item?)
>>
>
> No. Permissions can vary.
>
Ok good. And this is supposed to be managed by the zotero server I guess?
>> 3- Are items "sharable" between multiple users? (any chance of having
>> one item create and maintained by multiple users?)
>>
>
> Yes, via groups.
>
Ok.
>> To the question "how to define an item", I would answer by asking
>> another question:
>>
>> "What is such an item? What describes these items (properties)?"
>>
>> Depending how we answer this question, I could suggest creating a
>> "zotero:Item" that would describe it. Otherwise, is it a bookmark, is it
>> a tag, etc.... personally I think we should consider creating a
>> zotero:Item if needed (not necessarly re-using something else if it
>> doesn't fit perfectly for this task).
>>
>
> In the Zotero UI, an item is all the properties of a source (article,
> etc.), plus tags, plus notes, plus attachments, etc. All of these data
> are specific to a user.
>
> My point is these should be split into three resources:
>
> a) something like a bookmark which includes the notes, tags, etc., and
> points to both ..
> b) the source
> c) the user data about b, if it differs
>
> I know this sounds obtuse, but consider that individual users often
> create and maintain the source metadata, and if you have twenty
> different users with the same source in the library, there may be
> subtle differences between them. So you have to account for that.
>
Humm, what about something like this:
Source (bibo:Document) <-- zotero:Item (tags, annotations, etc)
So, for the description of a source (ex: a bibo:Document), you would
have multiple links to it from zotero:Items (tags, annotations, etc; all
by different Zotero users).
Is it what I am understanding?
>> About this page now (https://www.zotero.org/trac/wiki/BiboMapping):
>>
>> 1- For the serialization, the Zotero developers should consider testing
>> third parties JS libraries for parsing N3 files. There are a couple that
>> are already existing (one from Tabulator I think; and one with Ubiquity
>> (Mark's Ubiquity project)).
>>
>> Otherwise about your SIOC comment, we should really check if it make
>> sense considering the current description of both SIOC and BIBO. I
>> remember I asked to check if we could make sioc:Post for example a
>> subClassOf a bibo:Document, but I think it is still on ice, so we
>> should make sure that this doesn't create inconsistencies in the Zotero
>> dataset.
>>
>
> Yes. How should we do that?
>
Well, by asking SIOC. Otherwise, if it ends-up not possible, than we
will have to consider just to use BIBO for this.
>> However I think the current mapping is good; next step would be to
>> create actual resource descriptions of Zotero items by using this mapper
>> and to check if it is still that good :)
>>
>
> Yes.
>
Good
Thanks,
Take care,
Fred
Frederick Giasson
> Followup on uris, from one of the zotero devs (not sure if he's on
> this list or not):
>
> <http://forums.zotero.org/discussion/6966/uris-again/#Item_32>
>
So:
- About this assertion: "Notes and attachments are just items and don't
have a separate URI pattern." I think I agree. This means that these
things would be part of the description of a zotero:Item
- About "/users/[username]/items", is it referring to a resource (some
kind of collection) that define a "bag" of zotero:Items (same for
"/users/[username]/collections")?
- About "User and group items will be asynchronously linked to abstract
items using owl:sameAs.", I don't know what he means, but in anycase I
am sure it is not the good property to use ;)
What I think that is emerging is that we have two things to describe here:
1- Sources (documents, films, etc; everything that get "bookmarked" by
Zotero
2- Zotero items (notes, tags, etc).
I think that #1 should be described using BIBO and I think that #2
should come from a Zotero ontology that create the classes for these
Items and sub-items, and the properties used to describe these Zotero
Items. Additionally external ontologies (if it make sense) could be used
to describe group of users, users, etc.
About this "I said above that "User/group-item-specific metadata can be
represented with a separate URI, e.g.,
/users/[username]/items/[itemID]/data, in RDF", as you suggested, so I'm
not sure what your concern is at this point. I'm generally happy to
defer to you/Fred/Simon on specific recommendations for the RDF
representation.":
I have no problem proposing something. Conneg could be used to negotiate
RDF (xml or n3) and Atom if need-be. Otherwise it is sure that they can
always add a html "link" element to link to these files. It is sure that
some more work would be needed for the Conneg part, but I am not sure it
is a that big technical challenge (this really depends on their
infrastructure, etc). So I would be happy to check this possibility with
them if they want.
Otherwise, there are three things we have to distinguish in this thread:
1- What are the tools (FF Zotero or Zotero Server or Both) have to
export RDF data
2- What to describe, and how to describe it (Sources "bookmarked" by
Zotero and Zotero items)
3- All the URI schemas and how different content types are made accessible.
Am I right?
Thanks,
Take care,
Fred
Bruce D'Arcus
...
>> A group is a new feature, and it works as it does in social-networking
>> apps like Flickr or Twitter. One may add a personal item to a group,
>> so that there's a group reference list. See:
>>
>> <http://www.zotero.org/blog/zotero-2mothership-lands/>
>>
> Would this information be available in RDF?
I don't see why not.
> So, are we talking about creating RDF out of two things:
>
> 1- Zotero, the standalone FF addon
> 2- Zotero Server (where all this group information is archived I guess)
>
> If not the two, which one of them?
I don't really know where they'll do the conversion, but certainly on
the server. Does it really matter?
>>> 2- Will all items created by a user accessible by everybody? (So, is
>>> there permissions for each created item?)
>>>
>>
>> No. Permissions can vary.
>>
> Ok good. And this is supposed to be managed by the zotero server I guess?
Yes.
Yes; that's how I understand it, But the devil is in the details.
...
Bruce
Frederick Giasson
>> So, are we talking about creating RDF out of two things:
>>
>> 1- Zotero, the standalone FF addon
>> 2- Zotero Server (where all this group information is archived I guess)
>>
>> If not the two, which one of them?
>>
>
> I don't really know where they'll do the conversion, but certainly on
> the server. Does it really matter?
>
Sure it does.
If (1), then it has do be an upgrade of the Zotero FF addon that would
do the conversion from the server.
If (2), then it would be a conversion performed by the server
The only exception is if the plugin could query the server to get the
serialized file.
BTW, is everything now synched from the plugin to the server in real time?
>> Humm, what about something like this:
>>
>> Source (bibo:Document) <-- zotero:Item (tags, annotations, etc)
>>
>> So, for the description of a source (ex: a bibo:Document), you would
>> have multiple links to it from zotero:Items (tags, annotations, etc; all
>> by different Zotero users).
>>
>> Is it what I am understanding?
>>
>
> Yes; that's how I understand it, But the devil is in the details.
>
Good.
So in that case, what is the next step?
Thanks,
Fred
Bruce D'Arcus
>
> Hi again,
>> Followup on uris, from one of the zotero devs (not sure if he's on
>> this list or not):
>>
>> <http://forums.zotero.org/discussion/6966/uris-again/#Item_32>
>>
>
> So:
>
> - About this assertion: "Notes and attachments are just items and don't
> have a separate URI pattern." I think I agree. This means that these
> things would be part of the description of a zotero:Item
Actually, I missed that, but disagree with the notes point. Each note
really needs it's own URI IMHO. For example, a number of users have
asked for the ability to link notes together. There's no way to do
that if they have no URI.
> - About "/users/[username]/items", is it referring to a resource (some
> kind of collection) that define a "bag" of zotero:Items (same for
> "/users/[username]/collections")?
This is the TBD here.
> - About "User and group items will be asynchronously linked to abstract
> items using owl:sameAs.", I don't know what he means, but in anycase I
> am sure it is not the good property to use ;)
>
> What I think that is emerging is that we have two things to describe here:
>
>
> 1- Sources (documents, films, etc; everything that get "bookmarked" by
> Zotero
> 2- Zotero items (notes, tags, etc).
>
> I think that #1 should be described using BIBO and I think that #2
> should come from a Zotero ontology that create the classes for these
> Items and sub-items, and the properties used to describe these Zotero
> Items. Additionally external ontologies (if it make sense) could be used
> to describe group of users, users, etc.
Except there's bibo:Note.
> About this "I said above that "User/group-item-specific metadata can be
> represented with a separate URI, e.g.,
> /users/[username]/items/[itemID]/data, in RDF", as you suggested, so I'm
> not sure what your concern is at this point. I'm generally happy to
> defer to you/Fred/Simon on specific recommendations for the RDF
> representation.":
>
> I have no problem proposing something. Conneg could be used to negotiate
> RDF (xml or n3) and Atom if need-be. Otherwise it is sure that they can
> always add a html "link" element to link to these files. It is sure that
> some more work would be needed for the Conneg part, but I am not sure it
> is a that big technical challenge (this really depends on their
> infrastructure, etc). So I would be happy to check this possibility with
> them if they want.
>
> Otherwise, there are three things we have to distinguish in this thread:
>
> 1- What are the tools (FF Zotero or Zotero Server or Both) have to
> export RDF data
> 2- What to describe, and how to describe it (Sources "bookmarked" by
> Zotero and Zotero items)
> 3- All the URI schemas and how different content types are made accessible.
>
> Am I right?
Yes.
Bruce
Bruce D'Arcus
>
> Hi Bruce,
>
>>> So, are we talking about creating RDF out of two things:
>>>
>>> 1- Zotero, the standalone FF addon
>>> 2- Zotero Server (where all this group information is archived I guess)
>>>
>>> If not the two, which one of them?
>>>
>>
>> I don't really know where they'll do the conversion, but certainly on
>> the server. Does it really matter?
>>
> Sure it does.
>
>
> If (1), then it has do be an upgrade of the Zotero FF addon that would
> do the conversion from the server.
> If (2), then it would be a conversion performed by the server
>
> The only exception is if the plugin could query the server to get the
> serialized file.
>
> BTW, is everything now synched from the plugin to the server in real time?
Yes, it is.
>>> Humm, what about something like this:
>>>
>>> Source (bibo:Document) <-- zotero:Item (tags, annotations, etc)
>>>
>>> So, for the description of a source (ex: a bibo:Document), you would
>>> have multiple links to it from zotero:Items (tags, annotations, etc; all
>>> by different Zotero users).
>>>
>>> Is it what I am understanding?
>>>
>>
>> Yes; that's how I understand it, But the devil is in the details.
>>
>
> Good.
>
> So in that case, what is the next step?
My sense is just to try to come up with some example RDF?
For example, what RDF should be returned from:
http://www.zotero.org/bdarcus/34/items/10038 (though imagine one or
more notes here as well)
... or:
http://www.zotero.org/bdarcus/34/items
...?
I'll try to work on this a little later today or tomorrow. If you (or
anyone else) have any ideas, post them?
Bruce
Frederick Giasson
>>
>> - About this assertion: "Notes and attachments are just items and don't
>> have a separate URI pattern." I think I agree. This means that these
>> things would be part of the description of a zotero:Item
>>
>
> Actually, I missed that, but disagree with the notes point. Each note
> really needs it's own URI IMHO. For example, a number of users have
> asked for the ability to link notes together. There's no way to do
> that if they have no URI.
>
>
Well right, and I should ahve revised that question since what I found
at the end of the thread is that you would have a zotero:Item as parent
class of zotero:Note, zotero:Tag or whatever (I am not suggesting to
create them right now; just talking to talk ;) )
right?
>> - About "User and group items will be asynchronously linked to abstract
>> items using owl:sameAs.", I don't know what he means, but in anycase I
>> am sure it is not the good property to use ;)
>>
>> What I think that is emerging is that we have two things to describe here:
>>
>>
>> 1- Sources (documents, films, etc; everything that get "bookmarked" by
>> Zotero
>> 2- Zotero items (notes, tags, etc).
>>
>> I think that #1 should be described using BIBO and I think that #2
>> should come from a Zotero ontology that create the classes for these
>> Items and sub-items, and the properties used to describe these Zotero
>> Items. Additionally external ontologies (if it make sense) could be used
>> to describe group of users, users, etc.
>>
>
> Except there's bibo:Note.
>
Sure, this has to be determined (what we reuse, what we create)
But we are not yet there I think ;)
>> About this "I said above that "User/group-item-specific metadata can be
>> represented with a separate URI, e.g.,
>> /users/[username]/items/[itemID]/data, in RDF", as you suggested, so I'm
>> not sure what your concern is at this point. I'm generally happy to
>> defer to you/Fred/Simon on specific recommendations for the RDF
>> representation.":
>>
>> I have no problem proposing something. Conneg could be used to negotiate
>> RDF (xml or n3) and Atom if need-be. Otherwise it is sure that they can
>> always add a html "link" element to link to these files. It is sure that
>> some more work would be needed for the Conneg part, but I am not sure it
>> is a that big technical challenge (this really depends on their
>> infrastructure, etc). So I would be happy to check this possibility with
>> them if they want.
>>
>> Otherwise, there are three things we have to distinguish in this thread:
>>
>> 1- What are the tools (FF Zotero or Zotero Server or Both) have to
>> export RDF data
>> 2- What to describe, and how to describe it (Sources "bookmarked" by
>> Zotero and Zotero items)
>> 3- All the URI schemas and how different content types are made accessible.
>>
>> Am I right?
>>
>
> Yes.
>
Good
Fred
Bruce D'Arcus
On Thu, May 28, 2009 at 12:00 PM, Bruce D'Arcus <bda...@gmail.com> wrote:
...
> For example, what RDF should be returned from:
>
> http://www.zotero.org/bdarcus/34/items/10038 (though imagine one or
> more notes here as well)
.. I think some of the modeling, even in the UI, is less-than-ideal.
For example, calling "Amazon" the "repository" for this record is
really misleading. It's one place to obtain it from, and it's where
the metadata once extracted from.
Likewise, you've got three different dates, with no distinction
between them. This may be how it's modeled in their SQL, but I think
it's a) confusing, and b) not good to carry through to the RDF.
Bruce
Sean Takats
mapping of Zotero to BIBO (https://www.zotero.org/trac/wiki/
BiboMapping), but there are several outstanding issues that still need
to be resolved, if they're going to be, on the BIBO side of things,
including:
Patent support
Computer program support
A few missing fields that BIBO should consider (number of pages,
access date, etc.)
All of these items are marked on the Wiki page with a question mark,
and there are only about 15 remaining. If people could take a look
sooner rather than later, we would greatly appreciate it. The sooner
that this mapping is complete, the sooner that we can begin deploying
using BIBO in our import/export and elsewhere. We're very close!
Many thanks for your help.
Best regards,
Sean
Frederick Giasson
Fantastic, thanks!
I can't do anything today, but I will try to write an update proposition
on the BIBO mailing list before the end of this week. So we could have
an update of bibo (ontology + website) sometime next week if everything
goes fine.
Does that work?
Thanks,
Fred
Bruce D'Arcus
>
> With some valuable input from Bruce, Simon has largely completed the
> mapping of Zotero to BIBO (https://www.zotero.org/trac/wiki/
> BiboMapping), but there are several outstanding issues that still need
> to be resolved, if they're going to be, on the BIBO side of things,
> including:
>
> Patent support
> Computer program support
> A few missing fields that BIBO should consider (number of pages,
> access date, etc.)
On access date, this fits with what I've been telling Dan: that Zotero
really needs to split off--in both the data, and the UI--user data
from the data about the source. I would say access date might belong
in the former. In any case, this is the issue that explains why it;s
not currently there.
As I suggest on that wiki page ,there;s some question also about how
to handle the resource list stuff, since there's the Talis vocab,
annotea, and SIOC.
> All of these items are marked on the Wiki page with a question mark,
> and there are only about 15 remaining. If people could take a look
> sooner rather than later, we would greatly appreciate it.
If we have suggested changes on some of the existing mappings (like
uri should probably be bibo:uri), any suggestions on how we do that?
Is it fine, for example, to just make the change, and let Simon use
the revision history to see it?
Bruce
Sean Takats
On Jul 1, 2009, at 9:20 AM, Bruce D'Arcus wrote:
>
> On Wed, Jul 1, 2009 at 2:34 AM, Sean Takats<tak...@aya.yale.edu>
> wrote:
>>
>> With some valuable input from Bruce, Simon has largely completed the
>> mapping of Zotero to BIBO (https://www.zotero.org/trac/wiki/
>> BiboMapping), but there are several outstanding issues that still
>> need
>> to be resolved, if they're going to be, on the BIBO side of things,
>> including:
>>
>> Patent support
>> Computer program support
>> A few missing fields that BIBO should consider (number of pages,
>> access date, etc.)
>
> On access date, this fits with what I've been telling Dan: that Zotero
> really needs to split off--in both the data, and the UI--user data
> from the data about the source. I would say access date might belong
> in the former. In any case, this is the issue that explains why it;s
> not currently there.
>
For a source that's expected to change, like a home page, would you
consider the access date to be data about that source?
> As I suggest on that wiki page ,there;s some question also about how
> to handle the resource list stuff, since there's the Talis vocab,
> annotea, and SIOC.
>
>> All of these items are marked on the Wiki page with a question mark,
>> and there are only about 15 remaining. If people could take a look
>> sooner rather than later, we would greatly appreciate it.
>
> If we have suggested changes on some of the existing mappings (like
> uri should probably be bibo:uri), any suggestions on how we do that?
> Is it fine, for example, to just make the change, and let Simon use
> the revision history to see it?
>
Absolutely. Please feel free to edit the wiki page at will.
Many thanks for your help!
Sean
Bruce D'Arcus
1) number of volumes: unfortunately, this is ambiguous. Do we need a
MultiVolumeBook class, and attach a numberOfVolumes property to it?
2) assignee (for a Patent); we probably should just add this.
3) priorityNumbers: I have no idea what this means.
4) legalStatus: again, what is this? can this not be handled using the
more generic bibo:status property? If yes, we probably need to add
URIs for possible values.
5) system: again, what is this?
6) scale: I take it this is for a map or other such spatial
representation? If yes, we probably need it.
7) numPages: another of these that make me cringe a bit, but I suppose
we should add it
Bruce
skornblith
> OK, here's what I see we need to consider:
>
> 1) number of volumes: unfortunately, this is ambiguous. Do we need a
> MultiVolumeBook class, and attach a numberOfVolumes property to it?
be mistaken.
> 2) assignee (for a Patent); we probably should just add this.
>
> 3) priorityNumbers: I have no idea what this means.
> 4) legalStatus: again, what is this? can this not be handled using the
> more generic bibo:status property? If yes, we probably need to add
> URIs for possible values.
sufficient. I've updated the site.
> 5) system: again, what is this?
> 6) scale: I take it this is for a map or other such spatial
> representation? If yes, we probably need it.
> 7) numPages: another of these that make me cringe a bit, but I suppose
> we should add it
necessary.
You also still need to address Sean's comment's re: the access date.
If bibo is going to serve as a standard interchange format for
citation-related data, my feeling is that this is a necessary evil,
since it is still a requirement in many citation styles.
Bruce D'Arcus
...
>> 7) numPages: another of these that make me cringe a bit, but I suppose
>> we should add it
>
> It is required in some bibliographic citation formats, so it seems
> necessary.
It just points to some deliberate ambiguity in BIBO; is a bibo:Book a
frbr:Expression or a frbr:Manifestation? E.g. what level of
abstraction do the pages refer to?
> You also still need to address Sean's comment's re: the access date.
> If bibo is going to serve as a standard interchange format for
> citation-related data, my feeling is that this is a necessary evil,
> since it is still a requirement in many citation styles.
This isn't that straightforward, so let me explain:
It relates to the abstraction issue I mention above, and for
mergability of these data.
An access date doesn't really make sense as a literal property on a
bibo:Document, for the same reason it doesn't make any sense to add a
bibtex:key property: they are both data about the relation between a
person and the document. Put simply, these are user data.
So in turtle, I want to say:
<http://zotero.org/doej/items/1> a rs:Item ;
z:accessed "2009-07-03" ;
z:label "smith09" ;
rs:resource <http://zotero.org/doej/resource/1> .
<http://zotero.org/doej/resource/1> a bibo:Article ;
dcterms:title "Whatever Article" ;
owl:sameAs <http://somewhere.org/articles/x> .
Bruce
skornblith
> On Sat, Jul 4, 2009 at 7:17 PM, skornblith<si...@simonster.com> wrote:
>
> ...
>
> >> 7) numPages: another of these that make me cringe a bit, but I suppose
> >> we should add it
>
> > It is required in some bibliographic citation formats, so it seems
> > necessary.
>
> It just points to some deliberate ambiguity in BIBO; is a bibo:Book a
> frbr:Expression or a frbr:Manifestation? E.g. what level of
> abstraction do the pages refer to?
same abstraction issue to some extent? Or bibo:publisher (since the
same book could be published by two different entities)? My feeling is
that bibo should formalize bibliographically relevant information, and
this is certainly bibliographically relevant.
> > You also still need to address Sean's comment's re: the access date.
> > If bibo is going to serve as a standard interchange format for
> > citation-related data, my feeling is that this is a necessary evil,
> > since it is still a requirement in many citation styles.
>
> This isn't that straightforward, so let me explain:
>
> It relates to the abstraction issue I mention above, and for
> mergability of these data.
>
> An access date doesn't really make sense as a literal property on a
> bibo:Document, for the same reason it doesn't make any sense to add a
> bibtex:key property: they are both data about the relation between a
> person and the document. Put simply, these are user data.
>
> So in turtle, I want to say:
>
> <http://zotero.org/doej/items/1> a rs:Item ;
> z:accessed "2009-07-03" ;
> z:label "smith09" ;
> rs:resource <http://zotero.org/doej/resource/1> .
>
> <http://zotero.org/doej/resource/1> a bibo:Article ;
> dcterms:title "Whatever Article" ;
> owl:sameAs <http://somewhere.org/articles/x> .
bibo:Webpage, then the access date is information that identifies the
specific resource being described. Additionally, from a pragmatic
standpoint, it is impossible to share citation information among
processors (at least WRT webpages) unless there is some standardized
way of specifying this property.
Simon
Bruce D'Arcus
>
> On Jul 4, 5:19 pm, "Bruce D'Arcus" <bdar...@gmail.com> wrote:
>> On Sat, Jul 4, 2009 at 7:17 PM, skornblith<si...@simonster.com> wrote:
>>
>> ...
>>
>> >> 7) numPages: another of these that make me cringe a bit, but I suppose
>> >> we should add it
>>
>> > It is required in some bibliographic citation formats, so it seems
>> > necessary.
>>
>> It just points to some deliberate ambiguity in BIBO; is a bibo:Book a
>> frbr:Expression or a frbr:Manifestation? E.g. what level of
>> abstraction do the pages refer to?
>
> Unless I'm misunderstanding something, doesn't bibo:pages have the
> same abstraction issue to some extent?
Yes; duh.
So Fred, we should add this. It might suggest a more generic
bibo:extent or similar property, and then a bibo:pageExtent or some
such subproperty.
>> > You also still need to address Sean's comment's re: the access date.
>> > If bibo is going to serve as a standard interchange format for
>> > citation-related data, my feeling is that this is a necessary evil,
>> > since it is still a requirement in many citation styles.
>>
>> This isn't that straightforward, so let me explain:
>>
>> It relates to the abstraction issue I mention above, and for
>> mergability of these data.
>>
>> An access date doesn't really make sense as a literal property on a
>> bibo:Document, for the same reason it doesn't make any sense to add a
>> bibtex:key property: they are both data about the relation between a
>> person and the document. Put simply, these are user data.
>>
>> So in turtle, I want to say:
>>
>> <http://zotero.org/doej/items/1> a rs:Item ;
>> z:accessed "2009-07-03" ;
>> z:label "smith09" ;
>> rs:resource <http://zotero.org/doej/resource/1> .
>>
>> <http://zotero.org/doej/resource/1> a bibo:Article ;
>> dcterms:title "Whatever Article" ;
>> owl:sameAs <http://somewhere.org/articles/x> .
>
> But, as Sean pointed out above, if the bibo:Document is a
> bibo:Webpage, then the access date is information that identifies the
> specific resource being described.
OK, this is a good point. The case of a bibo:WebPage that is changing
(which is most commonly going to be a wiki page) is a tricky one.
But as I've mentioned somewhere before, an access date still doesn't
identify the version of the page; it's orthogonal to the update date
(which is what's really important).. E.g. if I access some wikipedia
page today, and you do tomorrow, but the document does not change,
they're still the exact same document.
> Additionally, from a pragmatic
> standpoint, it is impossible to share citation information among
> processors (at least WRT webpages) unless there is some standardized
> way of specifying this property.
I wonder if Rob has any thoughts on this, given that he requested bibo:WebPage.
In any case, purely from the standpoint of RDF idioms, the way you
typically model documents that change is to define each snapshot as a
separate document, and then link each to a more abstract document.
That's how the BIBO spec document works.
I'm not denying this is an issue we should try to solve; I'm just
explaining to you why it's not solved already, and hoping other people
can help out here.
Bruce
Bruce D'Arcus
...
> In any case, purely from the standpoint of RDF idioms, the way you
> typically model documents that change is to define each snapshot as a
> separate document, and then link each to a more abstract document.
> That's how the BIBO spec document works.
Here's how SIOC does it:
<http://rdfs.org/sioc/spec/#term_next_version>
So you have properties that links versions, and I guess use dcterms:modified.
Of course, it's hard to scrape that information; works better when a
wiki app (or whatever) can export it's own data.
Bruce
KiYanWang
we tried to define in Resource List Ontology: http://vocab.org/resourcelist/schema-20080519.html
Bruce and I have briefly discussed the fact that there is a great deal
of overlap here, and perhaps Zotero could also use Resource List
Ontology.
We are currently in the process of updating the published version of
the resource list vocab, since the current version is out of date. I
think this would be the ideal time to start thinking about how it
could be used to fulfill Zotero's needs as well as our own.
Obviously the Resource List vocab doesn't directly describe
bibliographic resources, but it does describe how those resources are
collected together into a resource list, the order of items, the
structure of the list etc.
The major difference between what we are currently doing and the
published version is that we no longer use the 'next' and 'previous'
properties for determining the order of sections / items on a list. We
now use rdf:Sequences which is much easier to work with. There are a
number of other things some new properties etc.. If I try and get the
latest version published by the end of this week that should provide
us all with something we can frame the discussion around.
> An access date doesn't really make sense as a literal property on a
> bibo:Document, for the same reason it doesn't make any sense to add a
> bibtex:key property: they are both data about the relation between a
> person and the document. Put simply, these are user data.
contains sections and items. Items point to the resource that they
relate to. We think of an item as the instance of a resource on a
list, this allows us to add data to the item that the user thought was
valuable, without modifying the underlying bibliographic resource
which we may have sourced from an external, more authoritative, data
set. For example, in the case of Aspire, we convert marc description
from a customers opac into a bibo resource when a user at that
institution adds an item to their list that appears in the
universities library catalogue.
So for us the distinction between and Item and Resource is very
important.
Nadeem
Frederick Giasson
> This isn't that straightforward, so let me explain:
>
> It relates to the abstraction issue I mention above, and for
> mergability of these data.
>
> An access date doesn't really make sense as a literal property on a
> bibo:Document, for the same reason it doesn't make any sense to add a
> bibtex:key property: they are both data about the relation between a
> person and the document. Put simply, these are user data.
>
> So in turtle, I want to say:
>
> <http://zotero.org/doej/items/1> a rs:Item ;
> z:accessed "2009-07-03" ;
> z:label "smith09" ;
> rs:resource <http://zotero.org/doej/resource/1> .
>
> <http://zotero.org/doej/resource/1> a bibo:Article ;
> dcterms:title "Whatever Article" ;
> owl:sameAs <http://somewhere.org/articles/x> .
>
This is really related to a "Data Access" ontology. This is not related
to BIBO (or any bibliographic things) only. This is really a widespread
thing: what Agent accessed what Resource at what Time?
This is that general, and this has to be taken into account by some king
of Data Access ontologies (have no idea if such an ontology currently
exists).
Thanks,
Fred
Frederick Giasson
> Yes; duh.
>
> So Fred, we should add this. It might suggest a more generic
> bibo:extent or similar property, and then a bibo:pageExtent or some
> such subproperty.
>
I agree. I will wrap-up a email about these additions.
A distinction has to be made: updated vs. accessed.
>> Additionally, from a pragmatic
>> standpoint, it is impossible to share citation information among
>> processors (at least WRT webpages) unless there is some standardized
>> way of specifying this property.
>>
>
> I wonder if Rob has any thoughts on this, given that he requested bibo:WebPage.
>
> In any case, purely from the standpoint of RDF idioms, the way you
> typically model documents that change is to define each snapshot as a
> separate document, and then link each to a more abstract document.
> That's how the BIBO spec document works.
>
> I'm not denying this is an issue we should try to solve; I'm just
> explaining to you why it's not solved already, and hoping other people
> can help out here.
>
This is really something that can be modeled in many, different, ways.
For example, we could think about creating a property bibo:dateUpdated
(subPropertyof dcterms:date).
Or we could do what Bruce suggested above: we create one document, with
their own URI, per version. Then each version would have a
dcterms:created property. So, no need of the property bibo:dateUpdated.
The lastest document of the version chain is the latest version of the
document (you can reason has its dcterms:created property as being
bibo:dateUpdated), etc.
For example, with OWL2, you endup with one URI per ontology version.
However you have one canonical URI which is the latest version.
It really depends on the expressiveness level we want to archive.
Thanks,
Fred
Frederick Giasson
requirements:
1- addition of bibo:volumes (to keep some consistency with bibo:pages?)
2- addition of bibo:assignee
3- addition of bibo:numPages
4- addition of a legal status (bibo:status individual) (I would need a
list of such legal status) (also, we could create a legalStatus property
subPropertyOf bibo:status if this would be helpful)
5- addition of the bibo:handle identifier
Otherwise, I will need more information about the other "?" on this
page: https://www.zotero.org/trac/wiki/BiboMapping
Thanks,
Fred
Bruce D'Arcus
> So, here is the proposition of the next version to meet Zotero's
> requirements:
>
> 1- addition of bibo:volumes (to keep some consistency with bibo:pages?)
No; this isn't that straightforward. What would "volumes" even mean?
See my comments earlier in the thread.
> 2- addition of bibo:assignee
> 3- addition of bibo:numPages
Well, again, needs to be clear, and needs to be extensible.
> 4- addition of a legal status (bibo:status individual) (I would need a
> list of such legal status) (also, we could create a legalStatus property
> subPropertyOf bibo:status if this would be helpful)
No; not needed. Just add indiividuals for bibo:status.
> 5- addition of the bibo:handle identifier
Bruce
skornblith
BiboMapping) to include our creator types. At the moment, we plan to
rely upon the MARC relator terms to handle much of these (http://
lcweb2.loc.gov/diglib/loc.terms/relators/dc-contributor.html). I'm not
sure whether or not this is in line with the goals of BIBO, and I'd
welcome any comments on the issue.
Since much of the code is now written, and it would be nice to include
a stable BIBO export format in Zotero 2.0, it would be helpful to
arrive at a consensus regarding the following points:
1) Addition of a property to handle the number of volumes.
bibo:numVolumes, bibo:numberOfVolumes, or bibo:volumesExtent seem like
logical choices.
2) Addition of bibo:assignee. There didn't seem to be much
disagreement about this, but alternatively, we could also use the MARC
relator terms to handle this.
3) Addition of a property to handle the number of pages. bibo:numPages
or bibo:pagesExtent.
4) Addition of bibo:priorityNumber. This is the priority number on a
patent, used to refer to prior patent application(s) when an inventor
applies for a subsequent patent on the same invention. See
http://gb.espacenet.com/espacenet/gb/en/help/15353.htm and
http://en.wikipedia.org/wiki/Priority_right.
5) Addition of bibo:attorney, for use with bibo:LegalDecision and
bibo:Patent. This seems relatively straightforward, but there doesn't
seem to be an appropriate MARC relator term.
6) An appropriate resolution to the z:accessDate conundrum. While
there seems to be a consensus against adding an accessDate property to
BIBO, I am still a little concerned about the interoperability
implications of hosting this property in the Zotero namespace. I'd
welcome any comments on the issue.
If these any of these terms are not appropriate for BIBO, I'll happily
host them in the Zotero namespace (which will one day have a proper
ontology). But, since the data itself should not be specific to
Zotero, I am a bit leery of doing this,
Bruce D'Arcus
On Thu, Sep 10, 2009 at 4:30 PM, skornblith <si...@simonster.com> wrote:
>
> I've updated the BIBO Mapping (https://www.zotero.org/trac/wiki/
> BiboMapping) to include our creator types. At the moment, we plan to
> rely upon the MARC relator terms to handle much of these (http://
> lcweb2.loc.gov/diglib/loc.terms/relators/dc-contributor.html). I'm not
> sure whether or not this is in line with the goals of BIBO, and I'd
> welcome any comments on the issue.
I think that's way out of date in terms of how its expressed in RDF.
What's wrong with the bibo contributor properties?
> Since much of the code is now written, and it would be nice to include
> a stable BIBO export format in Zotero 2.0, it would be helpful to
> arrive at a consensus regarding the following points:
>
> 1) Addition of a property to handle the number of volumes.
> bibo:numVolumes, bibo:numberOfVolumes, or bibo:volumesExtent seem like
> logical choices.
> 2) Addition of bibo:assignee. There didn't seem to be much
> disagreement about this, but alternatively, we could also use the MARC
> relator terms to handle this.
> 3) Addition of a property to handle the number of pages. bibo:numPages
> or bibo:pagesExtent.
These seems fine, but I think we just want a) to be consistent, and b)
leave room for other kinds of extent descriptions (think the running
time for a film).
Fred, how do you want to handle adding these?
> 4) Addition of bibo:priorityNumber. This is the priority number on a
> patent, used to refer to prior patent application(s) when an inventor
> applies for a subsequent patent on the same invention. See
> http://gb.espacenet.com/espacenet/gb/en/help/15353.htm and
> http://en.wikipedia.org/wiki/Priority_right.
> 5) Addition of bibo:attorney, for use with bibo:LegalDecision and
> bibo:Patent. This seems relatively straightforward, but there doesn't
> seem to be an appropriate MARC relator term.
It isn't at all clear to me that this is necessary, nor what the role
really is here.If you're talking about legal decision, you have
defense attorneys and plaintiff attorneys. But legal citations don't
include these
Similarly, with patents, what's the significance of the attorney? Is
it a legal proxy for the applicant?
> 6) An appropriate resolution to the z:accessDate conundrum. While
> there seems to be a consensus against adding an accessDate property to
> BIBO, I am still a little concerned about the interoperability
> implications of hosting this property in the Zotero namespace. I'd
> welcome any comments on the issue.
I think this sort of thing belongs with the Talis Resource list
vocabulary. Nadim or Chris, you guys around to comment on this?
> If these any of these terms are not appropriate for BIBO, I'll happily
> host them in the Zotero namespace (which will one day have a proper
> ontology). But, since the data itself should not be specific to
> Zotero, I am a bit leery of doing this,
I think most of the stuff you're worried about here can and should be
covered in the Resource list thing.
Bruce
skornblith
> Issues below for Fred and Nadim and/or Chris; we need to resolve these ...
>
> On Thu, Sep 10, 2009 at 4:30 PM, skornblith <si...@simonster.com> wrote:
>
> > I've updated the BIBO Mapping (https://www.zotero.org/trac/wiki/
> > BiboMapping) to include our creator types. At the moment, we plan to
> > rely upon the MARC relator terms to handle much of these (http://
> > lcweb2.loc.gov/diglib/loc.terms/relators/dc-contributor.html). I'm not
> > sure whether or not this is in line with the goals of BIBO, and I'd
> > welcome any comments on the issue.
>
> I think that's way out of date in terms of how its expressed in RDF.
> What's wrong with the bibo contributor properties?
some (e.g., "artist" and "cartographer") we could probably use
dcterms:creator. But, ignoring primary creator types, there are still
no mappings in BIBO for
attorneyAgent (on patent)
composer (on audioRecording; we could get this from the Music
Ontology)
guest (on tvBroadcast, radioBroadcast, and podcast)
scriptwriter (on film, videoRecording, tvBoradcast, and
radioBroadcast)
wordsBy (on audioRecording; doesn't seem to be possible to model using
the Music Ontology)
The MARC vocabulary is ugly, but it's comprehensive, and some of these
seem pretty important. I'd welcome any advice on how to map these
without MARC.
> > Since much of the code is now written, and it would be nice to include
> > a stable BIBO export format in Zotero 2.0, it would be helpful to
> > arrive at a consensus regarding the following points:
>
> > 1) Addition of a property to handle the number of volumes.
> > bibo:numVolumes, bibo:numberOfVolumes, or bibo:volumesExtent seem like
> > logical choices.
> > 2) Addition of bibo:assignee. There didn't seem to be much
> > disagreement about this, but alternatively, we could also use the MARC
> > relator terms to handle this.
> > 3) Addition of a property to handle the number of pages. bibo:numPages
> > or bibo:pagesExtent.
>
> These seems fine, but I think we just want a) to be consistent, and b)
> leave room for other kinds of extent descriptions (think the running
> time for a film).
dcterms:extent for artworkSize.
> Fred, how do you want to handle adding these?
>
> > 4) Addition of bibo:priorityNumber. This is the priority number on a
> > patent, used to refer to prior patent application(s) when an inventor
> > applies for a subsequent patent on the same invention. See
> >http://gb.espacenet.com/espacenet/gb/en/help/15353.htmand
> >http://en.wikipedia.org/wiki/Priority_right.
> > 5) Addition of bibo:attorney, for use with bibo:LegalDecision and
> > bibo:Patent. This seems relatively straightforward, but there doesn't
> > seem to be an appropriate MARC relator term.
>
> It isn't at all clear to me that this is necessary, nor what the role
> really is here.If you're talking about legal decision, you have
> defense attorneys and plaintiff attorneys. But legal citations don't
> include these
>
> Similarly, with patents, what's the significance of the attorney? Is
> it a legal proxy for the applicant?
"counsel" property on legalDecision is probably not useful. We can't
really pull these fields, but if they're suitably useless/unimportant,
maybe we should just stick them in our own ontology.
> > 6) An appropriate resolution to the z:accessDate conundrum. While
> > there seems to be a consensus against adding an accessDate property to
> > BIBO, I am still a little concerned about the interoperability
> > implications of hosting this property in the Zotero namespace. I'd
> > welcome any comments on the issue.
>
> I think this sort of thing belongs with the Talis Resource list
> vocabulary. Nadim or Chris, you guys around to comment on this?
be any kind of access date property.
Frederick Giasson
>> I've updated the BIBO Mapping (https://www.zotero.org/trac/wiki/
>> BiboMapping) to include our creator types. At the moment, we plan to
>> rely upon the MARC relator terms to handle much of these (http://
>> lcweb2.loc.gov/diglib/loc.terms/relators/dc-contributor.html). I'm not
>> sure whether or not this is in line with the goals of BIBO, and I'd
>> welcome any comments on the issue.
>>
>
> I think that's way out of date in terms of how its expressed in RDF.
> What's wrong with the bibo contributor properties?
>
Please confirm.
>> Since much of the code is now written, and it would be nice to include
>> a stable BIBO export format in Zotero 2.0, it would be helpful to
>> arrive at a consensus regarding the following points:
>>
>> 1) Addition of a property to handle the number of volumes.
>> bibo:numVolumes, bibo:numberOfVolumes, or bibo:volumesExtent seem like
>> logical choices.
>> 2) Addition of bibo:assignee. There didn't seem to be much
>> disagreement about this, but alternatively, we could also use the MARC
>> relator terms to handle this.
>> 3) Addition of a property to handle the number of pages. bibo:numPages
>> or bibo:pagesExtent.
>>
>
> These seems fine, but I think we just want a) to be consistent, and b)
> leave room for other kinds of extent descriptions (think the running
> time for a film).
>
> Fred, how do you want to handle adding these?
>
I think lets add them. It was planned to add numPages for example. See
bellow for more information.
>> 4) Addition of bibo:priorityNumber. This is the priority number on a
>> patent, used to refer to prior patent application(s) when an inventor
>> applies for a subsequent patent on the same invention. See
>> http://gb.espacenet.com/espacenet/gb/en/help/15353.htm and
>> http://en.wikipedia.org/wiki/Priority_right.
>> 5) Addition of bibo:attorney, for use with bibo:LegalDecision and
>> bibo:Patent. This seems relatively straightforward, but there doesn't
>> seem to be an appropriate MARC relator term.
>>
>
> It isn't at all clear to me that this is necessary, nor what the role
> really is here.If you're talking about legal decision, you have
> defense attorneys and plaintiff attorneys. But legal citations don't
> include these
>
> Similarly, with patents, what's the significance of the attorney? Is
> it a legal proxy for the applicant?
>
More info needed.
>> 6) An appropriate resolution to the z:accessDate conundrum. While
>> there seems to be a consensus against adding an accessDate property to
>> BIBO, I am still a little concerned about the interoperability
>> implications of hosting this property in the Zotero namespace. I'd
>> welcome any comments on the issue.
>>
>
> I think this sort of thing belongs with the Talis Resource list
> vocabulary. Nadim or Chris, you guys around to comment on this?
>
I agree.
>> If these any of these terms are not appropriate for BIBO, I'll happily
>> host them in the Zotero namespace (which will one day have a proper
>> ontology). But, since the data itself should not be specific to
>> Zotero, I am a bit leery of doing this,
>>
>
> I think most of the stuff you're worried about here can and should be
> covered in the Resource list thing.
>
So, here is what I will do. On Monday or Tuesday I will create an
update, list all proposed modifications according to this email and the
Zotero mapping proposed.
Then if everyone agree, we will release this new version has BIBO 1.3,
and will generate the proper documentation and N3 & XML files.
This mean that this can be set by middle next week.
Then we will release a new community website in the coming month or so.
Does that work for everybody?
Thanks!
Take care,
Fred
Bruce D'Arcus
>>> Since much of the code is now written, and it would be nice to include
>>> a stable BIBO export format in Zotero 2.0, it would be helpful to
>>> arrive at a consensus regarding the following points:
>>>
>>> 1) Addition of a property to handle the number of volumes.
>>> bibo:numVolumes, bibo:numberOfVolumes, or bibo:volumesExtent seem like
>>> logical choices.
>>> 2) Addition of bibo:assignee. There didn't seem to be much
>>> disagreement about this, but alternatively, we could also use the MARC
>>> relator terms to handle this.
>>> 3) Addition of a property to handle the number of pages. bibo:numPages
>>> or bibo:pagesExtent.
>>>
>>
>> These seems fine, but I think we just want a) to be consistent, and b)
>> leave room for other kinds of extent descriptions (think the running
>> time for a film).
>>
>> Fred, how do you want to handle adding these?
>>
> I think lets add them. It was planned to add numPages for example. See
> bellow for more information.
I do want to note that on the volumes issue, I don't believe anyone
responded to my earlier point that it would seem to only make sense in
a domain of something like MultiVolumeBook or some such.
So it seems if we add the property, we ought to add the class too, and
tie them together?
[snip]
> So, here is what I will do. On Monday or Tuesday I will create an
> update, list all proposed modifications according to this email and the
> Zotero mapping proposed.
>
> Then if everyone agree, we will release this new version has BIBO 1.3,
> and will generate the proper documentation and N3 & XML files.
>
> This mean that this can be set by middle next week.
>
> Then we will release a new community website in the coming month or so.
>
> Does that work for everybody?
Works for me.
Bruce
Bruce D'Arcus
>
> On Sep 10, 1:50 pm, "Bruce D'Arcus" <bdar...@gmail.com> wrote:
>> Issues below for Fred and Nadim and/or Chris; we need to resolve these ...
>>
>> On Thu, Sep 10, 2009 at 4:30 PM, skornblith <si...@simonster.com> wrote:
>>
>> > I've updated the BIBO Mapping (https://www.zotero.org/trac/wiki/
>> > BiboMapping) to include our creator types. At the moment, we plan to
>> > rely upon the MARC relator terms to handle much of these (http://
>> > lcweb2.loc.gov/diglib/loc.terms/relators/dc-contributor.html). I'm not
>> > sure whether or not this is in line with the goals of BIBO, and I'd
>> > welcome any comments on the issue.
>>
>> I think that's way out of date in terms of how its expressed in RDF.
>> What's wrong with the bibo contributor properties?
>
> If you look at the list, it's clear that they're not quite enough. For
> some (e.g., "artist" and "cartographer") we could probably use
> dcterms:creator. But, ignoring primary creator types, there are still
> no mappings in BIBO for
>
> attorneyAgent (on patent)
> composer (on audioRecording; we could get this from the Music
> Ontology)
> guest (on tvBroadcast, radioBroadcast, and podcast)
> scriptwriter (on film, videoRecording, tvBoradcast, and
> radioBroadcast)
> wordsBy (on audioRecording; doesn't seem to be possible to model using
> the Music Ontology)
Some of the above gets into some modeling issues, where your phrases
suggest a flat approach, but both bibo and mo would be treating them
as relations. For example, instead of thinking in terms of wordsBy,
you could think of an audio recording of a reading of some book, and
so two resource descriptions, rather than one.
> The MARC vocabulary is ugly, but it's comprehensive, and some of these
> seem pretty important. I'd welcome any advice on how to map these
> without MARC.
MARC is ugly, because in part its totally flat. BIBO isn't,.
>> > Since much of the code is now written, and it would be nice to include
>> > a stable BIBO export format in Zotero 2.0, it would be helpful to
>> > arrive at a consensus regarding the following points:
>>
>> > 1) Addition of a property to handle the number of volumes.
>> > bibo:numVolumes, bibo:numberOfVolumes, or bibo:volumesExtent seem like
>> > logical choices.
>> > 2) Addition of bibo:assignee. There didn't seem to be much
>> > disagreement about this, but alternatively, we could also use the MARC
>> > relator terms to handle this.
>> > 3) Addition of a property to handle the number of pages. bibo:numPages
>> > or bibo:pagesExtent.
>>
>> These seems fine, but I think we just want a) to be consistent, and b)
>> leave room for other kinds of extent descriptions (think the running
>> time for a film).
>
> For runningTime, we're currently using po:duration. We use
> dcterms:extent for artworkSize.
OK.
>> Fred, how do you want to handle adding these?
>>
>> > 4) Addition of bibo:priorityNumber. This is the priority number on a
>> > patent, used to refer to prior patent application(s) when an inventor
>> > applies for a subsequent patent on the same invention. See
>> >http://gb.espacenet.com/espacenet/gb/en/help/15353.htmand
>> >http://en.wikipedia.org/wiki/Priority_right.
>> > 5) Addition of bibo:attorney, for use with bibo:LegalDecision and
>> > bibo:Patent. This seems relatively straightforward, but there doesn't
>> > seem to be an appropriate MARC relator term.
>>
>> It isn't at all clear to me that this is necessary, nor what the role
>> really is here.If you're talking about legal decision, you have
>> defense attorneys and plaintiff attorneys. But legal citations don't
>> include these
>>
>> Similarly, with patents, what's the significance of the attorney? Is
>> it a legal proxy for the applicant?
>
> I think your guess is right re: patents, but I agree that our
> "counsel" property on legalDecision is probably not useful. We can't
> really pull these fields, but if they're suitably useless/unimportant,
> maybe we should just stick them in our own ontology.
I wonder if Stuart has any ideas on this, given that he's working with
legal data.
>> > 6) An appropriate resolution to the z:accessDate conundrum. While
>> > there seems to be a consensus against adding an accessDate property to
>> > BIBO, I am still a little concerned about the interoperability
>> > implications of hosting this property in the Zotero namespace. I'd
>> > welcome any comments on the issue.
>>
>> I think this sort of thing belongs with the Talis Resource list
>> vocabulary. Nadim or Chris, you guys around to comment on this?
>
> Looking at http://vocab.org/resourcelist/schema, there doesn't seem to
> be any kind of access date property.
I emailed them off-list about this. I doubt they'll object to adding
it (and maybe resource:label for things like bibtex-esque keys).
Bruce
skornblith
I fear that things will get really complicated. As BIBO models things,
it seems like, with the exclusion of relations among items, there is
never an arc into a bibliographic item. In the Music Ontology, there
are arcs both in and out. mo:MusicArtist is at the top of the
hierarchy. mo:composer is supposed to be on mo:Composition, with an
arc into mo:MusicalWork, which has an arc out to mo:Performance, which
has an arc out to mo:Recording. The mo:Recoding, buried five levels
into the hierarchy, is the entity that is actually being cited. I
don't know if there's anything reasonable to do about this, but it
seems excessive for our purposes. We'd need several of blank nodes
with only one property, with arcs in and out of the recording itself.
Because of the hierarchy, the wordsBy creator relation seems
impossible to model properly. Presumably, on most audioRecordings, it
will be the dc:creator of mo:Lyrics. But how do we relate mo:Lyrics to
a recording? mo:Lyrics is in the range of mo:publication_of, which has
in its domain PublishedLyrics, PublishedLibretto, PublishedScore, and
Record. Effectively, it seems that if audioRecording is unpublished,
there can't be lyrics.
Those are my issues with modeling composer and wordsBy. I now realize
I can map guest to po:participant. That leaves attorneyAgent and
scriptwriter with no mapping in any ontology, even though the latter
seems like the kind of thing po should include.
> > The MARC vocabulary is ugly, but it's comprehensive, and some of these
> > seem pretty important. I'd welcome any advice on how to map these
> > without MARC.
>
> MARC is ugly, because in part its totally flat. BIBO isn't,.
[...]
> >> > 6) An appropriate resolution to the z:accessDate conundrum. While
> >> > there seems to be a consensus against adding an accessDate property to
> >> > BIBO, I am still a little concerned about the interoperability
> >> > implications of hosting this property in the Zotero namespace. I'd
> >> > welcome any comments on the issue.
>
> >> I think this sort of thing belongs with the Talis Resource list
> >> vocabulary. Nadim or Chris, you guys around to comment on this?
>
>
> I emailed them off-list about this. I doubt they'll object to adding
> it (and maybe resource:label for things like bibtex-esque keys).
Simon
Bruce D'Arcus
I agree. Was just mentioning it since you did.
> As BIBO models things,
> it seems like, with the exclusion of relations among items, there is
> never an arc into a bibliographic item. In the Music Ontology, there
> are arcs both in and out. mo:MusicArtist is at the top of the
> hierarchy. mo:composer is supposed to be on mo:Composition, with an
> arc into mo:MusicalWork, which has an arc out to mo:Performance, which
> has an arc out to mo:Recording. The mo:Recoding, buried five levels
> into the hierarchy, is the entity that is actually being cited. I
> don't know if there's anything reasonable to do about this, but it
> seems excessive for our purposes. We'd need several of blank nodes
> with only one property, with arcs in and out of the recording itself.
>
> Because of the hierarchy, the wordsBy creator relation seems
> impossible to model properly.
But in BIBO the relations would be simpler (MO explicitly borrows from
FRBR, and adds some additional event modeling that makes it pretty
complex; this is largely why we've so far punted on FRBR integration).
For sake of argument:
<http://ex.org/1> x:recordingOf <http://ex.org/2> . # audio book
<http://ex.org/2> dct:creator <http://ex.org/3> . # text (book)
Bruce
skornblith
Music Ontology types. If we go this route, then I suggest that we add
a Script (movie script or radio/television program script) class.
Simon
Nadeem Shabir
Picked up Bruce's mail to me earlier today which summarized part of the discussion on the group to add a couple of properties to the resource list ontology:
1) something to track when the resource was last accessed.
2) a label, to encode what in bibtex is call a key.
So:
mylist:x a rs:Item ;
rs:accessed "2009-09-12"^^xsd:date ;
rs:label "doe99a" .
Whilst we dont currently have our own use cases for actually storing the last accessed date, I can't see why we couldn't add the property if it supports use cases that others have. However in the above example that Bruce sent, it seems to suggest that you want to add an 'accessed' property to an rs:Item rather than the resource list as a whole. I can see how adding an 'accessed' date property to a list is useful but im less clear about its relevance on an individual item.
Could you guys clarify this please?
Bruce D'Arcus
> Hi everyone
>
>
> Picked up Bruce's mail to me earlier today which summarized part of the
> discussion on the group to add a couple of properties to the resource list
> ontology:
>
>
> 1) something to track when the resource was last accessed.
>
> 2) a label, to encode what in bibtex is call a key.
>
> So:
>
> mylist:x a rs:Item ;
> rs:accessed "2009-09-12"^^xsd:date ;
> rs:label "doe99a" .
>
> Whilst we dont currently have our own use cases for actually storing the
> last accessed date, I can't see why we couldn't add the property if it
> supports use cases that others have. However in the above example that
> Bruce sent, it seems to suggest that you want to add an 'accessed' property
> to an rs:Item rather than the resource list as a whole. I can see how
> adding an 'accessed' date property to a list is useful but im less clear
> about its relevance on an individual item.
>
> Could you guys clarify this please?
Sure.
The use case can really be boiled down to citation practice, where
some styles expect you to include the date of last access.
While it's feasible to imagine this as referring to the last access of
anyone, practically speaking this is really about a characteristic of
the relation between the user and the resource; e.g. the rs:Item.
Aside: one wrinkle here that Simon pointed out is that this is
sometimes used to distinguish versions of web pages. Clearly that use
case is not covered by my suggestion here.
Bruce
Frederick Giasson
> The use case can really be boiled down to citation practice, where
> some styles expect you to include the date of last access.
>
> While it's feasible to imagine this as referring to the last access of
> anyone, practically speaking this is really about a characteristic of
> the relation between the user and the resource; e.g. the rs:Item.
>
> Aside: one wrinkle here that Simon pointed out is that this is
> sometimes used to distinguish versions of web pages. Clearly that use
> case is not covered by my suggestion here.
>
I certainly don't see this usecase as BIBO usecase. This kind of stuff
would be part of an ontology that describe states of systems (access
time, update times, permissions over resources, etc.). In my recent work
with conStruct and structWSF, this kind of information is completely
separated from the description of any resource (and the purpose is
totally different as wel).
Thanks,
Fred
Owen Stephens
'last accessed' date? I would agree that the 'last accessed' property
in the context of a reference/citation (i.e. the Zotero use case, and
also one that I'm interested in) in order to identify a version of the
resource - and that this is related to the 'updated date' (i.e. the
resource has a timespan of existence into which the last accessed date
falls). However in practical terms I'm not sure how we could expect to
record updated dates for the resource we are describing - that's
exactly why the convention is to say when the resource was updated
surely?
Anyway, it looks like on the Zotero/BIBO mapping this is currently
being handled by the z namespace - is this the likely way forward for
now?
Thanks,
Owen
http://www.open.ac.uk/blogs/telstar
Bruce D'Arcus
>
> What (if any) were the outcomes of this discussion in terms of the
> 'last accessed' date? I would agree that the 'last accessed' property
> in the context of a reference/citation (i.e. the Zotero use case, and
> also one that I'm interested in) in order to identify a version of the
> resource - and that this is related to the 'updated date' (i.e. the
> resource has a timespan of existence into which the last accessed date
> falls). However in practical terms I'm not sure how we could expect to
> record updated dates for the resource we are describing - that's
> exactly why the convention is to say when the resource was updated
> surely?
>
> Anyway, it looks like on the Zotero/BIBO mapping this is currently
> being handled by the z namespace - is this the likely way forward for
> now?
I would hope not.
Bruce