Print

Print


Sorry, to clarify:

> 
> If you adopt someone else's terms, you are stuck with their definitions, and if they decide to change them, you have to revisit your decision: a constant maintenance headache.

This is why we have versioning in the namespaces.


> The foaf vocab is in Testing status, version 0.98. Are they going to change it before it comes out? Who knows?  Will they add something better like foaf:sortName that is more like a traditional library listing?

Yes, the version you'd be using is http://xmlns.com/foaf/0.1/

> Just coming up with a list of all the possible terms out there and fighting over whether they are close enough to use for each term we have will be a major use of time.

I suggest that LoC not do this as it has been done before by the British Library and many others.

> On DC, people you might not be for it, but if we opened the BF vocab up, there might be a lot of clamor for it; it's so simple and it's all over the place!

You'd probably want to version this data too http://dublincore.org/2012/06/14/dcterms.rdf

> 
> Nate
> PS I had a good laugh about the Unicode and ISO 639 "roll our own comment". I'm working right now on developing a computer that uses 2s and 3s instead of 1s and 0s.
> 
> -----Original Message-----
> From: stuart yeates [mailto:[log in to unmask]] 
> Sent: Wednesday, May 22, 2013 5:31 PM
> To: Bibliographic Framework Transition Initiative Forum
> Cc: Trail, Nate
> Subject: Re: [BIBFRAME] re-using existing properties (was http://bibframe.org/documentation/bibframe-authority/ and the "lightweight abstraction layer")
> 
> On 23/05/13 05:25, Trail, Nate wrote:
>> I think when you start reusing existing properties, you're relying on 
>> them being around for the long haul, and requiring systems that 
>> consume them to be aware of all the multiple namespaces.
> 
> The "syntactic sugar" option used by madsrdf:hasCloseExternalAuthority does not introduce a new namespace from the users' point of view. The syntactic sugar can even be kept in a separate RDF file from the definition of the bibframe properties, making it second class and invisible to everyone who doesn't want it.
> 
>> In all cases, I can't
>> see us (the library community) agreeing that the way foaf or dc (or  > whatever) uses a term really matches what we're talking about.
> 
> Following that arguement we should also walk away from ISO 639, ISO 3166, RFC 3986, Unicode and so forth. None of them are perfect from a library point of view but all of the are better than rolling our own.
> 
> [For the record I'm not suggestion using dc / Dublincore.]
> 
> cheers
> stuart
> --
> Stuart Yeates
> Library Technology Services http://www.victoria.ac.nz/library/
> 

Rurik Thomas Greenall
NTNU University Library | NTNU Universitetsbiblioteket
[log in to unmask]
@brinxmat
http://folk.ntnu.no/greenall
https://listserv.loc.gov/cgi-bin/wa?A3=ind1305&L=BIBFRAME&E=quoted-printable&P=4088357&B=--&T=text%2Fplain;%20charset=us-ascii&header=1
listserv.loc.gov
crawl=CC-MAIN-2022-27
4159
application/http; msgtype=response
sha1:TQHKWKFZ7AC24QBRVCEL7B5QGPV3YBWZ
<urn:uuid:0d2d96d7-b344-41a3-a006-9b8691f2ce0f>
2022-07-01T05:40:16Z
140.147.239.86
text/html
sha1:MB7J4BFN2JQ5DNXVEPIKNWYW62XDDY5K
<urn:uuid:77f113eb-ddf0-4e58-bce2-ee2169f31895>
https://listserv.loc.gov/cgi-bin/wa?A3=ind1305&L=BIBFRAME&E=quoted-printable&P=4088357&B=--&T=text%2Fplain;%20charset=us-ascii&header=1
response
<urn:uuid:eb31dec6-c25b-4ee7-aa63-b731bc637b4c>
isPartOf: CC-MAIN-2022-27
publisher: Common Crawl
description: Wide crawl of the web for June/July 2022
operator: Common Crawl Admin (info@commoncrawl.org)
hostname: ip-10-67-67-246
software: Apache Nutch 1.18 (modified, https://github.com/commoncrawl/nutch/)
robots: checked via crawler-commons 1.3-SNAPSHOT (https://github.com/crawler-commons/crawler-commons)
format: WARC File Format 1.1
conformsTo: https://iipc.github.io/warc-specifications/specifications/warc-format/warc-1.1/