- Introduction
- Media Type and LDP Considerations
- Bagit Profile
- Context And Typed Tags
- Document Continuation
- References
The data structure resulting from a parsed BagIt tag file is a map of string labels to untyped string values in order. As such, the tag file is losslessly translatable to JSON-LD. This primary goal of this document is to outline a BagIt-Profile and parsing practice to leverage this JSON-LD compatibility to serialize and deserialize LDP resources as BagIt archives. The secondary goal is to produce object serializations that are sufficiently backwards-compatible to be used as plain BagIt archives in non-LDP contexts, e.g. AP Trust.
- The tagfile/json-ld translatability
- The fact that
<iana:describedby>
is a predicate that indicates graph continuation - The fact that json-ld's
@value
attribute can point to a relative fileUri for binary content (so that a node could have a separate@id
uri and@value
uri).
If you have some ttl of your LDP object -- with relative URIs -- and you have a Described-By
tag in your bag-info that points to the ttl, and you have a context tagfile that says:
{ "Described-By" : { "@id" : "iana:describedby", "@type" : "xsd:anyURI" } }
Then you basically have a graph serialization in the payload as well as including a context.
Spec needs a media type that indicates a zipped BagIt archive: application/zip+bagit
?
- LDP clients that
POST
BagIt serializations MUST indicate the ldp:RDFSource or ldp:Container interaction model. - LDP clients that require BagIt serializations on
GET
MUST indicate the requirement in Accept. - LDP servers that support BagIt serializations on
POST
MUST advertise support in Accept-Post. - LDP servers that support BagIt serializations on
PUT
MUST advertise support in Accept-Put. - LDP servers that do not support BagIt serializations SHOULD respond with
HTTP 415
toPOST
with a BagIt serialization.
Since tag names are case insensitive, the context information below should be considered to match all case variation of the tag names.
JSON-LD disallows aliasing @context
; the "reserved context" alias below is effective rather than literal.
{
"BagIt-Context" : "@context",
"Bagging-Date" : {"@type":"xsd:date"},
"BagIt-Profile-Identifier" : {"@type:"xsd:anyURI"},
"BagIt-Payload-URI" : {"@type:"xsd:anyURI"},
"bagit-payload" : "BagIt-Payload-URI"
}
{
"External-Identifier" : "@id",
"Described-By" : {
"@id" : "http://www.iana.org/assignments/link-relations/describedby",
"@type" : "xsd:anyURI",
}
}
- Resolution of relative file URIs to bag root
- Resolution of relative URIs to context, starting at External-Identifier
- bagit-payload URI and json-ld expansion
- Binary content indicated with
owl:sameAs <fileUri>
?"@value" : <fileUri>
? - Content serialized for proxied resources?
A tag with @id
of <http://www.iana.org/assignments/link-relations/describedby>
SHOULD be a relative URI pointing to additional description of the resource currently in context. If this is serialized data (a file URI), the tag's context SHOULD indicate its MIME with @format
.
Use of @value = file
uri for cached published context, nonRdfSource content with URI id.