Metadata Records & RDF: Validation, Record Scope, State, and the Statement-centric Model
CC Attribution 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Johnson, Thomas
Advocates for the use of RDF as a model for metadata in the cultural heritage sector have frequently spoken of the death of the “record”. Indeed, the shift from a document-centric approach to one based on identified resources and atomic statements is an important one. Yet current work on validation as well as requirements for day-to-day metadata management and attribution point back to aspects of a record-driven worldview. This session will address some historical views of records, contrasting them with the formal model adopted by RDF 1.1 and commonly accepted best practices for Linked Data. Practical implications of the RDF model will be explored, with questions raised regarding the management of state, mutability, and “record” workflows. A provisional approach for managing RDF resources and graphs in record-like contexts is proposed, with connections to RDF Shapes, DC Application Profiles, and Linked Data Platform. Use cases from the Digital Public Library of America will be presented as illustrative examples.
 So wow, what a talk to follow, huh? So I guess this is the second to last talk of the day and it's going to be a bit of a rant too. So I guess my hope for the rest of SWIB is that I can say something useful and meaningful as a follow-up to Karen and that Valentin can bring us down into something that's good to part on. So as was mentioned in the introduction, I work a lot on open source software and a lot of what I'm about to talk about is coming out of an effort to write a framework for representing RDF graph data in a way that developers can use it in application development in ways that they would normally expect to work with. So that's a little bit of context for where this is coming from. So to begin with, I want to talk to you about graphs. Do you know about graphs? We talk about them a lot. We don't always talk with a lot of clarity about what graphs are. So let's take a step back and look at a graph model for a second. Graphs are, well, let's see if I can get the slide to change. Graphs are mathematical objects. They have nodes and they have edges that connect the nodes. And this will be the only math slide with the embarrassing kind of handwritten chalk motif. But these are mathematical things and they're defined in RDF as mathematical things. And the graphs we talk about in linked data look like this. They have subject, predicate, and object, and your nodes are defined by the subjects and objects, and your edges are defined by the predicates. And off you go. And they also look like this. And if we do that, that is to say if we remove a statement, what we've done isn't to change the graph so much as to create a new slightly different one with one fewer edge and as many as two fewer nodes. Because the graph is defined in terms of its member triples, that is to say it's a set of its member triples, these changes aren't edits. And that's a good thing because if we want to find out what the difference is between two graphs or what the difference in meaning is, semantically, in what we're claiming in each of them, we have a simple model for that. And the model is statements in, statements out. This is one reason why we as a community have been so eager to advance graphs as a way of expressing data because we can capture meaning at this level. Adding and removing and comparing is easy and it's an attractive prospect. And I'm not here to tell you that we shouldn't do that. Another reason is that if I have this, these are triples that I know about and you have this or another one of my systems has this, putting them together is as easy as merging the graphs, simply appending the one graph to the other. So combining this idea with the web and follow your nose conventions that let me find your graph, we have linked data and it's taken us quite far. It's taken us here to all of the things that we've heard about during this conference. But one thing that I've noticed is that we're talking a lot about rewrite data workflows and information management workflows and while the community has gotten really good at publishing and consuming linked data, questions about how we manage it are mostly open. We've seen implementations here that serialize JSON-LD into no SQL data stores. We've seen implementations that serve REST APIs from Elasticsearch. We have object graph modelers represented here. We have linked data platform and ad hoc patch formats. This looks to me like the community grappling with how to manage graphs through stateful lenses. So this is coming from the section of the RDF concepts and abstract syntax document, which is an interesting read if you haven't read it. The RDF data model is atemporal. Graphs are static snapshots of information. However, RDF graphs can express information about events and temporal aspects of other entities given appropriate vocabulary terms. Since graphs are defined as mathematical sets, adding or removing triples from RDF graph yields a different graph. So this problem is called out directly in RDF 1.1 in this section called RDF and change over time. My claim here is that we need a robust account of a thing that's at once as simple and complex as change in the resources and the descriptions of them that we manage. Again, this atemporal model is a good thing. And besides unavoidable, once you've published some linked open data, retraction isn't part of the ecosystem. It's on the web. Other people have pulled it down, presumably. Otherwise, you might be wasting your time with the publishing thing. And those assertions are out there, and there's no system for you to say that assertion is invalidated. So, a 2009 paper that has influenced my thinking about this pretty significantly makes a similar observation about XML documents. Since documents, including in data contexts, are defined as strings, which are in turn defined as sets of characters, how can we account for workflows that rely on those documents to change? So document modification seems to be routine and widespread. Editing is a familiar practice to almost everyone. And revision is a fundamental feature of publishing workflows. Yet document modification would appear to be an illusion. Common accounts of what documents are seem to imply that documents cannot undergo genuine modification. So the point of this isn't to say that those workflows don't exist. That's not the point of the paper, and it's not my point here. They clearly do exist. The point is simply to prod us into thinking about some important things which we might have missed by failing to understand how this problem interacts with our data model. These stateless things interact with our data model. So both, possibly we're missing both things that we should understand about how we tackle information life cycles and information management use cases like the sorts of things that Karen is pointing to with users that we may be overlooking amidst our bad faith rhetoric about the death of the record. So let's talk about metadata records for a minute. I use this term records deliberately in part because I know that it will raise hackles among some of the people listening to this. And in part because I think that it stands a chance of inviting a group of people and practices that have been alienated by the linked data community back into the fold. So let me explain what I mean by a record in web friendly terms. So this is the conference of HTTP methods. Here our happy client sends a request to a non-descript web server saying, give me one Tim Berners-Lee please. The non-descript web server responds 200 okay and sends back some data in a response body. In the responses and RDF representation as in this case this is Tim Berners-Lee's FOPH file. It's his profile description for the W3C. It's customary to return some statements about the requested resource. So we get a nice description of Tim Biel's personal profile document, his FOPH file. And we're told that the primary topic of the document is Tim Biel. When constructing such a response one common pattern is to return all of the triples that the server knows about where the requested resource is the subject. So that means you return a graph generated on the fly and it includes the edges and nodes that are adjacent only to the connected resource. Usually this is extended to include connected resources that don't have requestable URIs of their own. So blank nodes or hash URIs, resources that are identified by hash URIs that have a base that's shared with the other resource. And anything adjacent to them also gets included possibly many triples out because otherwise there's no way to go collect that data from another follow your nodes style request. And this is also a common implementation for the loosely specified Sparkle describe. This word describe is an interesting one and we'll come back to it. Another common pattern, an alternate pattern is to serve out a graph with many subjects deemed to be primarily about quote unquote a given subject. This is what we see in the Tim Berners-Lee example. So while there are many unique subjects in the graph that's returned, Berners-Lee himself has an amorphously special status here. But in either case, what is retained when we send the next request and get a different graph is the aboutness. The graph returned is in some meaningful sense of representation of the resource it describes. So this starts to get at what I mean by record in RDF. RDF source is an interesting concept that's not terribly well known. I know of three references to this concept so I'm just going to jump in with the first one which follows immediately from the previous reference to RDF and change over time this section in 1.1 concepts. And this is kind of a funny passage. We informally use the term RDF source to refer to a persistent yet mutable source or container for RDF graphs. A source is a resource that may be said to have a state that can change over time. A snapshot of the state can be expressed as an RDF graph. For example, any web document that has an RDF bearing representation may be considered an RDF source. Like all resources, RDF sources may be named with IRIs and therefore described in other RDF graphs. So in some sense here what's being said is that an RDF source is a time sequence of graphs or maybe it's easier to think of it as a container that at any given time during its life cycle you can ask for its current state and it will give that back to you. And this is an interesting concept when we juxtapose it against the assumption that what we're dealing with in linked data is a giant global graph. So these are stateful resources. In data platform, a recent W3C specification for handling restful interactions, that is to say stateful interactions with RDF documents, RDF descriptions, uses this concept pretty heavily. So an LDPR in this context is just any resource that conforms to a base set of HTTP interaction patterns described in LDP. So you send a certain kind of request and it gives a certain kind of response and there's a set of assumptions built into LDP that makes it possible for you to classify things as LDPRs, LDP resources. LDP, RDF sources are a subset of this. Basically they're the subset that contain RDF documents as opposed to say binary blobs or videos or images or what have you. So an LDPR whose state, LDPRDF sources and LDPR whose state is fully represented in RDF corresponding to an RDF graph. So what this means is if you send that get request, you get back the current state of the resource and because of the way that LDP's interaction patterns are defined otherwise, assuming that the server supports update, you have a set of methods also for updating that resource. This is the only other reference that I know of to RDF sources in any kind of formal writing anywhere. If you know of any others, I would like to know. The entire semantics it says, this is from the RDF 1.1 semantics which is a less pleasant read unless you have a certain bent. So the entire semantics applies to RDF graphs, not to RDF sources. And RDF source has semantic meaning only through the graph that is its value at a given time or in a given state. So it has semantics for previous values as well. But graphs cannot change their semantics with time. So the thing to take away from this is that this RDF source concept is really talking about different graphs for any given instant that you might access them. So what are examples of things that might look like RDF sources? Any web resource that returns an RDF description and RDF serialization is going to look an awful lot like an RDF source. This includes HTML documents with embedded micro data. Named graphs, this is an interesting one. But it kind of suggests a way that we might move forward with stateful management of our resources. Sparkle describe and Sparkle construct both return RDF graphs and have stable identifiers and assuming that you're running these queries against a dataset, you can expect those queries to give some kind of representation of something reflected in the dataset. So API resources like some of the ones we've seen in LoweBit and the like. MVC model objects, MVC is model view controller for the non-developers. This is like an object that you use to marshal data towards your user interfaces and update it, et cetera. Also I think, and Ruben can correct me if he disagrees, but I think triple pattern fragments fall into this category as well and probably lots of other things. So some of those things don't really make a lot of sense to think of as records. So what I'm saying here isn't necessarily that an RDF source aligns closely with a record. Construct in particular is a particularly odd example since it's possible to induce the server to include whole bunches of data that's totally new and originates in your request in the response contingent on the contents of the dataset. You can do interesting things with construct. But let me suggest some qualities that we might want to use to separate sources that are not very record like from those that might be. So records we might think of as having consistent aboutness. Some of those source types might fit that bill. Records we would hopefully want to think of as having stable scope. So if we were to pull down a record, we would sort of expect the same kind of range of descriptions to fit in. And we would expect records to be amenable to managed life cycles. So what I mean by this is if we have information processes that we're trying to support with our applications, information processes in our libraries, we want to be able to interact with the records in a consistent way. We want them to do something for our life, for, we want their life cycle to represent a workflow in a meaningful way. So in some sense, you might think of these records as subsets of a larger graph and we can do that juxtaposition thing and still have our lovely global graph structure but also have recourse to managing them as part of a process. Your mileage may vary on this. In thinking about record use cases, I found it useful to look back at Dublin Core Abstract model and description set profiles. There's some interesting things here. The abstract model of DC metadata description sets is as follows and you can kind of draw a nice picture between description sets as closely aligned with the RDF source concept, descriptions as that first option that we dealt with earlier where the subject is always the same. The descriptions in DCAM look like key value pairs that are all about the same subject, that's one to one principle. And also there's this concept of statement. Below this, DCAM starts to get a little bit fussy with some, what I think are just simply out of date formalisms about what values look like and there's value surrogate reference here and you can probably safely stop reading past this point. But there's also this interesting reference where description sets are treated as separate from records, where records are documents that represent a snapshot of a description set, which I found very interesting. So that's my description set takeaway. And with application profiles, I think we have an opportunity to dig a little deeper on how we can scope records. So I think there's, oh that's just DPLA math, we'll skip that. So I think there's an important distinction that we need to make between human actionable like that, application profiles and machine actionable ones. Description set profiles is an interesting start towards some of this, towards the validation side but I'm actually, I want to call on us to be looking at ways to identify records as information management resources from larger graphs actively, not just in terms of looking at them and validating whether they fit a certain shape but also picking the aboutness of resources out from our application profiles from our larger graphs. So that's, yeah I think that's it. So I'm interested in talking about next steps for this and I think we have time for questions, yes? Of course we have, let's take a call.
 So wow, what a talk to follow, huh?  So I guess this is the second to last talk of the day and it's going to be a bit of a  rant too.  So I guess my hope for the rest of SWIB is that I can say something useful and meaningful  as a follow-up to Karen and that Valentin can bring us down into something that's good  to part on.  So as was mentioned in the introduction, I work a lot on open source software and a  lot of what I'm about to talk about is coming out of an effort to write a framework for  representing RDF graph data in a way that developers can use it in application development  in ways that they would normally expect to work with.  So that's a little bit of context for where this is coming from.  So to begin with, I want to talk to you about graphs.  Do you know about graphs?  We talk about them a lot.  We don't always talk with a lot of clarity about what graphs are.  So let's take a step back and look at a graph model for a second.  Graphs are, well, let's see if I can get the slide to change.  Graphs are mathematical objects.  They have nodes and they have edges that connect the nodes.  And this will be the only math slide with the embarrassing kind of handwritten chalk  motif.  But these are mathematical things and they're defined in RDF as mathematical things.  And the graphs we talk about in linked data look like this.  They have subject, predicate, and object, and your nodes are defined by the subjects  and objects, and your edges are defined by the predicates.  And off you go.  And they also look like this.  And if we do that, that is to say if we remove a statement, what we've done isn't to change  the graph so much as to create a new slightly different one with one fewer edge and as many  as two fewer nodes.  Because the graph is defined in terms of its member triples, that is to say it's a set  of its member triples, these changes aren't edits.  And that's a good thing because if we want to find out what the difference is between  two graphs or what the difference in meaning is, semantically, in what we're claiming in  each of them, we have a simple model for that.  And the model is statements in, statements out.  This is one reason why we as a community have been so eager to advance graphs as a way of  expressing data because we can capture meaning at this level.  Adding and removing and comparing is easy and it's an attractive prospect.  And I'm not here to tell you that we shouldn't do that.  Another reason is that if I have this, these are triples that I know about and you have  this or another one of my systems has this, putting them together is as easy as merging  the graphs, simply appending the one graph to the other.  So combining this idea with the web and follow your nose conventions that let me find your  graph, we have linked data and it's taken us quite far.  It's taken us here to all of the things that we've heard about during this conference.  But one thing that I've noticed is that we're talking a lot about rewrite data workflows  and information management workflows and while the community has gotten really good at publishing  and consuming linked data, questions about how we manage it are mostly open.  We've seen implementations here that serialize JSON-LD into no SQL data stores.  We've seen implementations that serve REST APIs from Elasticsearch.  We have object graph modelers represented here.  We have linked data platform and ad hoc patch formats.  This looks to me like the community grappling with how to manage graphs through stateful  lenses.  So this is coming from the section of the RDF concepts and abstract syntax document,  which is an interesting read if you haven't read it.  The RDF data model is atemporal. Graphs are static snapshots of information.  However, RDF graphs can express information about events and temporal aspects of other  entities given appropriate vocabulary terms.  Since graphs are defined as mathematical sets, adding or removing triples from RDF graph  yields a different graph.  So this problem is called out directly in RDF 1.1 in this section called RDF and change  over time.  My claim here is that we need a robust account of a thing that's at once as simple and complex  as change in the resources and the descriptions of them that we manage.  Again, this atemporal model is a good thing.  And besides unavoidable, once you've published some linked open data, retraction isn't part  of the ecosystem.  It's on the web.  Other people have pulled it down, presumably.  Otherwise, you might be wasting your time with the publishing thing.  And those assertions are out there, and there's no system for you to say that assertion is  invalidated.  So, a 2009 paper that has influenced my thinking about this pretty significantly makes a similar  observation about XML documents.  Since documents, including in data contexts, are defined as strings, which are in turn  defined as sets of characters, how can we account for workflows that rely on those documents  to change?  So document modification seems to be routine and widespread.  Editing is a familiar practice to almost everyone.  And revision is a fundamental feature of publishing workflows.  Yet document modification would appear to be an illusion.  Common accounts of what documents are seem to imply that documents cannot undergo genuine  modification.  So the point of this isn't to say that those workflows don't exist.  That's not the point of the paper, and it's not my point here.  They clearly do exist.  The point is simply to prod us into thinking about some important things which we might  have missed by failing to understand how this problem interacts with our data model.  These stateless things interact with our data model.  So both, possibly we're missing both things that we should understand about how we tackle  information life cycles and information management use cases like the sorts of things that Karen  is pointing to with users that we may be overlooking amidst our bad faith rhetoric about the death  of the record.  So let's talk about metadata records for a minute.  I use this term records deliberately in part because I know that it will raise hackles  among some of the people listening to this.  And in part because I think that it stands a chance of inviting a group of people and  practices that have been alienated by the linked data community back into the fold.  So let me explain what I mean by a record in web friendly terms.  So this is the conference of HTTP methods.  Here our happy client sends a request to a non-descript web server saying, give me one  Tim Berners-Lee please.  The non-descript web server responds 200 okay and sends back some data in a response body.  In the responses and RDF representation as in this case this is Tim Berners-Lee's FOPH  file.  It's his profile description for the W3C.  It's customary to return some statements about the requested resource.  So we get a nice description of Tim Biel's personal profile document, his FOPH file.  And we're told that the primary topic of the document is Tim Biel.  When constructing such a response one common pattern is to return all of the triples that  the server knows about where the requested resource is the subject.  So that means you return a graph generated on the fly and it includes the edges and nodes  that are adjacent only to the connected resource.  Usually this is extended to include connected resources that don't have requestable URIs  of their own.  So blank nodes or hash URIs, resources that are identified by hash URIs that have a base  that's shared with the other resource.  And anything adjacent to them also gets included possibly many triples out because otherwise  there's no way to go collect that data from another follow your nodes style request.  And this is also a common implementation for the loosely specified Sparkle describe.  This word describe is an interesting one and we'll come back to it.  Another common pattern, an alternate pattern is to serve out a graph with many subjects  deemed to be primarily about quote unquote a given subject.  This is what we see in the Tim Berners-Lee example.  So while there are many unique subjects in the graph that's returned, Berners-Lee himself  has an amorphously special status here.  But in either case, what is retained when we send the next request and get a different  graph is the aboutness.  The graph returned is in some meaningful sense of representation of the resource it describes.  So this starts to get at what I mean by record in RDF.  RDF source is an interesting concept that's not terribly well known.  I know of three references to this concept so I'm just going to jump in with the first  one which follows immediately from the previous reference to RDF and change over time this  section in 1.1 concepts.  And this is kind of a funny passage.  We informally use the term RDF source to refer to a persistent yet mutable source or container  for RDF graphs.  A source is a resource that may be said to have a state that can change over time.  A snapshot of the state can be expressed as an RDF graph.  For example, any web document that has an RDF bearing representation may be considered  an RDF source.  Like all resources, RDF sources may be named with IRIs and therefore described in other  RDF graphs.  So in some sense here what's being said is that an RDF source is a time sequence of graphs  or maybe it's easier to think of it as a container that at any given time during its life cycle  you can ask for its current state and it will give that back to you.  And this is an interesting concept when we juxtapose it against the assumption that what  we're dealing with in linked data is a giant global graph.  So these are stateful resources.  In data platform, a recent W3C specification for handling restful interactions, that is  to say stateful interactions with RDF documents, RDF descriptions, uses this concept pretty  heavily.  So an LDPR in this context is just any resource that conforms to a base set of HTTP interaction  patterns described in LDP.  So you send a certain kind of request and it gives a certain kind of response and there's  a set of assumptions built into LDP that makes it possible for you to classify things  as LDPRs, LDP resources.  LDP, RDF sources are a subset of this.  Basically they're the subset that contain RDF documents as opposed to say binary blobs  or videos or images or what have you.  So an LDPR whose state, LDPRDF sources and LDPR whose state is fully represented in RDF  corresponding to an RDF graph.  So what this means is if you send that get request, you get back the current state of  the resource and because of the way that LDP's interaction patterns are defined otherwise,  assuming that the server supports update, you have a set of methods also for updating  that resource.  This is the only other reference that I know of to RDF sources in any kind of formal writing  anywhere.  If you know of any others, I would like to know.  The entire semantics it says, this is from the RDF 1.1 semantics which is a less pleasant  read unless you have a certain bent.  So the entire semantics applies to RDF graphs, not to RDF sources.  And RDF source has semantic meaning only through the graph that is its value at a given time  or in a given state.  So it has semantics for previous values as well.  But graphs cannot change their semantics with time.  So the thing to take away from this is that this RDF source concept is really talking about  different graphs for any given instant that you might access them.  So what are examples of things that might look like RDF sources?  Any web resource that returns an RDF description and RDF serialization is going to look an  awful lot like an RDF source.  This includes HTML documents with embedded micro data.  Named graphs, this is an interesting one.  But it kind of suggests a way that we might move forward with stateful management of our  resources.  Sparkle describe and Sparkle construct both return RDF graphs and have stable identifiers  and assuming that you're running these queries against a dataset, you can expect those queries  to give some kind of representation of something reflected in the dataset.  So API resources like some of the ones we've seen in LoweBit and the like.  MVC model objects, MVC is model view controller for the non-developers.  This is like an object that you use to marshal data towards your user interfaces and update  it, et cetera.  Also I think, and Ruben can correct me if he disagrees, but I think triple pattern fragments  fall into this category as well and probably lots of other things.  So some of those things don't really make a lot of sense to think of as records.  So what I'm saying here isn't necessarily that an RDF source aligns closely with a record.  Construct in particular is a particularly odd example since it's possible to induce  the server to include whole bunches of data that's totally new and originates in your  request in the response contingent on the contents of the dataset.  You can do interesting things with construct.  But let me suggest some qualities that we might want to use to separate sources that  are not very record like from those that might be.  So records we might think of as having consistent aboutness.  Some of those source types might fit that bill.  Records we would hopefully want to think of as having stable scope.  So if we were to pull down a record, we would sort of expect the same kind of range of descriptions  to fit in.  And we would expect records to be amenable to managed life cycles.  So what I mean by this is if we have information processes that we're trying to support with  our applications, information processes in our libraries, we want to be able to interact  with the records in a consistent way.  We want them to do something for our life, for, we want their life cycle to represent  a workflow in a meaningful way.  So in some sense, you might think of these records as subsets of a larger graph and we  can do that juxtaposition thing and still have our lovely global graph structure but  also have recourse to managing them as part of a process.  Your mileage may vary on this.  In thinking about record use cases, I found it useful to look back at Dublin Core Abstract  model and description set profiles.  There's some interesting things here.  The abstract model of DC metadata description sets is as follows and you can kind of draw  a nice picture between description sets as closely aligned with the RDF source concept,  descriptions as that first option that we dealt with earlier where the subject is always  the same.  The descriptions in DCAM look like key value pairs that are all about the same subject,  that's one to one principle.  And also there's this concept of statement.  Below this, DCAM starts to get a little bit fussy with some, what I think are just simply  out of date formalisms about what values look like and there's value surrogate reference  here and you can probably safely stop reading past this point.  But there's also this interesting reference where description sets are treated as separate  from records, where records are documents that represent a snapshot of a description set,  which I found very interesting.  So that's my description set takeaway.  And with application profiles, I think we have an opportunity to dig a little deeper  on how we can scope records.  So I think there's, oh that's just DPLA math, we'll skip that.  So I think there's an important distinction that we need to make between human actionable  like that, application profiles and machine actionable ones.  Description set profiles is an interesting start towards some of this, towards the validation  side but I'm actually, I want to call on us to be looking at ways to identify records  as information management resources from larger graphs actively, not just in terms of looking  at them and validating whether they fit a certain shape but also picking the aboutness  of resources out from our application profiles from our larger graphs.  So that's, yeah I think that's it.  So I'm interested in talking about next steps for this and I think we have time for questions,  yes?  Of course we have, let's take a call.
