2

I need to describe in RDF documents that are electronically signed PDFs versus documents that are normal PDFs. The list of IANA media types only contains application/pdf media type.

What is the good practice to use a custom URI to identify electronically signed PDF from a normal PDF?

I am reading that a new media-type could be defined starting with x-; can I simply define http://example.com/media-type/application/x-signed-pdf and use this URI as a value for a dcterms:format (or myontology:mediaType) property in RDF?

unor
  • 92,415
  • 26
  • 211
  • 360
ThomasFrancart
  • 470
  • 3
  • 13
  • @jschnasse : I will not accept your answer since I already described and validated another answer describing an alternative approach. – ThomasFrancart Dec 17 '18 at 08:13

2 Answers2

1

1. I wouldn't use a URI at all. Just define a 'vendor' or 'personal' media type like...

application/vnd.yourcompany.signed-pdf
application/prs.yourapp.signed-pdf

...and store it as literal with dc elements. http://purl.org/dc/elements/1.1/format

".... Recommended best practice is to use a controlled vocabulary such as
the list of Internet Media Types [MIME]."

2. If you need a URI based approach you could use IANA URLs for registered media types like:

https://www.iana.org/assignments/media-types/application/pdf

I assume that vnd media types will also get a similar URI at IANA.

3. Also See this discussion on "Cool" Linked Data URIs for all IANA mediatypes?

How to describe mediatypes in RDF is still a bit unclear, it is however common to use Dublin Core's "format" property, although there are two approaches:

http://example.com/image.png dc:format "text/html"

No links to follow here.. and dc:format also allows any kind of format literals like "VHS" and "Polaroid". Easy to use, though.

The dcterms:format property [7] is more suited as it goes to a resource, but is a bit cumbersome to describe correctly as an IANA type, see [4] ...

Community
  • 1
  • 1
jschnasse
  • 8,526
  • 6
  • 32
  • 72
0

We actually chose to :

  1. Have 2 distinct metadata properties : the "true" media-type, relying only on IANA-registered media types, and an application-specific "media-type";
  2. For the "true" media type we rely exclusively on registered IANA values, and for the "custom" type we define our own list of URIs as possible values;

So, we can rely on the "true" media-type property to do proper content negociation, and use the "custom" property for application-specific behavior.

ThomasFrancart
  • 470
  • 3
  • 13
  • Could you add an example? From what you describe, I understood that you're doing something like ` "application/json"` and ` ` ? So, each resource has two different properties with two different types to express the media type? – jschnasse Dec 17 '18 at 08:47
  • @jschnasse : exactly. We are separating the actual file-format (IANA) from the more business-oriented format. The file format is pure IANA, the business-oriented format typically refers to a specific XML schema, or says "scanned PDF" vs "electronically signed PDF" – ThomasFrancart Dec 18 '18 at 09:21