DAIA extensions - Revision history

JakobVoss at 12:26, 3 April 2013

2013-04-03T12:26:54Z

Jrochkind: /* Deliver */

2009-10-28T02:48:14Z

‎Deliver

Jrochkind: /* Recall */

2009-10-28T02:45:20Z

‎Recall

Jrochkind: /* Recall */

2009-10-28T02:44:13Z

‎Recall

Jrochkind: /* Recall */

2009-10-28T02:42:50Z

‎Recall

Jrochkind: /* Recall */

2009-10-28T02:41:10Z

‎Recall

Jrochkind: /* Deliver */

2009-10-28T02:33:15Z

‎Deliver

Jrochkind: /* Deliver */

2009-10-28T02:32:06Z

‎Deliver

Jrochkind: /* Deliver */

2009-10-28T02:31:05Z

‎Deliver

Jrochkind: /* Recall */

2009-10-28T02:27:52Z

‎Recall

@@ Line 1: / Line 1: @@
-This page collects some proposed service types and other suggestions as extension to the [http://purl.org/NET/DAIA  Document Availability Information API].
+This page collected some proposed '''service types''' and other suggestions as extension to the [http://purl.org/NET/DAIA  Document Availability Information API]. See [https://github.com/gbv/dso Document Service Ontology (DSO)] for a more up-to-date approach.
 == Additional Service types ==
 === Request ===
@@ Line 13: / Line 41: @@
 Where possible, you should not use the 'request' service, but should instead use a service expressing a more specific action availability.  However, actually existing ILS's can make it very hard to figure out what more specific actions are available, and it may still be useful to advertise the ILS 'request' function, this service represents that.
-:Looks like a super-class of all service types with meaning "unknown". In this case we may better make the service field optional so if you can specify an unknown service. -- [[User:JakobVoss|JakobVoss]] 02:12, 29 September 2009 (PDT)
+:Looks like a super-class of all service types with meaning "unknown". In this case we may better '''make the service field optional''' so if you can specify an unknown service. -- [[User:JakobVoss|JakobVoss]] 02:12, 29 September 2009 (PDT)
 ::That might work, as long as it's possible to specify a user-displayable label for the service. Won't be able to be understood/acted upon by software, but the user can still be told this is, say, a generic 'Request'.
@@ Line 26: / Line 55: @@
 :::: Yes, I think I can buy this, seems workable, thanks for explaining.  Although I'd clarify I don't want to say why an item _isn't_ available. I in fact want to say that an item IS available, after a specified delay, but you can't just take it off the stacks, the only way you can get it is by pressing a button.  This is in general something I'm not sure how to do in DAIA, a thread throughout these new services. It's not always enough to say that 'loan' is available, sometimes I need to make sure a user knows they can't just pull it off the stacks themselves, the ONLY way to access 'loan' is to access this link here. I'm not sure how to do that in DAIA, so the system can make sure to let the user know this? Or maybe it's just indicated by 'loan' being available but NOT 'presentation'.  My end system consuming DAIA knows that if 'loan' is avaialable but not 'presentation', it should warn the user "don't go try to pull this off the stacks yourself, follow this link instead." Or maybe I DO need an 'obstacle' field, I kind of like that. But I don't think the current DAIA schema gives me any way to add such an 'obstacle' field while still having XML that validates against the DAIA schema? [[User:Jrochkind|Jrochkind]] 19:41, 27 October 2009 (PDT)
 :::: Additionally, I've been told that in my library users want to know if by accessing 'loan' they are going to be triggering an early return from someone who has it out now. Some users will decide they don't want the book that bad (especially cause the person who they got it from can then trigger an early return for THEM, the chances of them being able to keep it long are not that great. Not sure what to do with this either. Except it again makes me think of an 'obstacle' field maybe. [[User:Jrochkind|Jrochkind]] 19:27, 27 October 2009 (PDT)

@@ Line 39: / Line 39: @@
 :::: Hmm. I hear you. But we have some items for some patrons that can be checked out, but you've got to go get them from the stacks yourself. There are other items for certain patrons that can be checked out, and you can click a button and have them waiting at the circ desk. There are other items that can be checked out, and you can have them delivered to your office.  The end result of all of these things could be considered a 'loan' -- but it matters to the user which of these things are available, the difference in convenience may effect their decision of whether to access the item at this time or not.  How should this be encoded in DAIA so it can be presented to the user? I'm trying to take a stab at it, I hear your critique, but I'm still not sure the better way to do it. I see how to create new services simply by creating new URI's for them in DAIA -- you mention 'sub-service', but how can I extend DAIA with a 'sub-service', what does this look like?
 * Similarly: It matters to the user whether they can do 'presentation' by simply going to the stacks and picking it up themselves, and reading it in the library location of their choice, or whether they can only access 'presentation' by filing a request, waiting a certain amount of time, and then viewing the material during certain business hours of a special reading room in that special reading room. (Another actual situation in my actual library). How should this be represented in a DAIA response, so it can be communicated to the user?  I am not sure. Any ideas? [[User:Jrochkind|Jrochkind]] 19:33, 27 October 2009 (PDT)
 === Excerpt ===

@@ Line 25: / Line 25: @@
 :::This should better be encoded in the 'delay' and 'queue' attributes. If I understand you right, you want to encode whether an item is hold by someone else or is not available for some other reason. If we start encoding this, we can build an ontology of reasons why I cannot get a book (someone else holds it, it's a the bookbinder, the cat of the librarian is sitton on it...) which is not purpose of core DAIA. Maybe you could add a custom 'reason' field to unavailable or an 'obstacle' field to available/unavailable. -- [[User:JakobVoss|JakobVoss]] 01:39, 23 October 2009 (PDT)
 :::: Yes, I think I can buy this, seems workable, thanks for explaining.  Although I'd clarify I don't want to say why an item _isn't_ available. I in fact want to say that an item IS available, after a specified delay, but you can't just take it off the stacks, the only way you can get it is by pressing a button.  This is in general something I'm not sure how to do in DAIA, a thread throughout these new services. It's not always enough to say that 'loan' is available, sometimes I need to make sure a user knows they can't just pull it off the stacks themselves, the ONLY way to access 'loan' is to access this link here. I'm not sure how to do that in DAIA, so the system can make sure to let the user know this? Or maybe it's just indicated by 'loan' being available but NOT 'presentation'.  My end system consuming DAIA knows that if 'loan' is avaialable but not 'presentation', it should warn the user "don't go try to pull this off the stacks yourself, follow this link instead." Or maybe I DO need an 'obstacle' field, I kind of like that. But I don't think the current DAIA schema gives me any way to add such an 'obstacle' field while still having XML that validates against the DAIA schema? [[User:Jrochkind|Jrochkind]] 19:41, 27 October 2009 (PDT)
-:::: Additionally, I've been told that in my library users want to know if by accessing 'loan' they are going to be triggering an early return from someone who has it out now. Some users will decide they don't want the book that bad (especially cause the person who they got it from can then trigger an early return for THEM, the chances of them being able to keep it long are not that great. Not sure what to do with this either. [[User:Jrochkind|Jrochkind]] 19:27, 27 October 2009 (PDT)
+:::: Additionally, I've been told that in my library users want to know if by accessing 'loan' they are going to be triggering an early return from someone who has it out now. Some users will decide they don't want the book that bad (especially cause the person who they got it from can then trigger an early return for THEM, the chances of them being able to keep it long are not that great. Not sure what to do with this either. Except it again makes me think of an 'obstacle' field maybe. [[User:Jrochkind|Jrochkind]] 19:27, 27 October 2009 (PDT)
 === Deliver ===

@@ Line 24: / Line 24: @@
 ::So are you suggesting this shouldn't be a service of it's own, but instead should just be indicated in the 'delay' and user-displayable comments on the actual end-purpose service, that a 'recall' is possible?  One thing is that in my library I am told that the user wants to know if they will be recalling the item from someone else or not before making the request.
 :::This should better be encoded in the 'delay' and 'queue' attributes. If I understand you right, you want to encode whether an item is hold by someone else or is not available for some other reason. If we start encoding this, we can build an ontology of reasons why I cannot get a book (someone else holds it, it's a the bookbinder, the cat of the librarian is sitton on it...) which is not purpose of core DAIA. Maybe you could add a custom 'reason' field to unavailable or an 'obstacle' field to available/unavailable. -- [[User:JakobVoss|JakobVoss]] 01:39, 23 October 2009 (PDT)
-:::: Yes, I think I can buy this, seems workable, thanks for explaining.  Although I'd clarify I don't want to say why an item _isn't_ available. I in fact want to say that an item IS available, after a specified delay, but you can't just take it off the stacks, the only way you can get it is by pressing a button.  This is in general something I'm not sure how to do in DAIA, a thread throughout these new services. It's not always enough to say that 'loan' is available, sometimes I need to make sure a user knows they can't just pull it off the stacks themselves, the ONLY way to access 'loan' is to access this link here. I'm not sure how to do that in DAIA, so the system can make sure to let the user know this? Or maybe it's just indicated by 'loan' being available but NOT 'presentation'.  My end system consuming DAIA knows that if 'loan' is avaialable but not 'presentation', it should warn the user "don't go try to pull this off the stacks yourself, follow this link instead."[[User:Jrochkind|Jrochkind]] 19:41, 27 October 2009 (PDT)
+:::: Yes, I think I can buy this, seems workable, thanks for explaining.  Although I'd clarify I don't want to say why an item _isn't_ available. I in fact want to say that an item IS available, after a specified delay, but you can't just take it off the stacks, the only way you can get it is by pressing a button.  This is in general something I'm not sure how to do in DAIA, a thread throughout these new services. It's not always enough to say that 'loan' is available, sometimes I need to make sure a user knows they can't just pull it off the stacks themselves, the ONLY way to access 'loan' is to access this link here. I'm not sure how to do that in DAIA, so the system can make sure to let the user know this? Or maybe it's just indicated by 'loan' being available but NOT 'presentation'.  My end system consuming DAIA knows that if 'loan' is avaialable but not 'presentation', it should warn the user "don't go try to pull this off the stacks yourself, follow this link instead." Or maybe I DO need an 'obstacle' field, I kind of like that. But I don't think the current DAIA schema gives me any way to add such an 'obstacle' field while still having XML that validates against the DAIA schema? [[User:Jrochkind|Jrochkind]] 19:41, 27 October 2009 (PDT)
 :::: Additionally, I've been told that in my library users want to know if by accessing 'loan' they are going to be triggering an early return from someone who has it out now. Some users will decide they don't want the book that bad (especially cause the person who they got it from can then trigger an early return for THEM, the chances of them being able to keep it long are not that great. Not sure what to do with this either. [[User:Jrochkind|Jrochkind]] 19:27, 27 October 2009 (PDT)

@@ Line 24: / Line 24: @@
 ::So are you suggesting this shouldn't be a service of it's own, but instead should just be indicated in the 'delay' and user-displayable comments on the actual end-purpose service, that a 'recall' is possible?  One thing is that in my library I am told that the user wants to know if they will be recalling the item from someone else or not before making the request.
 :::This should better be encoded in the 'delay' and 'queue' attributes. If I understand you right, you want to encode whether an item is hold by someone else or is not available for some other reason. If we start encoding this, we can build an ontology of reasons why I cannot get a book (someone else holds it, it's a the bookbinder, the cat of the librarian is sitton on it...) which is not purpose of core DAIA. Maybe you could add a custom 'reason' field to unavailable or an 'obstacle' field to available/unavailable. -- [[User:JakobVoss|JakobVoss]] 01:39, 23 October 2009 (PDT)
-:::: Yes, I think I can buy this, seems workable, thanks for explaining.  Although I'd clarify I don't want to say why an item _isn't_ available. I in fact want to say that an item IS available, after a specified delay, but you can't just take it off the stacks, the only way you can get it is by pressing a button.  This is in general something I'm not sure how to do in DAIA, a thread throughout these new services. It's not always enough to say that 'loan' is available, sometimes I need to make sure a user knows they can't just pull it off the stacks themselves, the ONLY way to access 'loan' is to access this link here. I'm not sure how to do that in DAIA, so the system can make sure to let the user know this? [[User:Jrochkind|Jrochkind]] 19:41, 27 October 2009 (PDT)
+:::: Yes, I think I can buy this, seems workable, thanks for explaining.  Although I'd clarify I don't want to say why an item _isn't_ available. I in fact want to say that an item IS available, after a specified delay, but you can't just take it off the stacks, the only way you can get it is by pressing a button.  This is in general something I'm not sure how to do in DAIA, a thread throughout these new services. It's not always enough to say that 'loan' is available, sometimes I need to make sure a user knows they can't just pull it off the stacks themselves, the ONLY way to access 'loan' is to access this link here. I'm not sure how to do that in DAIA, so the system can make sure to let the user know this? Or maybe it's just indicated by 'loan' being available but NOT 'presentation'.  My end system consuming DAIA knows that if 'loan' is avaialable but not 'presentation', it should warn the user "don't go try to pull this off the stacks yourself, follow this link instead."[[User:Jrochkind|Jrochkind]] 19:41, 27 October 2009 (PDT)
 :::: Additionally, I've been told that in my library users want to know if by accessing 'loan' they are going to be triggering an early return from someone who has it out now. Some users will decide they don't want the book that bad (especially cause the person who they got it from can then trigger an early return for THEM, the chances of them being able to keep it long are not that great. Not sure what to do with this either. [[User:Jrochkind|Jrochkind]] 19:27, 27 October 2009 (PDT)

@@ Line 37: / Line 37: @@
 :::There is a difference between deliver to a circulation desk for use in the rooms of the library (presentation) and for loaning. Deliver to an office or at home is a different kind of service that implies loan. To distinguish deliver to circulation desk and self-pick up with open-access shelving we may need another method. -- [[User:JakobVoss|JakobVoss]] 01:39, 23 October 2009 (PDT)
-:::: Hmm. I hear you. But we have some items for some patrons that can be checked out, but you've got to go get them from the stacks yourself. There are other items for certain patrons that can be checked out, and you can click a button and have them waiting at the circ desk. There are other items that can be checked out, and you can have them delivered to your office.  The end result of all of these things could be considered a 'loan' -- but it matters to the user which of these things are available, the difference in convenience may effect their decision of whether to access the item at this time or not.  How should this be encoded in DAIA so it can be presented to the user? I'm trying to take a stab at it, I hear your critique, but I'm still not sure the better way to do it. I see how to create new services simply by creating new URI's for them in DAIA -- you mention 'sub-service', but how can I extend DAIA with a 'sub-service', what does this look like? [[User:Jrochkind|Jrochkind]] 19:31, 27 October 2009 (PDT)
+:::: Hmm. I hear you. But we have some items for some patrons that can be checked out, but you've got to go get them from the stacks yourself. There are other items for certain patrons that can be checked out, and you can click a button and have them waiting at the circ desk. There are other items that can be checked out, and you can have them delivered to your office.  The end result of all of these things could be considered a 'loan' -- but it matters to the user which of these things are available, the difference in convenience may effect their decision of whether to access the item at this time or not.  How should this be encoded in DAIA so it can be presented to the user? I'm trying to take a stab at it, I hear your critique, but I'm still not sure the better way to do it. I see how to create new services simply by creating new URI's for them in DAIA -- you mention 'sub-service', but how can I extend DAIA with a 'sub-service', what does this look like?
 === Excerpt ===

← Older revision		Revision as of 02:31, 28 October 2009
Line 36:		Line 36:

	:::There is a difference between deliver to a circulation desk for use in the rooms of the library (presentation) and for loaning. Deliver to an office or at home is a different kind of service that implies loan. To distinguish deliver to circulation desk and self-pick up with open-access shelving we may need another method. -- [[User:JakobVoss\|JakobVoss]] 01:39, 23 October 2009 (PDT)		:::There is a difference between deliver to a circulation desk for use in the rooms of the library (presentation) and for loaning. Deliver to an office or at home is a different kind of service that implies loan. To distinguish deliver to circulation desk and self-pick up with open-access shelving we may need another method. -- [[User:JakobVoss\|JakobVoss]] 01:39, 23 October 2009 (PDT)
		+
		+	:::: Hmm. I hear you. But we have some items for some patrons that can be checked out, but you've got to go get them from the stacks yourself. There are other items for certain patrons that can be checked out, and you can click a button and have them waiting at the circ desk. There are other items that can be checked out, and you can have them delivered to your office. The end result of all of these things could be considered a 'loan' -- but it matters to the user which of these things are available, the difference in convenience may effect their decision of whether to access the item at this time or not. How should this be encoded in DAIA so it can be presented to the user? I'm trying to take a stab at it, I hear your critique, but I'm still not sure the better way to do it. [[User:Jrochkind\|Jrochkind]] 19:31, 27 October 2009 (PDT)

	=== Excerpt ===		=== Excerpt ===