Metadata_Records___RDF__Validation__Record_Scope___aLjcTF0Lwb0_0_347.png Metadata_Records___RDF__Validation__Record_Scope___aLjcTF0Lwb0_348_5231.png Metadata_Records___RDF__Validation__Record_Scope___aLjcTF0Lwb0_5232_13271.png Metadata_Records___RDF__Validation__Record_Scope___aLjcTF0Lwb0_13272_13559.png Metadata_Records___RDF__Validation__Record_Scope___aLjcTF0Lwb0_13560_17471.png Metadata_Records___RDF__Validation__Record_Scope___aLjcTF0Lwb0_17472_22427.png Metadata_Records___RDF__Validation__Record_Scope___aLjcTF0Lwb0_22428_23627.png Metadata_Records___RDF__Validation__Record_Scope___aLjcTF0Lwb0_23628_29651.png Metadata_Records___RDF__Validation__Record_Scope___aLjcTF0Lwb0_29652_32327.png Metadata_Records___RDF__Validation__Record_Scope___aLjcTF0Lwb0_32328_32459.png Metadata_Records___RDF__Validation__Record_Scope___aLjcTF0Lwb0_32460_32735.png Metadata_Records___RDF__Validation__Record_Scope___aLjcTF0Lwb0_32736_32795.png Metadata_Records___RDF__Validation__Record_Scope___aLjcTF0Lwb0_32796_34115.png Metadata_Records___RDF__Validation__Record_Scope___aLjcTF0Lwb0_34116_34439.png Metadata_Records___RDF__Validation__Record_Scope___aLjcTF0Lwb0_34440_34477.png