The main, quite big, issue is there's a whole lot of needless blank
nodes. Example:
<file:///home/bdarcus/Data/zlibrary.rdf#item_10>
res:resource
<http://journals.ohiolink.edu/ejc/article.cgi?issn=00045608&issue=v95i0002&article=294_tpogpibcuas>
;
a z:UserItem ;
z:accessDate "2008-02-07 16:18:08" .
Also, on z:accessDate: a) did the Resource List ontology not add
something such a property?, and b) is the correct data-type value
(xsd:date-time)?
Again, a blank node for critical data:
<file:///home/bdarcus/Data/zlibrary.rdf#item_107>
res:resource [
dcterms:creator _:n710 ;
dcterms:isPartOf [
dcterms:date "1998" ;
dcterms:isPartOf [
dcterms:title "Review of International Political Economy" ;
a bibo:Journal
] ;
bibo:issue "1" ;
bibo:volume "5" ;
a bibo:Issue
] ;
dcterms:title "Global cities, glocal states: global city
formation and state territorial restructuring in contemporary Europe"
;
bibo:authorList [
rdf:_1 _:n710 ;
a rdf:Seq
] ;
bibo:pages "1-37" ;
a bibo:AcademicArticle
] ;
a z:UserItem .
So far, I have not seen a single property value that is a URI. The
upshot is that the modeling offers the modelling costs of RDF
(complexity) without the benefits?
Bruce
Yes,exactly.
>> Also, on z:accessDate: a) did the Resource List ontology not add
>> something such a property?, and b) is the correct data-type value
>> (xsd:date-time)?
>
> No, the Resource List ontology didn't add this. (And, FWIW, I'm still
> not sure it doesn't belong in BIBO, since it is necessary to
> unambiguously identify a cited webpage. Avram recently pointed out on
> the item types/fields issue tracker that WebCite has been issuing DOIs
> for archived versions of webpages.) What would you rather the data
> type be?
I think the way you do it here is appropriate because it's about when
the user accessed it.
>> Again, a blank node for critical data:
>>
>> <file:///home/bdarcus/Data/zlibrary.rdf#item_107>
>> res:resource [
>> dcterms:creator _:n710 ;
>> dcterms:isPartOf [
>> dcterms:date "1998" ;
>> dcterms:isPartOf [
>> dcterms:title "Review of International Political Economy" ;
>> a bibo:Journal
>> ] ;
>> bibo:issue "1" ;
>> bibo:volume "5" ;
>> a bibo:Issue
>> ] ;
>> dcterms:title "Global cities, glocal states: global city
>> formation and state territorial restructuring in contemporary Europe"
>> ;
>> bibo:authorList [
>> rdf:_1 _:n710 ;
>> a rdf:Seq
>> ] ;
>> bibo:pages "1-37" ;
>> a bibo:AcademicArticle
>> ] ;
>> a z:UserItem .
>>
>> So far, I have not seen a single property value that is a URI.
>
> res:resource in your example above is a property value that is a URI.
Yes, you're right; I stand corrected.
>> The
>> upshot is that the modeling offers the modelling costs of RDF
>> (complexity) without the benefits?
>
> If you don't provide an ISBN, DOI, or URI an item, Zotero can't
> provide a URI for the item.
OK. Fixing the item links would at least be a good start.
> I know you have been asking us to create
> URIs for items, but at the moment we don't have the resources to deal
> with the record linkage issues. If there is an ISBN, DOI, or URI the
> export should use it. If it's not using these identifiers, that's a
> bug, but it doesn't look like the item you provide above has any of
> this metadata.
>
> If there are other cases where you think we should model things
> differently, I would be happy to hear.
I think so far the modeling itself looks pretty good.
> FWIW, I think the complexity is almost entirely introduced by
> hierarchical structuring. MODS, which is also hierarchically
> structured but doesn't use RDF, has similar complexity, which is
> probably why relatively few tools can read/write it. A flat RDF format
> does not look very different from plain XML.
True. But unlike in MODS, the purpose of what you call "hierarchy"
here is to enable addressable/linkable objects: people, pubs, etc.
Example of obvious relevance:
<http://www.citeulike.org/author/D'Arcus:B>
Am I right that solving this issue is tied into other issues, like
duplicate detection?
Bruce