document/collection types

classic Classic list List threaded Threaded
27 messages Options
12
Reply | Threaded
Open this post in threaded view
|

document/collection types

Bruce D'Arcus
So I'd like to review the current hierarchy of document and collections
types in the RDF ontology we're working on. Am cross-posting to the
Zotero and OOo bib dev lists. Please send suggestions ASAP (like end of
today).

Note: as I mentioned before, this is really quite hard, as I don't
really think there can be an ontologically pure modeling here, and we
have to be able to deal with often awkward legacy data.

I do think this list needs work though. We've just been focusing on
other details lately.

Also, I think we probably need a literal property that allows people to
give a little more information when the type itself can't convey it.

So this is the hierarchy, with my comments:

Collection
        InternetSite
        Series
        Periodical
                Journal
                Magazine # we might drop this, or add Newspaper
                CourtReporter

# How to deal with multi-volume books?
# I guess could just use generic Collection?

Document
      InternetDocument # I'm convinced we need this as a full type
        Article
        LegalCase # need input from lawyers here; not happy with this
                Brief
                Decision
        Manuscript # I suggest dropping
        Book # do we need a separate class for edited books?
                Proceeding
                Booklet # I HATE this vestige from BibTeX; let's cut it
        Manual
        Legislation # need help here too
        Patent
        Report
                TechnicalReport # is this important?
        Thesis
                Dissertation
        Transcript
                Interview
        Note # maybe it shouldn't be a subclass of Document?
        Law # if we keep, should be subclass of Legislation

So obvious stuff we're missing beyond comments above?

No way to indicate letters, memos, phone conversations, etc. Transcript
might be problematic.

The Zotero guys wanted to treat communication as a separate class. E.g.

Communication
        EMail
        Letter
        Memo
        etc.

Bruce

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: document/collection types

Frederick Giasson
Hi Bruce,

> Also, I think we probably need a literal property that allows people to
> give a little more information when the type itself can't convey it.
>
> So this is the hierarchy, with my comments:
>
> Collection
> InternetSite
> Series
> Periodical
> Journal
> Magazine # we might drop this, or add Newspaper
> CourtReporter
>
>  
Would drop InternetSite as we dropper WebPage.

Would drop Magazine and not adding Newspaper. In fact, the question is:
is there a difference (in terms of descriptiveness) between a newspaper
and a journal? or a magazine and a periodical (some type of restrictions
applied only to that type of collection).

Also, the CourtReporter thing (and all Law documentations related
classes and properties) should be re-thinked, extended and possibly put
in a specialized (Law) extension module to bibo. What you think?


> # How to deal with multi-volume books?
> # I guess could just use generic Collection?
>
> Document
>       InternetDocument # I'm convinced we need this as a full type
>  
What convinced you? (related to our recent discussion on the bibo
mailing list).

> Article
> LegalCase # need input from lawyers here; not happy with this
> Brief
> Decision
>  
As I said above, I would create a module of its own for Law related Things.

> Manuscript # I suggest dropping
>  
Why?

> Book # do we need a separate class for edited books?
>  
Well, since bibo is rooted at the Manifestation (frbr) level, a Book is
not an edited book by definition?

> Proceeding
> Booklet # I HATE this vestige from BibTeX; let's cut it
>  
Let it go then.

> Manual
> Legislation # need help here too
> Patent
> Report
> TechnicalReport # is this important?
>  
Don't think so.

> Thesis
> Dissertation
> Transcript
> Interview
> Note # maybe it shouldn't be a subclass of Document?
>  
Well, good question. What it would be? I think that a Note is a document
by considering that it is a writing of information. And I think that it
should have its own class since it is restricted to a single author.


> So obvious stuff we're missing beyond comments above?
>
> No way to indicate letters, memos, phone conversations, etc. Transcript
> might be problematic.
>
>  

Letters is more problematic. Memos are sort of notes; are they? Phone
conversations are transcripts.

And in what sense Transcript is problematic?

> The Zotero guys wanted to treat communication as a separate class. E.g.
>
> Communication
> EMail
> Letter
> Memo
> etc.
>  

Well, not sure here since all documents have a communication goal. If I
write a book, or if I write this email, in both cases I want to
communicate something. So I am not really sure that its a good way to go.


Take care,


Fred

> Bruce
>
> --~--~---------~--~----~------------~-------~--~----~
> You received this message because you are subscribed to the Google Groups "Bibliographic Ontology Specification Group" group.
> To post to this group, send email to [hidden email]
> To unsubscribe from this group, send email to [hidden email]
> For more options, visit this group at http://groups.google.com/group/bibliographic-ontology-specification-group?hl=en
> -~----------~----~----~----~------~----~------~--~---
>
>  

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: document/collection types

Bruce D'Arcus
Frederick Giasson wrote:

> Hi Bruce,
>
>> Also, I think we probably need a literal property that allows people to
>> give a little more information when the type itself can't convey it.
>>
>> So this is the hierarchy, with my comments:
>>
>> Collection
>> InternetSite
>> Series
>> Periodical
>> Journal
>> Magazine # we might drop this, or add Newspaper
>> CourtReporter
>>
>>  
> Would drop InternetSite as we dropper WebPage.

Am fine with that. So how would we represent a weblog post?

> Would drop Magazine and not adding Newspaper. In fact, the question is:
> is there a difference (in terms of descriptiveness) between a newspaper
> and a journal? or a magazine and a periodical (some type of restrictions
> applied only to that type of collection).

Not really. But the differences are otherwise important (for search,
formatting perhaps, etc.).

> Also, the CourtReporter thing (and all Law documentations related
> classes and properties) should be re-thinked, extended and possibly put
> in a specialized (Law) extension module to bibo. What you think?

I think we need to provide the basics but provide room for extension.
It's just a question of how best to provide those basics.

>> # How to deal with multi-volume books?
>> # I guess could just use generic Collection?
>>
>> Document
>>       InternetDocument # I'm convinced we need this as a full type
>>  
> What convinced you? (related to our recent discussion on the bibo
> mailing list).

Oops, typo. I meant to add "not."

>> Article
>> LegalCase # need input from lawyers here; not happy with this
>> Brief
>> Decision
>>  
> As I said above, I would create a module of its own for Law related Things.
>
>> Manuscript # I suggest dropping
>>  
> Why?

It's just an unpublished document, which may be held in an archive. In
general, I think people who work with manuscripts would agree with me.

Elena, you there?

>> Book # do we need a separate class for edited books?
>>  
> Well, since bibo is rooted at the Manifestation (frbr) level, a Book is
> not an edited book by definition?

I was thinking EditedBook as subclass of Book, though I have no strong
opinion if this is a good idea. Am just asking.

>> Proceeding
>> Booklet # I HATE this vestige from BibTeX; let's cut it
>>  
> Let it go then.
>
>> Manual
>> Legislation # need help here too
>> Patent
>> Report
>> TechnicalReport # is this important?
>>  
> Don't think so.
>
>> Thesis
>> Dissertation
>> Transcript
>> Interview
>> Note # maybe it shouldn't be a subclass of Document?
>>  
> Well, good question. What it would be? I think that a Note is a document
> by considering that it is a writing of information. And I think that it
> should have its own class since it is restricted to a single author.

