Examples of using extended elements

[Gerardo Capiel]

Does anyone have any examples of using extended elements, such as X_subject?  Can you have multiple attribute with the same key?  For example, if we have a learning resource in multiple formats available at one resource URL, can we put in multiple X_format attributes?

[Grata, Walt]

You can't have multiple attributes with the same key but you could do something like

{

   <<Standard Envelope Stuff>>,

   "X_format" :["format1","format2","format3"]

[Midgley, Steve]

You could pack multiple schema formats for the same record in the same envelope using a technique like Walt describes.. But I think the original thinking was that for every format you would send a new envelope with a distinct payload_schema description. So the same resource from the same sender having multiple envelopes with identical information but in different formats is fine.

 

Input welcome!

Steve

 

 

 

---

From: learnin...@googlegroups.com [learnin...@googlegroups.com] On Behalf Of Grata, Walt [walt.gr...@adlnet.gov]
Sent: Tuesday, October 11, 2011 9:10 AM
To: learnin...@googlegroups.com
Subject: Re: [Learningreg-Dev] Examples of using extended elements

[Jim Klo]

Actually, while this is allowed, extended attributes are discouraged as there's no guarantee that they will get preserved by a harvest interface according to the way I interpret the spec.

From the way I interpret your situation. I'd either:
1. Declare the ext attribs in "keys"
2. Describe the ext attribs in the metadata payload (linked or inline). The payload schema format should match the metadata, not the resource itself. You can use any format you want including JSON.
3. Do both

Slice is currently the only service that you could use to query by keys/tags anyways, and I think it ignores the X_ attributes.

In the future there will most likely be ways to index the entire envelope. With a real query language. We've already experimented with a Lucene/Solr based solution, but that is currently not part of any release.

- Jim

Sent from my iPhone

[Daniel Rehak]

I think we need to know better what you are trying to accomplish, rather than discussing "how" first.

You said you had multiple formats for the same object at the same URL.

The LR submission is about the metadata for the object, not the object.  It seems that what you need is to have the metadata for the object indicate that it is available in multiple formats.  Metadata goes into the payload and you would do this based on how the metadata specifies multiple formats.

If you have different formats of metadata (say LOM vs DC) for the same object, then you would be using the payload schema and different submissions, one for each metadata record (and those records would point to the different formats of the object).

So maybe best if you can explain what you are trying to do.

    - Dan

--
Daniel R. Rehak, Ph.D.

Learning Registry Technical Architect

ADL Technical Advisor

Skype: drrehak
Email:  daniel...@learningregisrry.org
            daniel.r...@adlnet.gov
Twitter: @danielrehak
Web:   learningregistry.org

Google Voice: +1 412 301 3040

[Gerardo Capiel]

Thanks for all the input.  The use case is as follows:

Bookshare is the largest library of accessible ebooks for people with print disabilities (e.g. blind, dyslexic, cerebral palsy).  Thanks to an award from with the Office of Special Education Program (OSEP) at the Department of Education, we serve over 150K students in the U.S.  Bookshare has over 120K books and textbooks available in DAISY 3 text (www.daisy.org) format, which is similar to EPUB 3, and BRF (digital Braille Ready Format).  Students consumer the content via large print (for low vision), via their refreshable braille display, or Text-To-Speech.

Our catalog is available via our REST API (developer.bookshare.org) and we are developing a data pump to push information about our NIMAC sourced textbooks and OERs into LR. 

I am tagging via keys the resources as "Accessible" and also putting in other metadata about the book/textbook into the keys.  We have mapped the LR and Bookshare data models at:

https://wiki.benetech.org/display/BSO/LearningRegistry+Bookshare+Mapping

Advice into how we are using keys in addition to extended elements (e.g. "X_Format") and whether we should use one envelope would be great.

[Midgley, Steve]

Ah – I think get it. I believe what you want to do is instead of submitting those x_ attributes is to actually submit a “payload” with metadata describing those elements. You can submit that in any format you want –do you use a particular standard metadata format internally already? Like Dublin Core or LOM or whatever?

 

Whatever you choose, you would basically indicate in that format (in the LR payload) that each resource is available in multiple formats. In pseudo-metadata:

 

{standard lr-envelope header stuff here…,

“resource_data”:”<xml><isbn>123</isbn><formats><format type=”daisy”><format type=”brf”><format type=”epub3”></formats></xml>”

}

 

Obviously that xml is total mockup – don’t use that, but whatever format (ideally a standardized one) you find that lets you describe your materials, put it in the “resource_data” field (what we often call the payload) and then put a description of that format in “payload_schema”..

 

Steve

[Jim Klo]

Steve is right on the money with your answer. 

You even mentioned that there is already a REST api available.  If there is a REST response that provides this sort of metadata - you could:

a. use a linked payload and reference the appropriate URI that would return the metadata details in the payload_locator

b. include the response from that API inline as the resource_data payload.

This might be a way to shortcut from either translating to something like DC, LOM, etc. Especially if your API already adheres to some standard that might exist.

- Jim

Jim Klo

Senior Software Engineer

Center for Software Engineering

SRI International

[Daniel Rehak]

Agreed.  The x_attributes are for things that LR needs and are independent of the content.  They are not for metadata.    Metadata should go into the payload and you should be using on of the standard metadata formats.  In your case, there is a very good standard on how to mark up all sorts of accessibility called "access for all".

I know we have some folks from WGBH on the list -- they have a lot of good experience in metadata for accessibility of learning content and were key players in developing this standard.

    - Dan

[Gerardo Capiel]

OK, we will look at using the payload for the metadata.  The question is how much the metadata in the payload do we also want to have in the keys.  My understanding is that end users will be able to query/slice based on the tags, but not the payload information.  Our current plan is to include in the tags:

- "Accessible", "AIM"
- add keys "DAISY", "Z39.86" and "DAISY 3" if available
- add keys "Braille" and "BRF" if available
- ISBN13, Title, Author(s), Publisher, Categorie(s)

This would allow a user to query for any type of accessible format, specific types of accessible formats (e.g. DAISY 3) and certain titles, ISBNs, authors, publishers or categories.

In the payload, perhaps we would include more detailed book metadata based on the OPDS schema ( http://opds-spec.org/ ) and accessibility metadata either based on the "AccessForAll" schema ( http://www.imsglobal.org/accessibility/accdrdv2p0/html/ISO_ACCDRDv2p0_InfoModelv1.html or http://dublincore.org/accessibilitywiki/ ) or the proposed ONIX accessibilty features schema ( referenced at http://wiki.creativecommons.org/LRMI/Face-to-Face#Accessibility_.2810:15-11.29 ).

[Midgley, Steve]

I think those tags are good ones. Assuming categories have some subject related content that makes it even better – but helpful to have categories like “literature” or “algebra” in the keys where possible.

 

There is some duplication but it is hopefully a healthy inefficiency for the time being.. “Deep envelope inspection” is technically possible too for well defined formats, but that’s not being done right now as you observe.

 

Steve

 

 

From: learnin...@googlegroups.com [mailto:learnin...@googlegroups.com] On Behalf Of Gerardo Capiel
Sent: Wednesday, October 12, 2011 12:03 AM
To: learnin...@googlegroups.com
Subject: [Learningreg-Dev] Re: Examples of using extended elements

 

OK, we will look at using the payload for the metadata.  The question is how much the metadata in the payload do we also want to have in the keys.  My understanding is that end users will be able to query/slice based on the tags, but not the payload information.  Our current plan is to include in the tags: