You can subscribe to this list here.
2010 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
(9) |
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2011 |
Jan
|
Feb
|
Mar
|
Apr
(4) |
May
|
Jun
(3) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2012 |
Jan
(16) |
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
(4) |
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2013 |
Jan
|
Feb
(1) |
Mar
(19) |
Apr
(3) |
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2016 |
Jan
|
Feb
(8) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Voß, J. <Jak...@gb...> - 2016-02-02 19:43:01
|
Hi Uwe, Thanks for your response. Before further investigation and judgement I'd like to better understand the (possibly theoretical?) use case. Can the additional information somehow be located to belong to a specific conceptual (!) entity of DAIA (full response, document, item, availability...)? More concrete examples would also help but defining the unknown isn't easy ;-) Jakob ________________________________________ Von: Uwe Reh <re...@he...> Gesendet: Dienstag, 2. Februar 2016 17:18 An: dai...@li... Betreff: Re: [DAIA] Container for additional information Hi Jakob, again the clash of our different backgrounds: ;-) * Jakob, the intellectual evangelist of clarity and pure definitions. * Uwe, the pragmatic programmer and former admin of an ILS. Most times, a tiring but effective collaboration. Like already written, I like the work you've done. Your definition is clear and seems to be syntactical perfect. Never I could do it this way. On the other hand, it took me just a few seconds to detect a semantic error. (http://gbv.github.io/daia/daia.html#integrity-rules Example_6_§2: "One item can't belong to two departments") Without any doubt, you know the term 'over normalized' from the SQL context; "Perfect but unusable". I'm looking for a way to 'denormalize' slightly without contaminating your definition. Am 02.02.2016 um 13:49 wrote Jakob Voß: > Why not 3. Use DAIA for availability information and some other method > for anything else? To pragmatic reasons. Like availability, additional information has to do with the document, one of the items or one of the services. Two interfaces require: * two nearly identical requests * twice the time for processing * an additional merging of the responses * more maintanance >> As successor to 'message' I suggest something like: >> "additional" >> - context - (required) - Id for the context of the extension (a weak >> variant of a namespace) >> - content - (required) - Container (String) for the data in this context >> This element should be repeatable and optional in any other element. >> Even if it seems not to make sense. > > I don't see the difference between your suggestion and option 1. Without > definition how these new fields relate to the rest of DAIA, they are > also private and incompatible. What are clients expected to do with this > fields? The idea behind my suggestion is to provide a common way to model new requirements, without poisoning the core elements of DAIA. Otherwise I predict miss usages. (non-human-readable stuff in the attribute 'about' or inflationary usage of new 'limitations') > Sorry for objection but I don't see a use case apart from the rather > fuzzy need of general extension. That's the point. Others will see a case and they will look for an quick hack. "1.2.3....oops! Again a unofficial DAIA clone is born." Your current definition should be the core of DAIA and no one should see a reason to deform it. Especially not for additional local needs. This will guarantee the interoperability of different implementations. Maybe not for all local extensions, but for the availability. The benefit of a explicit element for local extensions is to canalizing them. This allows a strict syntactic validation and has the inherent possibility, to detect common needs. (We are using this pattern already for 'service' and 'limitation') In contrast, uncontrolled and incompatible forks of DAIA (my 'option 1') may weakening the relevance of DAIA. Uwe PS In respect to Gödel's first incompleteness theorem the new element needs to be weak defined. > https://de.wikipedia.org/wiki/G%C3%B6delscher_Unvollst%C3%A4ndigkeitssatz > https://en.wikipedia.org/wiki/G%C3%B6del's_incompleteness_theorems ------------------------------------------------------------------------------ Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140 _______________________________________________ daia-devel mailing list dai...@li... https://lists.sourceforge.net/lists/listinfo/daia-devel |
From: Uwe R. <re...@he...> - 2016-02-02 16:18:39
|
Hi Jakob, again the clash of our different backgrounds: ;-) * Jakob, the intellectual evangelist of clarity and pure definitions. * Uwe, the pragmatic programmer and former admin of an ILS. Most times, a tiring but effective collaboration. Like already written, I like the work you've done. Your definition is clear and seems to be syntactical perfect. Never I could do it this way. On the other hand, it took me just a few seconds to detect a semantic error. (http://gbv.github.io/daia/daia.html#integrity-rules Example_6_§2: "One item can't belong to two departments") Without any doubt, you know the term 'over normalized' from the SQL context; "Perfect but unusable". I'm looking for a way to 'denormalize' slightly without contaminating your definition. Am 02.02.2016 um 13:49 wrote Jakob Voß: > Why not 3. Use DAIA for availability information and some other method > for anything else? To pragmatic reasons. Like availability, additional information has to do with the document, one of the items or one of the services. Two interfaces require: * two nearly identical requests * twice the time for processing * an additional merging of the responses * more maintanance >> As successor to 'message' I suggest something like: >> "additional" >> - context - (required) - Id for the context of the extension (a weak >> variant of a namespace) >> - content - (required) - Container (String) for the data in this context >> This element should be repeatable and optional in any other element. >> Even if it seems not to make sense. > > I don't see the difference between your suggestion and option 1. Without > definition how these new fields relate to the rest of DAIA, they are > also private and incompatible. What are clients expected to do with this > fields? The idea behind my suggestion is to provide a common way to model new requirements, without poisoning the core elements of DAIA. Otherwise I predict miss usages. (non-human-readable stuff in the attribute 'about' or inflationary usage of new 'limitations') > Sorry for objection but I don't see a use case apart from the rather > fuzzy need of general extension. That's the point. Others will see a case and they will look for an quick hack. "1.2.3....oops! Again a unofficial DAIA clone is born." Your current definition should be the core of DAIA and no one should see a reason to deform it. Especially not for additional local needs. This will guarantee the interoperability of different implementations. Maybe not for all local extensions, but for the availability. The benefit of a explicit element for local extensions is to canalizing them. This allows a strict syntactic validation and has the inherent possibility, to detect common needs. (We are using this pattern already for 'service' and 'limitation') In contrast, uncontrolled and incompatible forks of DAIA (my 'option 1') may weakening the relevance of DAIA. Uwe PS In respect to Gödel's first incompleteness theorem the new element needs to be weak defined. > https://de.wikipedia.org/wiki/G%C3%B6delscher_Unvollst%C3%A4ndigkeitssatz > https://en.wikipedia.org/wiki/G%C3%B6del's_incompleteness_theorems |
From: Oliver G. <o.g...@tu...> - 2016-02-02 14:58:19
|
Hi Jakob and Uwe, thank you both for the recommandation. I guess you are right and it's a good idea to skip missing or lost copies in DAIA. Best Oliver Am 01.02.2016 um 17:00 schrieb Uwe Reh: > Hi Oliver, > > the latest definitions by Jakob (http://gbv.github.io/daia/daia.html) > are very strict. He has done a good job in optimizing DAIA for automated > processing. Maybe a bit to good, because now it's hard to tunnel > additional information to the client. That's the reason, why we are > still using version 0.5. (Even if we would adopt to version 0.9++, we > would have to extend the definition with 'message' elements.) > > To your concrete question, there is one easy option. Just like Jakob > suggested, omit the missing items. > - if you miss one of several items, no one would care. > - if the only item is missing, your client could interpret the absence > of items. > For a patron it is not relevant, why there is no item . (Libarians > should use the native tools of their ILS) > > Uwe > > > Am 01.02.2016 um 13:15 schrieb Oliver Goldschmidt: >> Hello all, >> >> I'm wondering how to show that an item is missing in DAIA. Our DAIA >> server is setting a message to the item indicating that it is missing. >> But I guess this is not the way the standard demands (as the message >> field has been dropped from specification). >> >> Does it make sense to use the limitation attribute for this use case? I >> thought limitation would only make sense for available items, but >> according to the spec it could also be set for unavailable elements. >> >> Is there any recommendation how to handle missing items? >> >> Thank you for any hint >> Oliver >> > ------------------------------------------------------------------------------ > Site24x7 APM Insight: Get Deep Visibility into Application Performance > APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month > Monitor end-to-end web transactions and take corrective actions now > Troubleshoot faster and improve end-user experience. Signup Now! > http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140 > _______________________________________________ > daia-devel mailing list > dai...@li... > https://lists.sourceforge.net/lists/listinfo/daia-devel |
From: Jakob V. <Jak...@gb...> - 2016-02-02 12:49:17
|
Hi Uwe & Oliver, Uwe Reh wrote: > I like this version (0.9.8+1), but I desperately miss a documented way > to add additional information. > In version 0.5 we had the element 'message'. This was and is very > helpful to pass additional information to the client. OK, it was poorly > defined but useful. :-) It was meant for error messages. > From my point of view, it is mandatory for DAIA to be extendable. No > one can predict all use cases of DAIA. In a real world, there are > millions of request for tunneling information from the ILS to the user. The whole point of an API is to limit what is possible to get expectable results. The general method to transport "information" is plain HTTP (without definition with a schema or format I would not even call this information but documents). > If there is no documented way to do this a developer has only two evil > options: > > 1. Invent a own private and potential incompatible extension. Sure. > 2. Ignore DAIA completely and implement a own interface. > > :-( Why not 3. Use DAIA for availability information and some other method for anything else? > As successor to 'message' I suggest something like: > "additional" > - context - (required) - Id for the context of the extension (a weak > variant of a namespace) > - content - (required) - Container (String) for the data in this context > This element should be repeatable and optional in any other element. > Even if it seems not to make sense. I don't see the difference between your suggestion and option 1. Without definition how these new fields relate to the rest of DAIA, they are also private and incompatible. What are clients expected to do with this fields? For plain-text general information there is already "document.about" and "item.about" to transport human-readable description of documents and items. Sorry for objection but I don't see a use case apart from the rather fuzzy need of general extension. Jakob -- Jakob Voß <jak...@gb...> Verbundzentrale des GBV (VZG) / Common Library Network Platz der Goettinger Sieben 1, 37073 Göttingen, Germany +49 (0)551 39-10242, http://www.gbv.de/ |
From: Uwe R. <re...@he...> - 2016-02-01 17:07:55
|
Hi, blocked by daily stuff, i lost track to the DAIA specs. Triggered by the Olivers question, I had a look on the current version. I like this version (0.9.8+1), but I desperately miss a documented way to add additional information. In version 0.5 we had the element 'message'. This was and is very helpful to pass additional information to the client. OK, it was poorly defined but useful. :-) From my point of view, it is mandatory for DAIA to be extendable. No one can predict all use cases of DAIA. In a real world, there are millions of request for tunneling information from the ILS to the user. If there is no documented way to do this a developer has only two evil options: 1. Invent a own private and potential incompatible extension. 2. Ignore DAIA completely and implement a own interface. :-( As successor to 'message' I suggest something like: "additional" - context - (required) - Id for the context of the extension (a weak variant of a namespace) - content - (required) - Container (String) for the data in this context This element should be repeatable and optional in any other element. Even if it seems not to make sense. Regards Uwe |
From: Uwe R. <re...@he...> - 2016-02-01 16:22:54
|
Hi Oliver, the latest definitions by Jakob (http://gbv.github.io/daia/daia.html) are very strict. He has done a good job in optimizing DAIA for automated processing. Maybe a bit to good, because now it's hard to tunnel additional information to the client. That's the reason, why we are still using version 0.5. (Even if we would adopt to version 0.9++, we would have to extend the definition with 'message' elements.) To your concrete question, there is one easy option. Just like Jakob suggested, omit the missing items. - if you miss one of several items, no one would care. - if the only item is missing, your client could interpret the absence of items. For a patron it is not relevant, why there is no item . (Libarians should use the native tools of their ILS) Uwe Am 01.02.2016 um 13:15 schrieb Oliver Goldschmidt: > > Hello all, > > I'm wondering how to show that an item is missing in DAIA. Our DAIA > server is setting a message to the item indicating that it is missing. > But I guess this is not the way the standard demands (as the message > field has been dropped from specification). > > Does it make sense to use the limitation attribute for this use case? I > thought limitation would only make sense for available items, but > according to the spec it could also be set for unavailable elements. > > Is there any recommendation how to handle missing items? > > Thank you for any hint > Oliver > |
From: Jakob V. <Jak...@gb...> - 2016-02-01 14:35:26
|
Hi Oliver, > I'm wondering how to show that an item is missing in DAIA. Our DAIA > server is setting a message to the item indicating that it is missing. > But I guess this is not the way the standard demands (as the message > field has been dropped from specification). yes. > Does it make sense to use the limitation attribute for this use case? I > thought limitation would only make sense for available items, but > according to the spec it could also be set for unavailable elements. > > Is there any recommendation how to handle missing items? What's the difference between a missing item and an item being unavailable for any other reason? DAIA is not intended for telling why something in available/unavailable but how. One solution would be not not return the item at all. If it's missing then it's gone, isn't it? Jakob -- Jakob Voß <jak...@gb...> Verbundzentrale des GBV (VZG) / Common Library Network Platz der Goettinger Sieben 1, 37073 Göttingen, Germany +49 (0)551 39-10242, http://www.gbv.de/ |
From: Oliver G. <o.g...@tu...> - 2016-02-01 12:13:39
|
Hello all, I'm wondering how to show that an item is missing in DAIA. Our DAIA server is setting a message to the item indicating that it is missing. But I guess this is not the way the standard demands (as the message field has been dropped from specification). Does it make sense to use the limitation attribute for this use case? I thought limitation would only make sense for available items, but according to the spec it could also be set for unavailable elements. Is there any recommendation how to handle missing items? Thank you for any hint Oliver |
From: David M. <ma...@ha...> - 2013-07-29 05:57:04
|
At Wed, 17 Jul 2013 15:50:36 +0200, Jakob Voß wrote: > > Hi, > > A few month ago we had a discussion about multilingual content for > limitations and other entities. I tried to summarize this as issue at: > > https://github.com/gbv/daiaspec/issues/4 > > At least for limitations the solution would cause no problems, right? > Wrapping the content of a limitation in a dedicated content element with language tag solves the problem, indeed. Best, -- David > Jakob > > -- > Jakob Voß <jak...@gb...>, skype: nichtich > Verbundzentrale des GBV (VZG) / Common Library Network > Platz der Goettinger Sieben 1, 37073 Göttingen, Germany > +49 (0)551 39-10242, http://www.gbv.de > > ------------------------------------------------------------------------------ > See everything from the browser to the database with AppDynamics > Get end-to-end visibility with application monitoring from AppDynamics > Isolate bottlenecks and diagnose root cause in seconds. > Start your free trial of AppDynamics Pro today! > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk > _______________________________________________ > daia-devel mailing list > dai...@li... > https://lists.sourceforge.net/lists/listinfo/daia-devel -- David Maus Herzog August Bibliothek - D-38299 Wolfenbuettel Phone: +49-5331-808-317 Email: ma...@ha... Digital Humanities Research Collaboration http://www.gcdh.de/en/projects/dh/ PGP Key 0x0CC2E093512F7385 Fingerprint 1AD2 EE67 224F 18C5 EA55 98AD 0CC2 E093 512F 7385 |
From: Jakob V. <vo...@gb...> - 2013-07-17 13:50:51
|
Hi, A few month ago we had a discussion about multilingual content for limitations and other entities. I tried to summarize this as issue at: https://github.com/gbv/daiaspec/issues/4 At least for limitations the solution would cause no problems, right? Jakob -- Jakob Voß <jak...@gb...>, skype: nichtich Verbundzentrale des GBV (VZG) / Common Library Network Platz der Goettinger Sieben 1, 37073 Göttingen, Germany +49 (0)551 39-10242, http://www.gbv.de |
From: Voß, J. <Jak...@gb...> - 2013-04-22 11:45:50
|
Hi Adrian, I added the suggested solutions as open issues at https://github.com/gbv/daiaspec/issues/3 > This sounds reasonable and I believe defining a daia:baseURL property > makes sense in any way. The problem is that, AFAIK, you are not able > to automatically generate DAIA-URIs for items solely based on this > information because you need some extra-information on how to compose > a query-URL for a particular item. This would be a problem for us... What do you mean by DAIA-URI? Do you mean a URL to query a DAIA response from a DAIA server, such as http://example.org/?id=foo:bar&format=xml ? Such an URL can be composed based on the base URL and the document identifier if the client knows how such query URLs are defined in DAIA specification. These URLs are only meant for consumption by DAIA clients and DAIA clients should know how to construct these URLs anyway. Otherwise one could argue to also give all HTTP request headers, explain how to open a HTTP connection etc. down to the level of TCP/IP. Jakob |
From: Jakob V. <vo...@gb...> - 2013-04-09 15:28:11
|
On 09.04.2013 16:06, Adrian Pohl wrote: > in our next improvement of the lobid RDF data we want to add links from > an item to its availability information from the corresponding DAIA API > (if existant). Well, a particular item does not have a DAIA API but the item is recorded in a database (aka library catalog) which may have a DAIA API. > Example: > > The item http://lobid.org/item/HT014860507%3AWWB48190%3A5 shall be > linked to the corresponding JSON output of the UB Bochum's DAIA API at > http://api.ub.rub.de/daia/?id=hbzid:HT014860507&format=json If you need to directly link the item to its availability information, you may just use foaf:isPrimaryTopicOf or use owl:sameAs and link to an URI that returns http://api.ub.rub.de/daia/?id=hbzid:HT014860507 converted to DAIA/RDF. BY the way DAIA query IDs are defined as URIs, so this should better work: http://api.ub.rub.de/daia/?id=http://lobid.org/item/HT014860507%3AWWB48190%3A5 I am not sure about how to exactely express the connection in RDF but a two-step property-chain will reduce the number of triples and better express the actual relations between entities instead of just pointing to JSON documents [*]: Solution 1: Link via the catalog/database: <http://lobid.org/item/HT014860507%3AWWB48190%3A5> example:catalogedIn <https://opac.ub.ruhr-uni-bochum.de/> . <https://opac.ub.ruhr-uni-bochum.de/> example:daiaAPI <http://api.ub.rub.de/daia/> . Solution 2: Link via the owner (which you already express in RDF): <http://lobid.org/item/HT014860507%3AWWB48190%3A5> frbr:owner <http://lobid.org/organisation/DE-294> . <http://lobid.org/organisation/DE-294> example:daiaAPI <http://api.ub.rub.de/daia/> . I'd use daia:heldBy instead of frbr:owner but the pattern is the same. We just need to define a property example:daiaAPI to link a resource that owns or helds or knowns about documents to a DAIA API to query availability information about this items. I'd call this propery "daia:baseURL" to make clear it points to the base URL of a DAIA API. Would this be acceptable? Jakob [*] Sorry for not offering the simple solution you requested for, but directly linking to a JSON response would mix information-resources and non-information resources. P.S: I am currently refactoring the DAIA ontology at so the RDF data of availability may change. The current draft of DAIA 1.0 is available at http://gbv.github.io/daiaspec (documentation) https://github.com/gbv/daiaspec (sources) Changes between DAIA/RDF 0.5 and DAIA/RDF 1.0 are documented at http://gbv.github.io/daiaspec/daia.html#relevant-differences-to-daia-0.5 -- Jakob Voß <jak...@gb...>, skype: nichtich Verbundzentrale des GBV (VZG) / Common Library Network Platz der Goettinger Sieben 1, 37073 Göttingen, Germany +49 (0)551 39-10242, http://www.gbv.de |
From: Adrian P. <ad...@go...> - 2013-04-09 14:07:00
|
Hello, in our next improvement of the lobid RDF data we want to add links from an item to its availability information from the corresponding DAIA API (if existant). Example: The item http://lobid.org/item/HT014860507%3AWWB48190%3A5 shall be linked to the corresponding JSON output of the UB Bochum's DAIA API at http://api.ub.rub.de/daia/?id=hbzid:HT014860507&format=json I haven't found a suitable property (like daia:availabilityInformation) in the DAIA ontology [1] for this use case. I would be very happy if you could add such a property to the ontology. Cheers, Adrian [1] http://purl.org/ontology/daia/ |
From: Uwe R. <re...@he...> - 2013-03-18 16:03:09
|
Am 18.03.2013 16:11, schrieb Jakob Voß: >> <limitation id="mydefinitions:sparseHolding"> (1) >> .... >> (1) It should be no problem to construct an URI > > yes, but then the plain text content "1983; 1985; 1988; ..." must be > equal for all limitations having this URI. So an additional <extent> > element may be more useful. Oh, now I got it. All the time I wrote 'id', but what I meant was 'type' or 'class'. Sorry :-( What do you think about: "<limitation type=..." ? Uwe |
From: Jakob V. <vo...@gb...> - 2013-03-18 15:18:38
|
Hi, I copied the current specification of DAIA 0.5 (or 0.51) from GBV wiki http://www.gbv.de/wikis/cls/DAIA_-_Document_Availability_Information_API to GitHub at http://gbv.github.com/daiaspec/daia.html Updates and sources can be found at http://github.com/gbv/daiaspec There should not be much changes compared to DAIA 0.5. but mostly clarifications. Nevertheless we may need to break full backwards compatibility, for instance by changing the XML namespace or some other minor issue. The final specification will include DAIA/XML, DAIA/JSON, and DAIA/RDF. I have not strict roadmap but plan to finish DAIA 1.0 this summer or autumn. I am also open to more co-authors if this helps to proceed without making DAIA more complicated. Cheers Jakob -- Jakob Voß <jak...@gb...>, skype: nichtich Verbundzentrale des GBV (VZG) / Common Library Network Platz der Goettinger Sieben 1, 37073 Göttingen, Germany +49 (0)551 39-10242, http://www.gbv.de |
From: Jakob V. <vo...@gb...> - 2013-03-18 15:11:26
|
On 15.03.2013 20:53, Uwe Reh wrote: > Up to here it sounds perfect. Did I got it right? > - message has no 'id' or 'errno' anymore. > It has only one attribute which is 'lang' Yes, and the attribute is mandatory. > - even you haven't noted in your examples, every element > which can contain a message needs to have a 'id' which > could be translated to an default value for the message text. This primarily applies to the elements 'institution', 'department', and 'limitation'. After thinking about it twice, it also applies to the remaining elements 'document' and 'item'. > - Good design is avoiding messages, even they are allowed. >> The following mixed case should be forbidden, right?: >> >> <limitation> >> Nicht für alle Nutzer >> <message lang="en">not for everyone</message> >> </limitation> > > At semantic level, you are right. But I am not sure whether it is a good > idea, to disallow any other content than messages. > I have to think about this. Mixed content should be disallowed. I am not sure about plain text, such as <limitation>Nicht für alle Nutzer</limitation> The main main reason for allowing this alternatively to messages is backwards compatibility. > Trying to follow your other points I'm a bit confused. Is the > following example be consistent and valid for you? > > <item id="some:item"> > <limitation id="mydefinitions:sparseHolding"> (1) > <message lang="de"> > Bitte beachten Sie den Bestandsverlauf > </message> (2) > 1983; 1985; 1988; ... > </limitation> > <available service="loan"> > <limitation id="mydefinitions:short-time-loan" /> (3) > </available> > <available service="interloan"> > <limitation id="mydefinitions:only-university-libraries" > > <message lang="en"> (4) > Restricted to scientific libraries > </message> > <message lang="de"> > Nur für Universitäts- und Hochschulbibliotheken > </message> > </limitation> > </available> > </item> Not quite because of the following issue: > (1) It should be no problem to construct an URI yes, but then the plain text content "1983; 1985; 1988; ..." must be equal for all limitations having this URI. So an additional <extent> element may be more useful. > (2) Reference to the discussion about messages. Even there is a > message given, the content is needed for a raw informations. Yes. > (3) An 'id' is given, there is no real need for messages. Yes. > (4) An 'id' is given, it's still allowed to provide textual > explanations anyway. Yes. General clients can just show the message, more intelligent clients can use the id to show a message if no message is given, even more intelligent clients can make use of the id for specific actions, for instance check whether a patron is at a university library and skip the limitation in this case. Jakob -- Jakob Voß <jak...@gb...>, skype: nichtich Verbundzentrale des GBV (VZG) / Common Library Network Platz der Goettinger Sieben 1, 37073 Göttingen, Germany +49 (0)551 39-10242, http://www.gbv.de |
From: Uwe R. <re...@he...> - 2013-03-16 00:52:57
|
Am 15.03.2013 14:49, schrieb Jakob Voß: > As far as I understand, you just argued for inclusion of holding > information (which I called "extent") in DAIA. I got the same request > from other users of DAIA. Not in the sense of making DAIA to an OPAC. But yes, I think this could be a useful information to present. >> So we are back to my initial example, which does not need any change of >> DAIA's model. >>> <limitation id="sparseHolding"> >>> 1983; 1985; 1988; 1990; 1992 - 1994; 1996 >>> </limitation> > > This would make sense if limitation was a property of an item: > > <item> > <limitation>1983; 1985; 1988; ...</limitation> > ... > </item> OK, now i got your point. This limitation is one of the item it's relevant to all forms of availability, not only for one or some. Yes you are right. Trying to follow your other points I'm a bit confused. Is the following example be consistent and valid for you? <item id="some:item"> <limitation id="mydefinitions:sparseHolding"> (1) <message lang="de"> Bitte beachten Sie den Bestandsverlauf </message> (2) 1983; 1985; 1988; ... </limitation> <available service="loan"> <limitation id="mydefinitions:short-time-loan" /> (3) </available> <available service="interloan"> <limitation id="mydefinitions:only-university-libraries" > <message lang="en"> (4) Restricted to scientific libraries </message> <message lang="de"> Nur für Universitäts- und Hochschulbibliotheken </message> </limitation> </available> </item> (1) It should be no problem to construct an URI ;-) (2) Reference to the discussion about messages. Even there is a message given, the content is needed for a raw informations. (3) An 'id' is given, there is no real need for messages. (4) An 'id' is given, it's still allowed to provide textual explanations anyway. Uwe |
From: Uwe R. <re...@he...> - 2013-03-15 19:53:34
|
Hi Jakob, it seems that we are synchronized again. ;-) Am 15.03.2013 14:29, schrieb Jakob Voß: > deprecating errno and introducing a dedicated error elememt: > > <error id="some:uri" /> > > <error id="some:uri"> > <message lang="en">blablab</message> > </error> > > <error> > <message lang="en">bla</message> > <message lang="de">blablab</message> > </error> > > Without errno, the message element could be used for all plain text > strings in DAIA, which includes debugging information (in the response, > document, item, availability), names and explanations (in limitation, > institution, department, storage, error). > > In addition to > > <storage>Magazin</storage> > > we would allow > > <storage> > <message lang="de">Magazin</message> > <message lang="en">stacks</message> > </storage> > > And in addition to > > <limitation>not for everyone</limitation> > > we would have > > <limitation> > <message lang="en">not for everyone</message> > </limitation> Up to here it sounds perfect. Did I got it right? - message has no 'id' or 'errno' anymore. It has only one attribute which is 'lang' - even you haven't noted in your examples, every element which can contain a message needs to have a 'id' which could be translated to an default value for the message text. - Good design is avoiding messages, even they are allowed. > The following mixed case should be forbidden, right?: > > <limitation> > Nicht für alle Nutzer > <message lang="en">not for everyone</message> > </limitation> At semantic level, you are right. But I am not sure whether it is a good idea, to disallow any other content than messages. I have to think about this. Uwe |
From: <in...@fl...> - 2013-03-15 14:24:32
|
Hi Jakob Am 15.03.2013 12:18, schrieb Jakob Voß: > There are three alternatives: > > 1. define a more precise/machine-readable format for extent > 2. don't include the extent at all, so it must be queried by other > means, if needed. > 3. encode each issue/volume/etc as one (hierarchical) DAIA item. I'd prefer solution 2. And you are right: this is how I do it in my implementation. > This only works if one knows journal and issue/volume/year and wants to > know availability. It does not work if one only knows the journal and > wants to know which issues are available. I think this should not be resolved within DAIA, but by using more precise requests: http://www.doctor-doc.com/version1.0/daia.do?&jtitle=pflegezeitschrift Gives the correct answer to the question. If you want to get a more precise answer, be more specific: add a year (or a volume or add even issue) http://www.doctor-doc.com/version1.0/daia.do?issn=&date=1990&volume=&issue=&jtitle=pflegezeitschrift or you use something like my urn:x-domain:... element to look up the information manually http://www.doctor-doc.com/version1.0/stockinfo.do?holding=213 which may give you even several holdings for one library as in the example above. > It's a design decision to include more information about an item in DAIA > or not: Don't. The underlying problem is that the cataloge systems in use, can't handle requests on issue level and sometimes even not for a given year. Adding free text to DAIA to transport this deficency would be another brick to keep up this messy situation. This should be fixed on the level of the "knowledge databases" or cataloging systems. Markus > It get's difficult if items have no URI to look up information with. In > doubt, I'd also argue not to include more information. > > Given the ZDB example in my last may, one would need to supply item > identifiers, e.g.: > > <document id="http://ld.zdb-services.de/resource/1060843-6"> > <item id="http://ld.zdb-services.de/resource/item-epn/089000595"/> > <department id="http://lobid.org/organisation/DE-24"/> > <label>ZCa 6087</label> > <available service="interloan"/> > </item> > > http://ld.zdb-services.de/resource/item-epn/089000595 > => > extent "1983; 1985; 1988; 1990; 1992 - 1994; 1996". > > Jakob > |
From: Jakob V. <vo...@gb...> - 2013-03-15 13:49:23
|
Uwe Reh wrote: > # Journals, we have no information about which issue the patron is > interested in. So we can only in rare situations a valid Information > about the availability (available if all issues are present and not > lendable, unavailable if there is no issue at all) Still important for > the patron are informations like building, shelfmark and the human > readable holding information. He should be able to interpret this and > depending on this information if it is worth going to the library or > not. As far as I understand, you just argued for inclusion of holding information (which I called "extent") in DAIA. I got the same request from other users of DAIA. > So we are back to my initial example, which does not need any change of > DAIA's model. >> <limitation id="sparseHolding"> >> 1983; 1985; 1988; 1990; 1992 - 1994; 1996 >> </limitation> This would make sense if limitation was a property of an item: <item> <limitation>1983; 1985; 1988; ...</limitation> ... </item> Moreover, the kind of limitation is not visible to the client - it's just a random plain text string. An identifier (such as sparseHolding, which is no valid URI by the way) would not help, because it uniquely identifies a limitation. We would need *distinct* limitation identifiers for each different extent value. Instead, limitation refers to the availability of an item, e.g.: <item id="some:item"> <available service="loan"> <limitation>short-time loan</limitation> </available> <available service="interloan"> <limitation>only to university libraries</limitation> </available> </item> One can define custom limitations, but the typical list of limitations is finite. The list of possible holding informations for journals, which is the permutation of all possible years, volumes, issues etc. instead is quite infinite. So this kind of holding information (extent) is *not* an entity, but a plain text information, unless coded in more detail: http://purl.org/NET/DAIA#2.7._Additional_entities Jakob -- Jakob Voß <jak...@gb...>, skype: nichtich Verbundzentrale des GBV (VZG) / Common Library Network Platz der Goettinger Sieben 1, 37073 Göttingen, Germany +49 (0)551 39-10242, http://www.gbv.de |
From: Jakob V. <vo...@gb...> - 2013-03-15 13:29:39
|
Hi Uwe, :-) > Here my pragmatic approach. Since the usage message is already not very > consistent, if should not hurt to use it to extend <limitation> You vote to extend inconsistency instead of removing it? ;-) > Btw. For me, <message> was always meant as container for end user > messages, why else should it contain the 'lang' attribute? > Btw2. If you have a look at the context the usage of <message> isn't > really inconsistent. Its like fully qualified names, "org.foo.message" > is different to "org.bar.message". > > I think, we have still the same fundamental idea. "A perfect implementation > of DAIA should not need to code any information as plain text." (This is > already possible.) I hope we also agree with, that most implementations > aren't perfect and there is a need for text containers. I am not sure, maybe the introduction of messages was the wrong solution in the first place - where are the actual use cases of text containers? I have seen no convincing examples yet. Instead I only see misuses of plain text instead of explicit encoding of information. > I feel queasy, but as a sign of willing, I'm ready to bite the bullet. > If you can't stand with <message> extent the model with <content> or <lab > But please, check again if you can't find a smarter solution like, > changing message's the attribute 'errno' to 'id'. This will pay respect > to different ways of using <message> The name "message", "content", etc. does not matter that much to me. Reusing the current element, however, has the downside of 'errno' - which makes no sense inside of <limitation>. This could be solved by deprecating errno and introducing a dedicated error elememt: <error id="some:uri" /> <error id="some:uri"> <message lang="en">blablab</message> </error> <error> <message lang="en">bla</message> <message lang="de">blablab</message> </error> Without errno, the message element could be used for all plain text strings in DAIA, which includes debugging information (in the response, document, item, availability), names and explanations (in limitation, institution, department, storage, error). In addition to <storage>Magazin</storage> we would allow <storage> <message lang="de">Magazin</message> <message lang="en">stacks</message> </storage> And in addition to <limitation>not for everyone</limitation> we would have <limitation> <message lang="en">not for everyone</message> </limitation> The following mixed case should be forbidden, right?: <limitation> Nicht für alle Nutzer <message lang="en">not for everyone</message> </limitation> Jakob -- Jakob Voß <jak...@gb...>, skype: nichtich Verbundzentrale des GBV (VZG) / Common Library Network Platz der Goettinger Sieben 1, 37073 Göttingen, Germany +49 (0)551 39-10242, http://www.gbv.de |
From: Uwe R. <re...@he...> - 2013-03-15 13:07:26
|
Hi Am 15.03.2013 12:18, schrieb Jakob Voß: >> this looks very bad, because this is free text and not machine readable >> / parsable. > Yep, the only possible use-case is to show the extent to end-users and > hope that they can make use of it. There are three alternatives: > > 1. define a more precise/machine-readable format for extent > 2. don't include the extent at all, so it must be queried by other > means, if needed. > 3. encode each issue/volume/etc as one (hierarchical) DAIA item. Holding informations for journals are normed but not validated by the ZDB. (Is there something similar for non German librarys?) So they are implicit buggy and definitely not usable for a general conversion to a machine-readable format. For this reason I vote against having this extent(ion) in the DAIA model(1). For the same reason it isn't a good idea to extend the hierarchical model of DAIA (3) Let's have a look at a typical research situation: The patron places his query and the OPAC prepares the hit list. This List contains Books, Articles and Journals. # Books, are not our problem at the moment. # Articles, are the best argument for the extension of DAIA by Markus. # Journals, we have no information about which issue the patron is interested in. So we can only in rare situations a valid Information about the availability (available if all issues are present and not lendable, unavailable if there is no issue at all) Still important for the patron are informations like building, shelfmark and the human readable holding information. He should be able to interpret this and depending on this information if it is worth going to the library or not. So we are back to my initial example, which does not need any change of DAIA's model. > <limitation id="sparseHolding"> > 1983; 1985; 1988; 1990; 1992 - 1994; 1996 > </limitation> Uwe |
From: Uwe R. <re...@he...> - 2013-03-15 12:21:50
|
Hi Jakob, here we are again, at the clashing point of our different backgrounds. On the one side, you the top informed traveler between all standards and norms. On the other side me, the well grounded specialist for nonstandard practices in librarys, looking for pragmatic solutions. Let us find a good compromise again :-) You are right when you postulate > ... the term "message" is used inconsistently in the current > specification, .... <message> was intended for errors. But the element became to a swiss knife for small hacks. So I can't really agree with your conclusion > we may solve the issues without the <message> element. Here my pragmatic approach. Since the usage message is already not very consistent, if should not hurt to use it to extend <limitation> Yes your new element <content> may be a more proper way of modeling, but is is a additional element and worse it would the second which explicit is meant for plain text. For me this is a anti pattern to "Don't repeat yourself" Btw. For me, <message> was always meant as container for end user messages, why else should it contain the 'lang' attribute? Btw2. If you have a look at the context the usage of <message> isn't really inconsistent. Its like fully qualified names, "org.foo.message" is different to "org.bar.message". I think, we have still the same fundamental idea. "A perfect implementation of DAIA should not need to code any information as plain text." (This is already possible.) I hope we also agree with, that most implementations aren't perfect and there is a need for text containers. Your horror scenario seems to be the fuzzy role of an element, mine is every new element. ;-) I feel queasy, but as a sign of willing, I'm ready to bite the bullet. If you can't stand with <message> extent the model with <content> or <lab But please, check again if you can't find a smarter solution like, changing message's the attribute 'errno' to 'id'. This will pay respect to different ways of using <message> Uwe PS. > As said before, messages are not meant to be displayed to end-users at > all - neither from the message element's textual content nor derived > from an error id. Notifications of the sourced lending system are > > - either internal librarian-stuff, irrelevant to end-users > - or specific kinds of textual strings, which can better be encoded > in explicit elements (for instance label) Not really. In our application the messages should be encoded. But the end user messages in the OPACs (LBS3) of our librarys are generated with external logic and additional informations. For this reason there are to much possible variants to encode the properly. |
From: Jakob V. <vo...@gb...> - 2013-03-15 11:19:02
|
Hi Markus, Thanks for the comment! > this looks very bad, because this is free text and not machine readable > / parsable. Yep, the only possible use-case is to show the extent to end-users and hope that they can make use of it. There are three alternatives: 1. define a more precise/machine-readable format for extent 2. don't include the extent at all, so it must be queried by other means, if needed. 3. encode each issue/volume/etc as one (hierarchical) DAIA item. > One should be able to question a DAIA server on issue level or at least > on volume/year level and get correct availability responses. This only works if one knows journal and issue/volume/year and wants to know availability. It does not work if one only knows the journal and wants to know which issues are available. > Availability for journals usually uses OpenURL. So you can easily > combine a OpenURL request with a DAIA response. That's what I have done > here: > > http://www.doctor-doc.com/version1.0/daia.do?issn=0253-0465&date=2012&volume=105&issue=3&jtitle= > > This works perfect. No need to encode an additional "extent" element. You support the five OpenURL fields issn, date, volume, issue, and jtitle, right?) As far as I understand your data, the result however is not a single issue, but a stockinfo or holding record, such as http://www.doctor-doc.com/version1.0/stockinfo.do?stock=486 or http://www.doctor-doc.com/version1.0/stockinfo.do?holding=437 These record contain an extent element, e.g. "1999, Vol. 92 -"! So your database uses alternative 2 from the list above: Given a DAIA response and a DAIA Item, one can look up the full extent of an item. urn:x-domain:http://www.doctor-doc.com/version1.0/stockinfo.do?stock=486 => extent "1999, Vol. 92 -". It's a design decision to include more information about an item in DAIA or not: <item> <title>Krankenpflege</title> <issn>0253-0465</issn> <extent>1999, Vol. 92 -</extent> <NameOfUncleOfNeighborOfPublishersFriend>... ... It get's difficult if items have no URI to look up information with. In doubt, I'd also argue not to include more information. Given the ZDB example in my last may, one would need to supply item identifiers, e.g.: <document id="http://ld.zdb-services.de/resource/1060843-6"> <item id="http://ld.zdb-services.de/resource/item-epn/089000595"/> <department id="http://lobid.org/organisation/DE-24"/> <label>ZCa 6087</label> <available service="interloan"/> </item> http://ld.zdb-services.de/resource/item-epn/089000595 => extent "1983; 1985; 1988; 1990; 1992 - 1994; 1996". Jakob -- Jakob Voß <jak...@gb...>, skype: nichtich Verbundzentrale des GBV (VZG) / Common Library Network Platz der Goettinger Sieben 1, 37073 Göttingen, Germany +49 (0)551 39-10242, http://www.gbv.de |
From: <in...@fl...> - 2013-03-15 10:10:59
|
Hi this looks very bad, because this is free text and not machine readable / parsable. Journals need a different approach than other media types: One should be able to question a DAIA server on issue level or at least on volume/year level and get correct availability responses. It do not like the idea to encode availabilty information into a DAIA request. Availability for journals usually uses OpenURL. So you can easily combine a OpenURL request with a DAIA response. That's what I have done here: http://www.doctor-doc.com/version1.0/daia.do?issn=0253-0465&date=2012&volume=105&issue=3&jtitle= This works perfect. No need to encode an additional "extent" element. Markus Am 15.03.2013 09:57, schrieb Jakob Voß: > Hi, > > The Zeitschriftendatenbank (ZDB) is a good example for the use of an > additional "extent" element. See > > http://dispatch.opac.dnb.de/DB=1.1/CMD?ACT=SRCH&IKT=8506&TRM=1060843-6&PRS=HOL > > for a simple journal, held by three German libraries. This could be > expressed in DAIA like this: > > <document id="http://ld.zdb-services.de/resource/1060843-6"> > <item> > <department id="http://lobid.org/organisation/DE-24"> > Württembergische Landesbibliothek > </department> > <label>ZCa 6087</label> > <extent>1983; 1985; 1988; 1990; 1992 - 1994; 1996</extent> > <available service="interloan"/> > </item> > <item> > <department id="http://lobid.org/organisation/DE-7"> > Niedersächsische Staats- und Universitätsbibliothek Göttingen > </department> > <storage>FMAG</storage> > <label>ZB 83244</label> > <extent>1983</extent> > <available service="interloan"/> > </item> > <item> > <department id="http://lobid.org/organisation/DE-14"> > Sächsische Landesbibliothek - Staats- und Universitätsbibliothek > Dresden > </department> > <extent>1990 [Dpl. ZDB</extent> > <available service="interloan"/> > </item> > </document> > > The ZDB already provides bibliographic data about journals as Linked > Open Data, e.g., but no holding information yet: > > http://ld.zdb-services.de/resource/1060843-6.rdf > > Cheers > Jakob > |