tag:blogger.com,1999:blog-759829936301057674.post9117269321692190147..comments2023-10-17T15:09:44.748+01:00Comments on About Tag: The Guardian 1000 Novels Everyone Must Readnjrhttp://www.blogger.com/profile/08980758986023344486noreply@blogger.comBlogger15125tag:blogger.com,1999:blog-759829936301057674.post-57074119788218638732010-01-28T21:13:43.857+00:002010-01-28T21:13:43.857+00:00The "canonical" (persistent) identifier ...The "canonical" (persistent) identifier in the publishing industry is increasingly the Digital Object Identifier (DOI); see http://doi.org<br /><br />The fascinating thing for me about FluidDB is that a few of us active in the DOI/Handle System community over the last decade++ have imagined associating metadata with objects in this fashion, but the infrastructure has been too heavy. With FluidDB, it isn't!Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-759829936301057674.post-84206077769325788092009-09-14T18:26:47.494+01:002009-09-14T18:26:47.494+01:00How does FluidDB help with the recommendation side...How does FluidDB help with the recommendation side of this ("which of your friends seem to like the same novels as you")? The article's great as far as it goes, but I'm intrigued how "this is exactly the kind of thing FluidDB was built for" is the case, and how it could help me to answer similar questions.Peterhttps://www.blogger.com/profile/15981047584546701890noreply@blogger.comtag:blogger.com,1999:blog-759829936301057674.post-44610571980761176582009-08-31T02:42:04.151+01:002009-08-31T02:42:04.151+01:00Yup, I encountered that "abstract tag" c...Yup, I encountered that "abstract tag" construct right after posting my previous comment (I'm bitsucker, btw). I agree that this would be a natural place to identify the datatype for a tag.<br /><br />But I still think this just begs the question: if different apps design their own mechanisms for describing their data-types, third-party mashups will be forced to develop and maintain "interop glue" for each new convention. <br /><br />Perhaps this is just me leaning towards the "librarian end" myself, but my intuition is that some sort of standard for schema metadata would be hugely beneficial. Whether it is designed into the DB itself, or adopted by convention "after market," someone will need to establish a canonical way to encode datatypes -- to say, for example, "this is a value from 0-10 indicating the owner's opinion of the quality of the tagged object." Without this, the data will necessarily be unstructured soup.<br /><br />If you agree with that, then I further suggest that it'd be preferable to at least offer a suggested "canonical encoding" for this metadata. Even an RFC with a starting proposal for this could help to herd the community towards an eventual standard. You have the opportunity now, in the beginning, to guide the users in how they construct and annotate their data. If you wait and hope that the community will converge on its own standard, it may be much less likely to succeed.<br /><br /><br />I should confess, of course, that I'm just getting started in reading about your project and its community; I may be unaware of some discussion that's already been shared in this area. If so, please set me straight! And congrats on coming this far with a very exciting project; I hope it lives up to its full potential.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-759829936301057674.post-35351105301278230492009-08-30T22:43:04.512+01:002009-08-30T22:43:04.512+01:00bitsucker: I agree with most of this. I'm no...bitsucker: I agree with most of this. I'm not sure it requires an architectural change though. There is an object corresponding to each "abstract tag" in FluidDB (an abstract tag, in my terminology, being roughly the set of tags sharing a name). So if you use a tag bitsucker/rating, there is an object corresponding to the (abstract) tag bitsucker/rating, and you could attach a schema specifier on there.<br /><br />There's a broad range of view on the importance of taxonomies in FluidDB. Personally, I veer towards the "librarian end", but others are more relaxed.<br /><br />Anyway, thanks for the comment...we shall see how it evolves.njrhttps://www.blogger.com/profile/08980758986023344486noreply@blogger.comtag:blogger.com,1999:blog-759829936301057674.post-583770694561061982009-08-30T18:39:28.560+01:002009-08-30T18:39:28.560+01:00Though I'm sure this isn't novel, I'm ...Though I'm sure this isn't novel, I'm compelled to highlight that the challenge discussed in these comments -- the lack of (and need for) a truly canonical identifier for books -- applies to just about every kind of entity you might want to annotate in a db. This has been the source of my primary skepticism about the fluiddb concept since I first started thinking about it a few weeks ago: how can an open data-store be socially useful without standardized formulae for identifying the records?<br /><br />In fact, this same problem arises for ALL fields in the DB: both in the tag names (why "rating" instead of "score?") and in their values (I might pick a rating scale 1-5, like many popular review websites, and pollute your rating data).<br /><br />I anticipate that the social value offered by something like fluiddb will depend heavily on the availability (and adoption) of a supporting system for specifying and referring to SCHEMA descriptions. Something like XSD, allowing applications to describe the conventions employed for storing specific types of data. This may also require an additional data axis in the db, to allow a specific tag to be annotated with its datatype from a given schema.<br /><br />Without some sort of metadata store like this, I fear your "open db" may quickly devolve into an unmanagable, unstructured mess with no more interoperability than today's "open web."bitsuckerhttps://www.blogger.com/profile/08606093667742884460noreply@blogger.comtag:blogger.com,1999:blog-759829936301057674.post-59131260365142272582009-08-27T09:44:31.970+01:002009-08-27T09:44:31.970+01:00Comment as much as you like Owen: it's all goo...Comment as much as you like Owen: it's all good stuff.<br /><br />But detailed replies will have to wait: I need to work.<br /><br />I'll check out Library Thing though.<br /><br />Leaning towards<br /><br />about="The Name of the Book//The Book's Author"<br /><br />as a temporary convention till the librarians of the world get their act together :-)<br /><br />Thanks for all the input.njrhttps://www.blogger.com/profile/08980758986023344486noreply@blogger.comtag:blogger.com,1999:blog-759829936301057674.post-16917700821064860522009-08-27T09:36:01.108+01:002009-08-27T09:36:01.108+01:00Final comment! (I promise) Obviously you weren'...Final comment! (I promise) Obviously you weren't setting out to solve all these problems, but rather do some stuff with FluidDB and add some interesting social functions to this list of books!<br /><br />You asked about automatic grabbing of ISBNs. Most library systems support m2m interface. You could look at the WorldCat API (http://www.oclc.org/productworks/worldcatapi.htm), or possibly the LibraryThing API (http://www.librarything.com/services/webservices.php), or finally COPAC (catalogue from major research Unis in the UK) can return records in an XML format - http://copac.ac.uk/development-blog/tag/api/<br /><br />I think you'd find LibraryThing is the best match to the kind of thing you want to do, although not sure about the T&C on their API (generally the guy behind LibraryThing seems pretty open to doing interesting stuff, but he has got a business to run!)Owenhttps://www.blogger.com/profile/15363304748950192248noreply@blogger.comtag:blogger.com,1999:blog-759829936301057674.post-2000381803866243722009-08-27T09:27:39.415+01:002009-08-27T09:27:39.415+01:00Oh - forgot the LibraryThing URL http://www.librar...Oh - forgot the LibraryThing URL http://www.librarything.com/<br /><br />Also, you might be interested in this paper from Rob Styles et al on RDF representations of book data. Specifically the bits on creating URIs as identifiers might possibly be of relevance:<br /><br />http://dynamicorange.com/uploads/Semantic%20Marcup.pdf<br />(Rob Styles works for http://www.talis.com who do lots of semantic web/linked data stuff but also do library systems)Owenhttps://www.blogger.com/profile/15363304748950192248noreply@blogger.comtag:blogger.com,1999:blog-759829936301057674.post-30505612022918597862009-08-27T09:27:28.587+01:002009-08-27T09:27:28.587+01:00Owen. Yes; it;s more of a minefield than I realis...Owen. Yes; it;s more of a minefield than I realised. Sanghyeon Seo pointed me at FRBR too. I'll take a look.<br /><br />I wonder whether it's too fanciful to think that FluidDB could actually help with its 256-bit immutable object IDs.<br /><br />Maybe we do just establish a convention for describing a work and then use the FluidDB ID as the reference code. Clearly there'd be a major problem defining the canonical form for a work, but starting with title and author in an agreed (algorithmic) encoding would be a start. Obviously, accents, punctuation, editions etc. would all be issues.<br /><br />But that's probably simplistic.<br /><br />I stepped into a minefield!<br /><br />Thanks for the input.njrhttps://www.blogger.com/profile/08980758986023344486noreply@blogger.comtag:blogger.com,1999:blog-759829936301057674.post-26904612893137943582009-08-27T09:17:26.518+01:002009-08-27T09:17:26.518+01:00Libraries and associated bodies have been dealing ...Libraries and associated bodies have been dealing with managing book data for quite a while! The current thinking in this area is something called 'FRBR' - which defines different levels of description in terms of the following entities:<br /><br />Work<br />Expression<br />Manifestation<br />Item<br /><br />(see http://en.wikipedia.org/wiki/Functional_Requirements_for_Bibliographic_Records)<br /><br />In this model, the Guardian list is a list of works, whereas ISBNs are part of a specific manifestation (as would be other details specific to a published edition).<br /><br />However, the problem is that there is no agreed identifier for works.<br /><br />You could look at:<br /><br />LibraryThing - this has an API, and groups books into 'works' bringing together the various editions<br />FictionFinder - from OCLC (a library organisation), which presents 'work' level records for books (user interface at http://fictionfinder.oclc.org/ and some more information at http://www.oclc.org/research/projects/frbr/fictionfinder.htm)<br />Open Library - http://openlibrary.org/about/frbrization<br /><br />To be honest it's tricky stuff, but there are people around doing a lot of work on itOwenhttps://www.blogger.com/profile/15363304748950192248noreply@blogger.comtag:blogger.com,1999:blog-759829936301057674.post-45537458782680896212009-08-27T08:24:05.800+01:002009-08-27T08:24:05.800+01:00Incidentally, I hope people have noticed that Flui...Incidentally, I hope people have noticed that FluidDB has allocated an ID for HHGTTG that includes a 42 hex pair, as well as an (admitttedly non-byte-aligned) 2a, which is 42 in hex.<br /><br />It's scary.njrhttps://www.blogger.com/profile/08980758986023344486noreply@blogger.comtag:blogger.com,1999:blog-759829936301057674.post-83641779661109834042009-08-27T08:02:41.300+01:002009-08-27T08:02:41.300+01:00Holger:
These are all good points. I'll tak...Holger:<br /><br />These are all good points. I'll take them in turn.<br /><br />1. I agree (now) that the ISBN number isn't as good as I thought, for exactly the reason you state, namely that there is a many-to-one mapping from isbn numbers to (conceptual) books. I hadn't really realised this; at least not clearly enough. That's a huge problem with my scheme.<br /><br />2. I know about ISBN10 vs. ISBN 13, but that worries me less. But you're right, it's an issue.<br /><br />3. Formatting. Me culpa. The truth is, I took the format from Amazon and assumed it was standard (though if I'd thought about it, I'd have realised it wasn't). In general, I'm a big believer in software accepting separators in numbers because it makes them so much easier for humans. But I should have found the standard. You're right, there's definitely a case for makeing the tag without any separators, though in fact I think I'm more likely to go for separators in standard places, assuming there is a universal standard for ISBN-13 formatting. (I don't mean universally used; just universally applicable).<br /><br />Lots to think about and all good points. It's early days, and fortunately (since these aren't global standards and its so early) it's easy for me to edit my recommendations.<br /><br />The fundamental problem you point out (the non-uniqueness of ISBN numbers) is a big deal, and I may decide to try to find something better. Of course, it could be that this "something better" is a FLuidDB object ID, and that about tag really should be set to some title/author combination in standard form. (And yes, I realise all the problems with that "standard form"...)<br /><br />Thanks for the input. I'll think a little before putting up the other 990, which will take me a couple of days anyway, I think.<br /><br />What I am unlikely to be deflected from is the attempt to find a meaningful about tag that identifies books, because in my my view, that is pretty much necessary in order for cross-user queries to work reliably and take off.njrhttps://www.blogger.com/profile/08980758986023344486noreply@blogger.comtag:blogger.com,1999:blog-759829936301057674.post-57314043411324434072009-08-27T07:51:52.061+01:002009-08-27T07:51:52.061+01:00David --- thanks!David --- thanks!njrhttps://www.blogger.com/profile/08980758986023344486noreply@blogger.comtag:blogger.com,1999:blog-759829936301057674.post-13638575450982494032009-08-27T07:35:39.859+01:002009-08-27T07:35:39.859+01:00Thank you for this article describing your view of...Thank you for this article describing your view of tagging the universe.<br /><br />Unfortunately this example also shows the difficulties of this endeavour, namely the discoverablity of objects via their about tag.<br />In this case you used the ISBN number which, while I cannot offer any better attribute of books, is not very suitable.<br />Firstly, your formatting included one hyphen. Why one? ISBN numbers are highly structured (read up on it on Wikipedia) and hyphens are usually used as separators between the parts of an ISBN but not everywhere and not consistently. So maybe it would have been better to just drop all hyphens and make it easier for others to discover the object even if they don't know how exactly you entered it.<br /><br />Secondly, there are two kinds of ISBN -- 10 digit and 13 digit. IIRC I have seen books that had both printed on them. Now, as I understand it, you can convert a 10-digit version to a 13-digit by prefixing it with "987" but will users trying to find the object for their book know that?<br /><br />Thirdly and most importantly ISBNs identify a publisher's version of the work. I hope we can agree that Mr Douglas's classic work is basically the same (at least for the purpose of general review that you outlined), no matter if you have the British version, the US version, a version part of an omnibus edition, etc. But all these will have different ISBNs (case in point: my HHGTTG copy's number is 0-671-52721-5).<br /><br />So this begs the question if you should have made the ISBN a regular tag (list valued so one can associate more than one ISBN with a work)?Holger Dürerhttps://www.blogger.com/profile/00555282306926644834noreply@blogger.comtag:blogger.com,1999:blog-759829936301057674.post-20568371172437386902009-08-27T01:41:03.077+01:002009-08-27T01:41:03.077+01:00Thanks for that Nick, very useful. The most intere...Thanks for that Nick, very useful. The most interesting part for me was your attempt to set down some conventions for tag semantics and value ranges. I sense a disturbance in the (evolutionist) force, a glitch in the biological matrix, etc, etc. As the speaker said: order, order, order!David Semeriahttp://lmframework.com/blog/aboutnoreply@blogger.com