But from the application angle, a note is really different; something
like a tag in the sense of user-defined annotation of bibliographic
source (documents).

>> So obvious stuff we're missing beyond comments above?
>>
>> No way to indicate letters, memos, phone conversations, etc. Transcript
>> might be problematic.
>>
>>  
>
> Letters is more problematic. Memos are sort of notes; are they? Phone
> conversations are transcripts.

Not really. If I cite a phone conversation, there's no transcript typically.

> And in what sense Transcript is problematic?

It's just that the communication itself might be more significant than
the document characteristic (might be absent).

>> The Zotero guys wanted to treat communication as a separate class. E.g.
>>
>> Communication
>> EMail
>> Letter
>> Memo
>> etc.
>>  
>
> Well, not sure here since all documents have a communication goal. If I
> write a book, or if I write this email, in both cases I want to
> communicate something. So I am not really sure that its a good way to go.

This is indeed the problem.

We could say a Communication involves sender/author and recipient; often
called a PersonalCommunication?

Broadcasts?

Bruce

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: document/collection types

Frederick Giasson
Hi Bruce,

> Am fine with that. So how would we represent a weblog post?
>
>  

As we already discussed, a WebPage is a Document but published with a
certain medium. This said, a WebPage could be a Law Case, an Article, etc.

An InternetSite could be see as a Collection, or an eBook for example.


In any case, the "web documents" should be see with their related types
(law case, article, etc) but that can be located on the web (using their
identifers bibo:uri or bibo:url).

This said, a WebPage or an InternetSite are Documents and Collections.
The only difference is that their identifiers are on the Web (so, people
can locate them on the Web).

Check the nytime example at:
http://wiki.bibliontology.com/index.php/Examples


>> Would drop Magazine and not adding Newspaper. In fact, the question is:
>> is there a difference (in terms of descriptiveness) between a newspaper
>> and a journal? or a magazine and a periodical (some type of restrictions
>> applied only to that type of collection).
>>    
>
> Not really. But the differences are otherwise important (for search,
> formatting perhaps, etc.).
>  
I understand, and its why we add the discussion of: Classes or Individuals?

:)

But as Ivan pointed out, its probably more intuitive to talk abou
rdfs:type than dcterms:type, so we should create these classes.


In that case, let create the bibo:Newspaper class, and keep the other
ones in the ontology.

>> Also, the CourtReporter thing (and all Law documentations related
>> classes and properties) should be re-thinked, extended and possibly put
>> in a specialized (Law) extension module to bibo. What you think?
>>    
>
> I think we need to provide the basics but provide room for extension.
> It's just a question of how best to provide those basics.
>  

Okay, but you should check that to make sure that it is consistent since
I have no knowledge in that domain.

>>> # How to deal with multi-volume books?
>>> # I guess could just use generic Collection?
>>>
>>> Document
>>>       InternetDocument # I'm convinced we need this as a full type
>>>  
>>>      
>> What convinced you? (related to our recent discussion on the bibo
>> mailing list).
>>    
>
> Oops, typo. I meant to add "not."
>  
So lets delete it :)

(naturally, if people agree with what I said above)

>>> Article
>>> LegalCase # need input from lawyers here; not happy with this
>>> Brief
>>> Decision
>>>  
>>>      
>> As I said above, I would create a module of its own for Law related Things.
>>
>>    
>>> Manuscript # I suggest dropping
>>>  
>>>      
>> Why?
>>    
>
> It's just an unpublished document, which may be held in an archive. In
> general, I think people who work with manuscripts would agree with me.
>
> Elena, you there?
>
>  
Okay good; but I think it really depends on the definition here.

Check: http://dictionary.reference.com/browse/manuscript (from american
heritage and Random House Unabridged Dictionary)

One definition is: "a book or document written before the invention of
printing"

So, if we define it that way, it could possibly mean something to have a
class "munuscript".

However, its sure that in all cases, its a document.


>>> Book # do we need a separate class for edited books?
>>>  
>>>      
>> Well, since bibo is rooted at the Manifestation (frbr) level, a Book is
>> not an edited book by definition?
>>    
>
> I was thinking EditedBook as subclass of Book, though I have no strong
> opinion if this is a good idea. Am just asking.
>
>  

Is there a real value in it? In fact, if a bibo:isbn is used to describe
the book, we could certainly conclude that it has been published, no?
So, depending on its identifier(s), we can probably conclude that a book
is published or not.


That way, I won't create such a class in bibo.

>>> Thesis
>>> Dissertation
>>> Transcript
>>> Interview
>>> Note # maybe it shouldn't be a subclass of Document?
>>>  
>>>      
>> Well, good question. What it would be? I think that a Note is a document
>> by considering that it is a writing of information. And I think that it
>> should have its own class since it is restricted to a single author.
>>    
>
> But from the application angle, a note is really different; something
> like a tag in the sense of user-defined annotation of bibliographic
> source (documents).
>  
Yes, but its a document (note) that has a relation with another document
(book), no?

If you want, you can even use dcterms:relation to relate them.


>>> So obvious stuff we're missing beyond comments above?
>>>
>>> No way to indicate letters, memos, phone conversations, etc. Transcript
>>> might be problematic.
>>>
>>>  
>>>      
>> Letters is more problematic. Memos are sort of notes; are they? Phone
>> conversations are transcripts.
>>    
>
> Not really. If I cite a phone conversation, there's no transcript typically.
>  

So its a good question and something to consider.

>> And in what sense Transcript is problematic?
>>    
>
> It's just that the communication itself might be more significant than
> the document characteristic (might be absent).
>  

So, you have an Interview (the thing you site) and a possible related
transcript (the thing that can be abscent).


So, what you site isn't the transcript, but the Interview. This make sense.

However, I think that we should keep Transcript as it is a type of
document that is related to an Interview Event (not sure you will like
that :) ). And then, we should relate the Transcript Document with the
Interview Event.


Makes sense?

>>> The Zotero guys wanted to treat communication as a separate class. E.g.
>>>
>>> Communication
>>> EMail
>>> Letter
>>> Memo
>>> etc.
>>>  
>>>      
>> Well, not sure here since all documents have a communication goal. If I
>> write a book, or if I write this email, in both cases I want to
>> communicate something. So I am not really sure that its a good way to go.
>>    
>
> This is indeed the problem.
>
> We could say a Communication involves sender/author and recipient; often
> called a PersonalCommunication?
>
> Broadcasts?
>  

What change here is the communication channel, and not what is being
communicated (the document's information (that is written)).

An email and a letter are two type documents but with two essential
characteristics:

(1) at least one recipient and (2) at least one sender.

In fact, an email is a letter but with a different communication
channel. And starting to describe an email in term of CC, BCC, etc.;
would be wrong since it would makes us describing the communication
channel (protocol in that case) instead of the document. All-in-all, an
email is a document with at least one recipient and one sender.


A broadcast is the special case when there is more than one recipient.


Take care,


Fred

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: document/collection types

John P. McCaskey
In reply to this post by Bruce D'Arcus
> Book # do we need a separate class for edited books?

In years of using EndNote, I solved many problems by having two distinct
types, Book and Edited Book (= Edited book of essays by multiple authors,
not just a book with an editor). I don't now remember all the difficulties,
only that before I had a clear distinction, life was difficult and
afterwards life was good. I don't think the problems was limitations of
EndNote.

I think the basic semantic difference was that in one the author is primary.
The book is presented with the author as the person primarily responsible.
The book may have had an editor, translator, etc. but they are secondary. In
the second, the editor is the primarily responsible person, even though
there may be several authors.

Maybe you can have just one category, but then you need a flag saying
whether author or editor is primary. I vote for having two categories an
Authored Book (maybe just called Book, but I think Authored Book is better)
and an Edited Book, even though an Authored Book can have editors and an
Edited Book can have authors.

John

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: document/collection types

Bruce D'Arcus
In reply to this post by Frederick Giasson
BTW, on the legal stuff, Marbux has some useful information in the
comments here:

<http://netapps.muohio.edu/blogs/darcusb/darcusb/archives/2006/09/26/reference-types>

Bruce

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Re: document/collection types

James Howison
How would a book review fit into this? Jstor for example makes this a  
separate type, with specific data for a reviewed article etc. One  
could imagine having a collection of reviewed articles.

Yes, one could also just do this in the title field as people gave  
done for years.

I guess that level of metadata is more akin to having a listed of  
cited references than a separate type.

And there's nothing stopping the RDF format from allowing links to  
cited works, perhaps even with citation types, of which a review would  
be one.  If such a link was in the record then special layout rules  
could apply. But this seems to much of an edge case?

I'd also like to see an encouragement for not includng the year in the  
'container' for conference proceedings/presentation.


Speaking of which how would this type  system cover the common  
practice of sing a conference presentation which doesn't publish  
proceedings, and then  making that available via a webpage?

--j

On Jul 30, 2007, at 11:40 AM, Bruce D'Arcus <[hidden email]> wrote:

> BTW, on the legal stuff, Marbux has some useful information in the  
> comments here:
>
> <http://netapps.muohio.edu/blogs/darcusb/darcusb/archives/2006/09/26/reference-types 
> >
>
> Bruce
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Re: document/collection types

Bruce D'Arcus
James Howison wrote:

> How would a book review fit into this?

Good question. I think that's dropped out somewhere.

> Jstor for example makes this a
> separate type, with specific data for a reviewed article etc. One could
> imagine having a collection of reviewed articles.

This is a little tricky. I think if I have a book review in a newspaper,
then perhaps it ought to be typed as both an Article and a Review?

Reviews can be issued in different forms, including broadcast on the radio.

> Yes, one could also just do this in the title field as people gave done
> for years.
>
> I guess that level of metadata is more akin to having a listed of cited
> references than a separate type.

Well, it could instead be a relation, and maybe should be.

<http://ex.net/1> a bibo:Article ;
     bibo:reviewOf <http://ex.net/2> .

That works for me. What do you think?

> And there's nothing stopping the RDF format from allowing links to cited
> works, perhaps even with citation types, of which a review would be
> one.  

Exactly.

> If such a link was in the record then special layout rules could
> apply. But this seems to much of an edge case?
>
> I'd also like to see an encouragement for not includng the year in the
> 'container' for conference proceedings/presentation.
>
>
> Speaking of which how would this type  system cover the common practice
> of sing a conference presentation which doesn't publish proceedings, and
> then  making that available via a webpage?

A conference paper is typically presented at a conference, and may be
published in either a proceeding, or simply directly on the web.

So:

<http://ex.net/1> a bibo:Document ;
     bibo:presentedAt <http://ex.net/2> ; # the conference
     dcterms:isPartOf <http://ex.net/3> . # the proceedings

This might suggest that isPartOf is a bit vague for your purposes. The
Zotero guys suggested instead something like reproducedIn, which is
probably closer.

As for one published straight to the web, I'd do just:

<http://ex.net/1> a bibo:Document ;
     bibo:url <http://ex.net/1> ; # strictly speaking redundant
     bibo:presentedAt <http://ex.net/2> . # the conference

Ivan Herman was wondering if maybe we don't want something like
bibo:ConferenceDocument or some such, and I think that's an open
question indeed.

Bruce

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: document/collection types

Matthias Basler-2
Von: Bruce D\'Arcus <[hidden email]>

> This is a little tricky. I think if I have a book review in a newspaper,
> then perhaps it ought to be typed as both an Article and a Review?
>
> Reviews can be issued in different forms, including broadcast on the
> radio.

Which makes me think ...

... and as a result I strongly suggest to distinguish the MEDIUM (FORMAT) and the CONTENT of a document.

Examples:
- A "book" as a MEDIUM could include different kinds of content, such as a monograph, articles, reviews, transcripts, a diploma thesis or a combination of several such things.
- On the other side a book review as CONTENT could come by different media, such as a book, a journal, a newspaper, radio broadcast, and/or an internet page.

Mixing these two aspects will likely not result in a consistent schema.

What I havn't thought about yet is what this implies technically (i.e. in the bibliographic software and file format).

Just my 2c.
--
Matthias Basler
[hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Re: document/collection types

Bruce D'Arcus
Matthias,

Matthias Basler wrote:

> Von: Bruce D\'Arcus <[hidden email]>
>
>> This is a little tricky. I think if I have a book review in a
>> newspaper, then perhaps it ought to be typed as both an Article and
>> a Review?
>>
>> Reviews can be issued in different forms, including broadcast on
>> the radio.
>
> Which makes me think ...
>
> ... and as a result I strongly suggest to distinguish the MEDIUM
> (FORMAT) and the CONTENT of a document.

We can certainly do that at some level. I don't think, for example, that
  whether a document is encoded as electronic bits and in HTML should in
any way be relevant to its class/type. That can be handled with properties.

But I think the problem here is a) we've got legacy and practical
challenges to deal with, and b) in some cases, it's just not easy to
disentangle the different concepts. In common language, we blur the
concepts all the time. For example, how do we break apart the "content"
and "form" of a basic idea like "journal article"?

> Examples: - A "book" as a MEDIUM could include different kinds of
> content, such as a monograph, articles, reviews, transcripts, a
> diploma thesis or a combination of several such things. - On the
> other side a book review as CONTENT could come by different media,
> such as a book, a journal, a newspaper, radio broadcast, and/or an
> internet page.
>
> Mixing these two aspects will likely not result in a consistent
> schema.
>
> What I havn't thought about yet is what this implies technically
> (i.e. in the bibliographic software and file format).

What we're dealing with right now is the RDF classes. A resource may be
typed with one or more of these classes, which facilitates querying and
so forth in RDF. It will also be used to map to formatting.

Bruce

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Re: document/collection types

Frederick Giasson
In reply to this post by Bruce D'Arcus
Hi all,

>> How would a book review fit into this?
>>    
>
> Good question. I think that's dropped out somewhere.
>
>  

Well, a book review is a document of its own, however, its distinction
is in its "relation" with the reviewed document.

>> Jstor for example makes this a
>> separate type, with specific data for a reviewed article etc. One could
>> imagine having a collection of reviewed articles.
>>    
>
> This is a little tricky. I think if I have a book review in a newspaper,
> then perhaps it ought to be typed as both an Article and a Review?
>
> Reviews can be issued in different forms, including broadcast on the radio.
>
>  

I would only describe document review and leave the radio or whatever
the medium used to other ontologies. In fact, bibo is rooted at the
document manifestation level.

In fact, the Work that created a bibo:Document can be used to create a
radio program Manifestation of the Work; however bibo shouldn't care
about such manifestations...

>> Yes, one could also just do this in the title field as people gave done
>> for years.
>>
>> I guess that level of metadata is more akin to having a listed of cited
>> references than a separate type.
>>    
>
> Well, it could instead be a relation, and maybe should be.
>
> <http://ex.net/1> a bibo:Article ;
>      bibo:reviewOf <http://ex.net/2> .
>
> That works for me. What do you think?
>  
Yeah, its exactly what I said with: " its distinction is in its
"relation" with the reviewed document.

bibo:reviewOf would be a sub property of dcterms:relation. So, a
specialized relation between two documents.

Does this make sense?

>> If such a link was in the record then special layout rules could
>> apply. But this seems to much of an edge case?
>>
>> I'd also like to see an encouragement for not includng the year in the
>> 'container' for conference proceedings/presentation.
>>
>>
>> Speaking of which how would this type  system cover the common practice
>> of sing a conference presentation which doesn't publish proceedings, and
>> then  making that available via a webpage?
>>    
>
> A conference paper is typically presented at a conference, and may be
> published in either a proceeding, or simply directly on the web.
>
> So:
>
> <http://ex.net/1> a bibo:Document ;
>      bibo:presentedAt <http://ex.net/2> ; # the conference
>      dcterms:isPartOf <http://ex.net/3> . # the proceedings
>
> This might suggest that isPartOf is a bit vague for your purposes. The
> Zotero guys suggested instead something like reproducedIn, which is
> probably closer.
>
> As for one published straight to the web, I'd do just:
>
> <http://ex.net/1> a bibo:Document ;
>      bibo:url <http://ex.net/1> ; # strictly speaking redundant
>      bibo:presentedAt <http://ex.net/2> . # the conference
>  

Exact. To make the distinction between a "web" proceeding or a
"physical: (hardcover, paperback, etc) proceeding, you have to take a
look at its identifier (bibo:identifier). From it, you will know what is
the medium used to publish (make available) the proceeding.

As I explained on another thread, we shouldn't care about "online
(virtual)" and "physical" manifestations of such documents.

> Ivan Herman was wondering if maybe we don't want something like
> bibo:ConferenceDocument or some such, and I think that's an open
> question indeed.
>  

Could do that. Dunno if it worth it.


Take care,


Fred


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Re: document/collection types

Frederick Giasson
In reply to this post by Bruce D'Arcus
Hi,

>>> This is a little tricky. I think if I have a book review in a
>>> newspaper, then perhaps it ought to be typed as both an Article and
>>> a Review?
>>>
>>> Reviews can be issued in different forms, including broadcast on
>>> the radio.
>>>      
>> Which makes me think ...
>>
>> ... and as a result I strongly suggest to distinguish the MEDIUM
>> (FORMAT) and the CONTENT of a document.
>>    
>
> We can certainly do that at some level. I don't think, for example, that
>   whether a document is encoded as electronic bits and in HTML should in
> any way be relevant to its class/type. That can be handled with properties.
>
>  
As I said to times today: this should be inferred with the
bibo:identifier and has nothing to do with the class/type.

> But I think the problem here is a) we've got legacy and practical
> challenges to deal with, and b) in some cases, it's just not easy to
> disentangle the different concepts. In common language, we blur the
> concepts all the time. For example, how do we break apart the "content"
> and "form" of a basic idea like "journal article"?
>  

The content is seen as the document itself. And the medium can be
inferred via their identifiers.

However, would it worth it to specify the medium used to communicate a
document?

And then, when you talk abou MEDIUM, you talk about the communication
channel used to publish (communicate) a document?

Or about a FORMAT as en encoding methodology?

Its clearly two different things.


Nowadays, a web page composed of html, javascript, flash, and other
technologies. So, is a web document only in HTML? Should we then
describes all the technologies (the ones that produce the web document)
used to generate the web document?

I have some doubts here.

>> Examples: - A "book" as a MEDIUM could include different kinds of
>> content, such as a monograph, articles, reviews, transcripts, a
>> diploma thesis or a combination of several such things. - On the
>> other side a book review as CONTENT could come by different media,
>> such as a book, a journal, a newspaper, radio broadcast, and/or an
>> internet page.
>>
>> Mixing these two aspects will likely not result in a consistent
>> schema.
>>
>> What I havn't thought about yet is what this implies technically
>> (i.e. in the bibliographic software and file format).
>>    
Yup, you are right.

But by using a property to relate a document that review another
document, then you can describe these distinctions:

you can have a review that is a Book, and article or a web page. These
reviews can review other books, articles or webpages. What matter here,
is the "review" property, so, to relate one of the document with the
document(s) it reviews via the bibo:reviewOf property.

"Review" is not a type of document, "review" is a property of a document :)



Take care,


Fred

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: document/collection types

Matthias Steffens
In reply to this post by Bruce D'Arcus
On 30-Jul-07 at 10:00 -0400 Bruce D'Arcus wrote:

> So this is the hierarchy, with my comments:
>
> Collection
> InternetSite
> Series
> Periodical
> Journal
> Magazine # we might drop this, or add Newspaper

I'd favour keeping both Magazine and Newspaper, since a citation of
a Magazine or Newspaper article may require different formatting
than, say, an journal article.

Speaking of collections, how would one deal with
Conference/Proceedings volumes? Isn't this a collection as well?

> Document
>       InternetDocument # I'm [not] convinced we need this as a
>       full type

I agree, especially when one considers that in the future a thesis
or a report (or whatever) may be published online exclusively. So I
think that I'd prefer to have a universal property such as
"OnlinePublication" or the like.

> Article
> LegalCase # need input from lawyers here; not happy with this
> Brief
> Decision
> Manuscript # I suggest dropping

In any case, there should be a way to explicitly state that a
document is "unpublished". Maybe a property "PublicationStatus" will
do? This would also have the benefit of stating other publication
status types explicitly.

> Book # do we need a separate class for edited books?

I'm with John McCaskey here. IMHO, edited books don't need a
separate type (it's a book after all), but as John notes, it needs
"a flag saying whether author or editor is primary".

> Proceeding
> Booklet # I HATE this vestige from BibTeX; let's cut it

Are there any cases where a booklet (i.e. a printed book w/o a named
publisher or sponsoring institution) is formatted differently than a
book?

> Manual
> Legislation # need help here too
> Patent
> Report
> TechnicalReport # is this important?

I'd say a TechnicalReport is just a Report but I may be missing
something obvious.

> Thesis
> Dissertation

IMHO, the different types of theses should be indicated via a
property or the like. This is especially since there are more thesis
types than just Dissertation and Master's thesis, e.g. in Germany we
still have Diploma thesis (which is similar but *not* identical to
Master's thesis), and there's a Habilitation thesis. Also, a german
Doctoral thesis is similar but not identical to a Ph.D. thesis. So
I'd rather like to have a property here as well.

> Transcript
> Interview
> Note # maybe it shouldn't be a subclass of Document?

I don't think a note needs to have it's own subclass under Document.
I mean a note is just an unpublished document, isn't it?

But I'd agree with your statement (from another email in this
thread):

> But from the application angle, a note is really different;
> something like a tag in the sense of user-defined annotation of
> bibliographic source (documents).


> The Zotero guys wanted to treat communication as a separate class.
> E.g.
>
> Communication
> EMail
> Letter
> Memo
> etc.

I like this for the reason you've given in another mail:

> We could say a Communication involves sender/author and recipient;
> often called a PersonalCommunication?

And speaking of Broadcasts (Radio, Television, Podcast), these are
public (i.e. not personal) communication forms with many recipients,
right? But OTOH books (or web sites) would also fit into that
description, so the difference is more about the communication
medium (printed vs. broadcasted).

Anyways, for practical reasons, I like distinguishing resources as
Documents, Communication, and Broadcast.

Matthias
_____________________________________
Matthias Steffens     [hidden email]
       http://www.extracts.de

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Re: document/collection types

Leonard Mada-2
In reply to this post by Bruce D'Arcus
Hi,

without having understood all the comments, let me emphasize some little
points which have been probably overlooked.

Basically, as pointed in another post, the collections seem to admix
medium with document type.

Regarding document type, there are broadly 2 large categories of
documents, and therefore I am strongly against some of the droppibngs:

A. Peer-Reviewed Documents
B. NON-Peer-Reviewed Documents

So, you cannot mix everything in the article category, there are really
different things:

A. Peer-Reviewed
=============
This is basically the article and many more standard documents.


B. NON-Peer-Reviewed
=================
[Some structure is still needed as I mix medium with document type, too.]
1. Book
2. Periodicals
   2.1.Newspaper article (else like an article)
   2.2. Non-peer reviewed journal article (else like an article) or Magazine
   2.2'. Exclusively Online Journal (non-peer reviewed)
3. Internet page (NOT really like an article)
[some peer-reviewed articles are published exclusively on the net, BUT
those do NOT fit in this category]
4. Letter (true letter)
5. Personal communication [includes  phone/ whatever communication]
6. many other types
   6.1 Manuscript
7. Specialized Types
   7.1 Court / Law
   7.2 Patents

QUESTION
=========
Should 'Book'also be split into more categories:
a.) non-peer reviewed book (e.g. a novel, single author, whatever else)
b.) speciality book with an editor => therefore peer-reviewed
c.) anything else NOT easily fitting in the previous 2 categories

I will think more thoroughly about the problem tomorrow. Though,
recognising the 2 main categories, aka *peer-reviewed* vs *non
peer-reviewed*, is critical because every scientist will put so much
different weight  into these different types of evidence.

Sincerely,

Leonard


Bruce D'Arcus wrote:

> Frederick Giasson wrote:
>> Hi Bruce,
>>
>>> Also, I think we probably need a literal property that allows people
>>> to give a little more information when the type itself can't convey it.
>>>
>>> So this is the hierarchy, with my comments:
>>>
>>> Collection
>>>     InternetSite
>>>     Series
>>>     Periodical
>>>         Journal
>>>         Magazine # we might drop this, or add Newspaper
>>>         CourtReporter
>>>
>>>  
>> Would drop InternetSite as we dropper WebPage.
>
> Am fine with that. So how would we represent a weblog post?
>
>> Would drop Magazine and not adding Newspaper. In fact, the question
>> is: is there a difference (in terms of descriptiveness) between a
>> newspaper and a journal? or a magazine and a periodical (some type of
>> restrictions applied only to that type of collection).
>
> Not really. But the differences are otherwise important (for search,
> formatting perhaps, etc.).
>
>> Also, the CourtReporter thing (and all Law documentations related
>> classes and properties) should be re-thinked, extended and possibly
>> put in a specialized (Law) extension module to bibo. What you think?
>
> I think we need to provide the basics but provide room for extension.
> It's just a question of how best to provide those basics.
>
>>> # How to deal with multi-volume books?
>>> # I guess could just use generic Collection?
>>>
>>> Document
>>>           InternetDocument # I'm convinced we need this as a full type
>>>  
>> What convinced you? (related to our recent discussion on the bibo
>> mailing list).
>
> Oops, typo. I meant to add "not."
>
>>>     Article
>>>     LegalCase # need input from lawyers here; not happy with this
>>>         Brief
>>>         Decision
>>>  
>> As I said above, I would create a module of its own for Law related
>> Things.
>>
>>>     Manuscript # I suggest dropping
>>>  
>> Why?
>
> It's just an unpublished document, which may be held in an archive. In
> general, I think people who work with manuscripts would agree with me.
>
> Elena, you there?
>
>>>     Book # do we need a separate class for edited books?
>>>  
>> Well, since bibo is rooted at the Manifestation (frbr) level, a Book
>> is not an edited book by definition?
>
> I was thinking EditedBook as subclass of Book, though I have no strong
> opinion if this is a good idea. Am just asking.
>
>>>         Proceeding
>>>         Booklet # I HATE this vestige from BibTeX; let's cut it
>>>  
>> Let it go then.
>>
>>>     Manual
>>>     Legislation # need help here too
>>>     Patent
>>>     Report
>>>         TechnicalReport # is this important?
>>>  
>> Don't think so.
>>
>>>     Thesis
>>>         Dissertation
>>>     Transcript
>>>         Interview
>>>     Note # maybe it shouldn't be a subclass of Document?
>>>  
>> Well, good question. What it would be? I think that a Note is a
>> document by considering that it is a writing of information. And I
>> think that it should have its own class since it is restricted to a
>> single author.
>
> But from the application angle, a note is really different; something
> like a tag in the sense of user-defined annotation of bibliographic
> source (documents).
>
>>> So obvious stuff we're missing beyond comments above?
>>>
>>> No way to indicate letters, memos, phone conversations, etc.
>>> Transcript might be problematic.
>>>
>>>  
>>
>> Letters is more problematic. Memos are sort of notes; are they? Phone
>> conversations are transcripts.
>
> Not really. If I cite a phone conversation, there's no transcript
> typically.
>
>> And in what sense Transcript is problematic?
>
> It's just that the communication itself might be more significant than
> the document characteristic (might be absent).
>
>>> The Zotero guys wanted to treat communication as a separate class. E.g.
>>>
>>> Communication
>>>     EMail
>>>     Letter
>>>     Memo
>>>     etc.
>>>  
>>
>> Well, not sure here since all documents have a communication goal. If
>> I write a book, or if I write this email, in both cases I want to
>> communicate something. So I am not really sure that its a good way to
>> go.
>
> This is indeed the problem.
>
> We could say a Communication involves sender/author and recipient;
> often called a PersonalCommunication?
>
> Broadcasts?
>
> Bruce
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: document/collection types

Gannon Dick
In reply to this post by Bruce D'Arcus
Sorry, I'm not somewhere I can look this up quickly ...

There are attributes in this DTD for sources, journal, conference etc.

http://dtd.nlm.nih.gov/2.0/index.html

This might be helpful too.  It was the gold standard and still has a
fair amount of patina. http://www.diglib.org/preserve/hadtdfs.pdf

--Gannon
--- Bruce D'Arcus <[hidden email]> wrote:

> So I'd like to review the current hierarchy of document and
> collections
> types in the RDF ontology we're working on. Am cross-posting to the
> Zotero and OOo bib dev lists. Please send suggestions ASAP (like end
> of
> today).
>
> Note: as I mentioned before, this is really quite hard, as I don't
> really think there can be an ontologically pure modeling here, and we
>
> have to be able to deal with often awkward legacy data.
>
> I do think this list needs work though. We've just been focusing on
> other details lately.
>
> Also, I think we probably need a literal property that allows people
> to
> give a little more information when the type itself can't convey it.
>
> So this is the hierarchy, with my comments:
>
> Collection
> InternetSite
> Series
> Periodical
> Journal
> Magazine # we might drop this, or add Newspaper
> CourtReporter
>
> # How to deal with multi-volume books?
> # I guess could just use generic Collection?
>
> Document
>       InternetDocument # I'm convinced we need this as a full type
> Article
> LegalCase # need input from lawyers here; not happy with this
> Brief
> Decision
> Manuscript # I suggest dropping
> Book # do we need a separate class for edited books?
> Proceeding
> Booklet # I HATE this vestige from BibTeX; let's cut it
> Manual
> Legislation # need help here too
> Patent
> Report
> TechnicalReport # is this important?
> Thesis
> Dissertation
> Transcript
> Interview
> Note # maybe it shouldn't be a subclass of Document?
> Law # if we keep, should be subclass of Legislation
>
> So obvious stuff we're missing beyond comments above?
>
> No way to indicate letters, memos, phone conversations, etc.
> Transcript
> might be problematic.
>
> The Zotero guys wanted to treat communication as a separate class.
> E.g.
>
> Communication
> EMail
> Letter
> Memo
> etc.
>
> Bruce
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail:
> [hidden email]
>
>



       
____________________________________________________________________________________
Be a better Globetrotter. Get better travel answers from someone who knows. Yahoo! Answers - Check it out.
http://answers.yahoo.com/dir/?link=list&sid=396545469

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Re: document/collection types

Bruce D'Arcus
In reply to this post by Leonard Mada-2
Leonard Mada wrote:

...

> Regarding document type, there are broadly 2 large categories of
> documents, and therefore I am strongly against some of the droppibngs:
>
> A. Peer-Reviewed Documents
> B. NON-Peer-Reviewed Documents
>
> So, you cannot mix everything in the article category, there are really
> different things:

This is an interesting argument, though I'm not sure I agree with you
entirely.

> A. Peer-Reviewed
> =============
> This is basically the article and many more standard documents.

Books are often peer-reviewed also, as are conference presentations (you
submit an abstract and can only present if approved by a committee).
This suggests it's a property rather than a type.

> B. NON-Peer-Reviewed
> =================
> [Some structure is still needed as I mix medium with document type, too.]
> 1. Book

As above. Moreover, we often can't know that one book is peer-reviewed
and another not without doing some research into the publication
process. This is the same for journal article metadata; information
about review is typically not available.

> 2. Periodicals
>   2.1.Newspaper article (else like an article)
>   2.2. Non-peer reviewed journal article (else like an article) or Magazine

So why not just call this a generic Document?

>   2.2'. Exclusively Online Journal (non-peer reviewed)

It's still a Journal, and some of them are peer-reviewed. Indeed, I have
done many reviews for one exclusively online journal. Seems easier to
just call it a Journal.

> 3. Internet page (NOT really like an article)

Document. I am talking at the level, BTW, of the RDF model, not
necessarily what you see in your application.

> [some peer-reviewed articles are published exclusively on the net, BUT
> those do NOT fit in this category]
> 4. Letter (true letter)

Which is what; something on paper?

> 5. Personal communication [includes  phone/ whatever communication]
> 6. many other types
>   6.1 Manuscript
> 7. Specialized Types
>   7.1 Court / Law
>   7.2 Patents
>
> QUESTION
> =========
> Should 'Book'also be split into more categories:
> a.) non-peer reviewed book (e.g. a novel, single author, whatever else)
> b.) speciality book with an editor => therefore peer-reviewed
> c.) anything else NOT easily fitting in the previous 2 categories
>
> I will think more thoroughly about the problem tomorrow. Though,
> recognising the 2 main categories, aka *peer-reviewed* vs *non
> peer-reviewed*, is critical because every scientist will put so much
> different weight  into these different types of evidence.

This is where we get to the crux of the matter; how do we encode the
metadata in such a way so that we can assess rigor?

On my tenure application, I have to list peer-reviewed vs.
non-peer-reviewed publications. But that alone isn't enough to get my
tenure approved. I also have to include evidence about the general
quality of the journals I publish in.

So I think we can gauge that information by knowing we have an article
published in a journal. What is essential is the Journal.

We can also do it with some property if necessary; maybe reusing our
status property. See for example:

<http://www.ukoln.ac.uk/repositories/digirep/index/EPrints_Application_Profile#Status>

Bruce

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Re: document/collection types

Gannon Dick
In reply to this post by Leonard Mada-2
Had to put my 2 cents here ...

Leonard, very good point but might it be better to use Evidence Basis
(ala' Evidence Based Medicine, Evidence Based Health Care, Evidence
Based Librarianship, etc.) as a Property of the resource no matter what
form or source the resource takes ?
--- Leonard Mada <[hidden email]> wrote:

> Hi,
>
> without having understood all the comments, let me emphasize some
> little
> points which have been probably overlooked.
>
> Basically, as pointed in another post, the collections seem to admix
> medium with document type.
>
> Regarding document type, there are broadly 2 large categories of
> documents, and therefore I am strongly against some of the
> droppibngs:
>
> A. Peer-Reviewed Documents
> B. NON-Peer-Reviewed Documents
>
> So, you cannot mix everything in the article category, there are
> really
> different things:
>
> A. Peer-Reviewed
> =============
> This is basically the article and many more standard documents.
>
>
> B. NON-Peer-Reviewed
> =================
> [Some structure is still needed as I mix medium with document type,
> too.]
> 1. Book
> 2. Periodicals
>    2.1.Newspaper article (else like an article)
>    2.2. Non-peer reviewed journal article (else like an article) or
> Magazine
>    2.2'. Exclusively Online Journal (non-peer reviewed)
> 3. Internet page (NOT really like an article)
> [some peer-reviewed articles are published exclusively on the net,
> BUT
> those do NOT fit in this category]
> 4. Letter (true letter)
> 5. Personal communication [includes  phone/ whatever communication]
> 6. many other types
>    6.1 Manuscript
> 7. Specialized Types
>    7.1 Court / Law
>    7.2 Patents
>
> QUESTION
> =========
> Should 'Book'also be split into more categories:
> a.) non-peer reviewed book (e.g. a novel, single author, whatever
> else)
> b.) speciality book with an editor => therefore peer-reviewed
> c.) anything else NOT easily fitting in the previous 2 categories
>
> I will think more thoroughly about the problem tomorrow. Though,
> recognising the 2 main categories, aka *peer-reviewed* vs *non
> peer-reviewed*, is critical because every scientist will put so much
> different weight  into these different types of evidence.
>
> Sincerely,
>
> Leonard
>
>
> Bruce D'Arcus wrote:
> > Frederick Giasson wrote:
> >> Hi Bruce,
> >>
> >>> Also, I think we probably need a literal property that allows
> people
> >>> to give a little more information when the type itself can't
> convey it.
> >>>
> >>> So this is the hierarchy, with my comments:
> >>>
> >>> Collection
> >>>     InternetSite
> >>>     Series
> >>>     Periodical
> >>>         Journal
> >>>         Magazine # we might drop this, or add Newspaper
> >>>         CourtReporter
> >>>
> >>>  
> >> Would drop InternetSite as we dropper WebPage.
> >
> > Am fine with that. So how would we represent a weblog post?
> >
> >> Would drop Magazine and not adding Newspaper. In fact, the
> question
> >> is: is there a difference (in terms of descriptiveness) between a
> >> newspaper and a journal? or a magazine and a periodical (some type
> of
> >> restrictions applied only to that type of collection).
> >
> > Not really. But the differences are otherwise important (for
> search,
> > formatting perhaps, etc.).
> >
> >> Also, the CourtReporter thing (and all Law documentations related
> >> classes and properties) should be re-thinked, extended and
> possibly
> >> put in a specialized (Law) extension module to bibo. What you
> think?
> >
> > I think we need to provide the basics but provide room for
> extension.
> > It's just a question of how best to provide those basics.
> >
> >>> # How to deal with multi-volume books?
> >>> # I guess could just use generic Collection?
> >>>
> >>> Document
> >>>           InternetDocument # I'm convinced we need this as a full
> type
> >>>  
> >> What convinced you? (related to our recent discussion on the bibo
> >> mailing list).
> >
> > Oops, typo. I meant to add "not."
> >
> >>>     Article
> >>>     LegalCase # need input from lawyers here; not happy with this
> >>>         Brief
> >>>         Decision
> >>>  
> >> As I said above, I would create a module of its own for Law
> related
> >> Things.
> >>
> >>>     Manuscript # I suggest dropping
> >>>  
> >> Why?
> >
> > It's just an unpublished document, which may be held in an archive.
> In
> > general, I think people who work with manuscripts would agree with
> me.
> >
> > Elena, you there?
> >
> >>>     Book # do we need a separate class for edited books?
> >>>  
> >> Well, since bibo is rooted at the Manifestation (frbr) level, a
> Book
> >> is not an edited book by definition?
> >
> > I was thinking EditedBook as subclass of Book, though I have no
> strong
> > opinion if this is a good idea. Am just asking.
> >
> >>>         Proceeding
> >>>         Booklet # I HATE this vestige from BibTeX; let's cut it
> >>>  
> >> Let it go then.
> >>
> >>>     Manual
> >>>     Legislation # need help here too
> >>>     Patent
> >>>     Report
> >>>         TechnicalReport # is this important?
> >>>  
> >> Don't think so.
> >>
> >>>     Thesis
> >>>         Dissertation
> >>>     Transcript
> >>>         Interview
> >>>     Note # maybe it shouldn't be a subclass of Document?
> >>>  
> >> Well, good question. What it would be? I think that a Note is a
> >> document by considering that it is a writing of information. And I
>
> >> think that it should have its own class since it is restricted to
> a
> >> single author.
> >
> > But from the application angle, a note is really different;
> something
> > like a tag in the sense of user-defined annotation of bibliographic
>
> > source (documents).
> >
> >>> So obvious stuff we're missing beyond comments above?
> >>>
> >>> No way to indicate letters, memos, phone conversations, etc.
> >>> Transcript might be problematic.
> >>>
> >>>  
> >>
> >> Letters is more problematic. Memos are sort of notes; are they?
> Phone
> >> conversations are transcripts.
> >
> > Not really. If I cite a phone conversation, there's no transcript
> > typically.
> >
> >> And in what sense Transcript is problematic?
> >
> > It's just that the communication itself might be more significant
> than
=== message truncated ===



       
____________________________________________________________________________________
Be a better Heartthrob. Get better relationship answers from someone who knows. Yahoo! Answers - Check it out.
http://answers.yahoo.com/dir/?link=list&sid=396545433

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Re: document/collection types

Frederick Giasson
In reply to this post by Bruce D'Arcus
Hi Leonard,

This is a really interesting usecase, indeed!


Okay, so here is how I would attack the problem.


First, we should not think about peer-reviewed documents as a spacial
*type* of document. In fact, peer-reviewing is an action.

So, someone reviewing a Document make it a reviewed document.

How to know if a document is reviewed? By checking if it is related by
some review relations.


So, if I (the Agent) review a Document, I will most than likely write
something about it (a mail, an article and probably even a book). So,
this Document I authored is related to this other Document and the
relation between the two is one of "review".

Its why Bruce suggested the property bibo:reviewOf as the review
property between two documents.


So, a Document X could be reviewed by many documents Y (a Note, a
Letter, a Book, etc). Each of these Y document have their own type, and
all have a bibo:reviewOf relations to the Document X.


So, we can infer that a Document X is "peer-reviewed" if we have at
least one bibo:reviewOf that point to it. Also, we can even think about
a "level" of peer-reviewing by calculating the number of bibo:reviewOf
links to link to the document X. So, is a Document X highly or lowly
reviewed?

This is even more powerful than typing a document as "peer-reviewed"
since we can compute some degree of peer-reviewing by analyzing the
network of relationship of a Document entity.

So, what I am suggesting is not to type a Document as a peer-reviewed or
non-peer-reviewed document. This should be inferred by properties; so
found by analyzing the graph(network) of relationships of a Document
with other Documents.


Does this make sense for you?


Take care,


Fred



>> Regarding document type, there are broadly 2 large categories of
>> documents, and therefore I am strongly against some of the droppibngs:
>>
>> A. Peer-Reviewed Documents
>> B. NON-Peer-Reviewed Documents
>>
>> So, you cannot mix everything in the article category, there are really
>> different things:
>>    
>
> This is an interesting argument, though I'm not sure I agree with you
> entirely.
>
>  
>> A. Peer-Reviewed
>> =============
>> This is basically the article and many more standard documents.
>>    
>
> Books are often peer-reviewed also, as are conference presentations (you
> submit an abstract and can only present if approved by a committee).
> This suggests it's a property rather than a type.
>
>  
>> B. NON-Peer-Reviewed
>> =================
>> [Some structure is still needed as I mix medium with document type, too.]
>> 1. Book
>>    
>
> As above. Moreover, we often can't know that one book is peer-reviewed
> and another not without doing some research into the publication
> process. This is the same for journal article metadata; information
> about review is typically not available.
>
>  
>> 2. Periodicals
>>   2.1.Newspaper article (else like an article)
>>   2.2. Non-peer reviewed journal article (else like an article) or Magazine
>>    
>
> So why not just call this a generic Document?
>
>  
>>   2.2'. Exclusively Online Journal (non-peer reviewed)
>>    
>
> It's still a Journal, and some of them are peer-reviewed. Indeed, I have
> done many reviews for one exclusively online journal. Seems easier to
> just call it a Journal.
>
>  
>> 3. Internet page (NOT really like an article)
>>    
>
> Document. I am talking at the level, BTW, of the RDF model, not
> necessarily what you see in your application.
>
>  
>> [some peer-reviewed articles are published exclusively on the net, BUT
>> those do NOT fit in this category]
>> 4. Letter (true letter)
>>    
>
> Which is what; something on paper?
>
>  
>> 5. Personal communication [includes  phone/ whatever communication]
>> 6. many other types
>>   6.1 Manuscript
>> 7. Specialized Types
>>   7.1 Court / Law
>>   7.2 Patents
>>
>> QUESTION
>> =========
>> Should 'Book'also be split into more categories:
>> a.) non-peer reviewed book (e.g. a novel, single author, whatever else)
>> b.) speciality book with an editor => therefore peer-reviewed
>> c.) anything else NOT easily fitting in the previous 2 categories
>>
>> I will think more thoroughly about the problem tomorrow. Though,
>> recognising the 2 main categories, aka *peer-reviewed* vs *non
>> peer-reviewed*, is critical because every scientist will put so much
>> different weight  into these different types of evidence.
>>    
>
> This is where we get to the crux of the matter; how do we encode the
> metadata in such a way so that we can assess rigor?
>
> On my tenure application, I have to list peer-reviewed vs.
> non-peer-reviewed publications. But that alone isn't enough to get my
> tenure approved. I also have to include evidence about the general
> quality of the journals I publish in.
>
> So I think we can gauge that information by knowing we have an article
> published in a journal. What is essential is the Journal.
>
> We can also do it with some property if necessary; maybe reusing our
> status property. See for example:
>
> <http://www.ukoln.ac.uk/repositories/digirep/index/EPrints_Application_Profile#Status>
>
> Bruce
>
>
> --~--~---------~--~----~------------~-------~--~----~
> You received this message because you are subscribed to the Google Groups "Bibliographic Ontology Specification Group" group.
> To post to this group, send email to [hidden email]
> To unsubscribe from this group, send email to [hidden email]
> For more options, visit this group at http://groups.google.com/group/bibliographic-ontology-specification-group?hl=en
> -~----------~----~----~----~------~----~------~--~---
>
>  

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Re: document/collection types

Bruce D'Arcus
Frederick Giasson wrote:

> How to know if a document is reviewed? By checking if it is related by
> some review relations.
>  
> So, if I (the Agent) review a Document, I will most than likely write
> something about it (a mail, an article and probably even a book). So,
> this Document I authored is related to this other Document and the
> relation between the two is one of "review".
>
> Its why Bruce suggested the property bibo:reviewOf as the review
> property between two documents.
>
> So, a Document X could be reviewed by many documents Y (a Note, a
> Letter, a Book, etc). Each of these Y document have their own type, and
> all have a bibo:reviewOf relations to the Document X.
>
> So, we can infer that a Document X is "peer-reviewed" if we have at
> least one bibo:reviewOf that point to it.

Not really. Peer-review is really a different kind of "action" (to use
your word) than published reviews.

For one, it is typically (almost exclusively; like 99.99% of the time)
private and anonymous. If I review an article manuscript, my comments do
not get published, and the author does not know who I am. The only
people who will ever see the comments are the author (who will in fact
only see *some* of them; that which I allow them to see) and the editor.

Now, in the future at some point (maybe in 20 or 30 years given how
conservative academia is?) we might see the move to what you describe.
But we're nowhere near that now.

I prefer treating this as a specific kind of status, like how the
eprints work models it.

Bruce

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Re: document/collection types

Frederick Giasson
Hi Bruce,

>> How to know if a document is reviewed? By checking if it is related by
>> some review relations.
>>  
>> So, if I (the Agent) review a Document, I will most than likely write
>> something about it (a mail, an article and probably even a book). So,
>> this Document I authored is related to this other Document and the
>> relation between the two is one of "review".
>>
>> Its why Bruce suggested the property bibo:reviewOf as the review
>> property between two documents.
>>
>> So, a Document X could be reviewed by many documents Y (a Note, a
>> Letter, a Book, etc). Each of these Y document have their own type, and
>> all have a bibo:reviewOf relations to the Document X.
>>
>> So, we can infer that a Document X is "peer-reviewed" if we have at
>> least one bibo:reviewOf that point to it.
>>    
>
> Not really. Peer-review is really a different kind of "action" (to use
> your word) than published reviews.
>
> For one, it is typically (almost exclusively; like 99.99% of the time)
> private and anonymous. If I review an article manuscript, my comments do
> not get published, and the author does not know who I am. The only
> people who will ever see the comments are the author (who will in fact
> only see *some* of them; that which I allow them to see) and the editor.
>
>  
Hooo, okay, you are talking about this peer-reviewing procedure :)

> Now, in the future at some point (maybe in 20 or 30 years given how
> conservative academia is?) we might see the move to what you describe.
> But we're nowhere near that now.
>
> I prefer treating this as a specific kind of status, like how the
> eprints work models it.
>  
Yeah sure, in that case, it certainly a good way to go.

So, a document could have more than one status, and one of them could be
bibo_status:peerReviewed. Is it what you have in mind?

But the description of such a status should be well defined to make sure
that it reflects exactly the discussion we had here.


However, this doesn't remove the case that we can, in some case, infer
that a document is peer-reviewed by checking the reviewOf properties
linking to a document entity.

Bruce: should we add the property now that I think it is an essential one?




take care,


Fred

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

12