The OWL API supports many different output document formats. I would like to give the user a choice of which format to use, but each format should have a different file extension, such as .ttl for Turtle and .rdf for RDF. Does the API provide a way to get a suggested file extension for a given format?
If there isn't a way, I wish there were!
There is nothing to do this at the moment. I have opened an issue for it:
https://github.com/owlcs/owlapi/issues/346
Edit: There's now an Extensions enum that links (some of) the format classes to (some of) the most common file extensions.
Usage: `Iterable formats=Extensions.getCommonExtensions(RDFXMLDocumentFormat.class);'
This is available in the master, version4 and version5 branches. Will be available in the next releases of OWL API.
Related
Some software uses audio/flac. Some uses audio/x-flac.
MDN suggests that x-flac is "non-standard". But based on what?
But this appears to be the official registry for audio/ types... and audio/flac doesn't appear on it. Has nobody ever registered flac there? Whyever not?
In 2021, what is the correct place to determine the list of "standard" content-types, and what is it for FLAC?
In 2022 Mozilla seems to have the answer:
The Free Lossless Audio Codec (FLAC) is a lossless audio codec; there
is also an associated simple container format, also called FLAC, that
can contain this audio. The format is not encumbered by any patents,
so its use is safe from interference. FLAC files can only contain FLAC
audio data.
audio/flac
audio/x-flac (non-standard)
So, depending on that I go with audio/flac. It seems to work for me on a Grav website.
I want to localize my application using the catopen()/catgets() family of functions.
As far as I understand, in the absence of NLSPATH variable, message catalogs will be looked up under /usr/share/locale/xx_YY/LC_MESSAGES.
What is the "traditional" file extension for message catalog files? I see some code examples using *.cat while others don't use any extension at all. Is it dependent on a particular UNIX flavour?
On my Linux boxes I see plenty of *.mo files, but those are GNU gettext archives. It seems catgets() can rarely be seen "in the wild" nowadays.
I meant this to be a comment, but it's a bit too long :P
Looking at the doc you've linked to, it seems probably that the code isn't opinionated as to file extension. Since you're not using MIME or anything to automatically find a handler for this file, the only requirement is likely to be that the name is correct. In UNIX, especially in the shell, file extensions often mean nothing to the system - fo example, any file extension can be used on an executable script as long as the executable bit is set and the shebang line at the top of the file specifies an appropriate interpreter.
It's possible the user community, if one still exists for this crufty sounding library, has a standard naming convention that the docs don't describe - but I wouldn't sweat it too much. It's trival to change file names, even if it means a recompile ( command line variables would make the program agnostic as to file name and extension )
I am trying to find a read that differentiates the advantages of using a Path object over the File object in java. I see a comparison of the API here http://docs.oracle.com/javase/tutorial/essential/io/legacy.html but don't really see the real advantages anywhere. Any pointer will be appreciated!
Generally one could say that both classes have different focus.
File is designed for file handling (creating, deleting, ...) while Path is focused on filename parsing.
File seems to have most functionality of Path included but there may be special cases where Path suits better.
Please see the documentation sites (especially methods overview) java.nio.File and java.nio.file.Path for further information.
I am looking for some input on how to programmatically convert mp4 files to fragmented f4f files with accompanying manifests.
I currently have an implementation for creating segmented MPEG2-TS files with accompanying manifest for Apples HLS, and want to create a similar piece of software for Adobes HDS.
My code is based on Libav (alternatively, ffmpeg), so I was hoping they had native support for muxing f4f files, but I have not been able to find any resources for it.
What I am specifically looking for:
How (if) the format is used in libav?
If there is any special requirements (such as the h264_mp4toannexb filter required for converting MP4 to MPEG2 TS)?
Any sample code (even if it's not using libav/ffmpeg)
An easy-to-read manifest specification.
I'm afraid you have to read mp4/f4f specification, and implementation it your self.
MP4 file format: ISO/IEC 14496-14
f4f file format: It is included in the f4v specification.(http://www.adobe.com/cn/devnet/f4v.html)
The code of mod_h264_streaming (http://h264.code-shop.com/trac) may be helpful.
I am trying to understand the different file extensions for the pfxplus powerflex database. Could someone please help telling me briefly what each file is for?
.k1
.k2
.k3
...
.k13
.k14
.k15
.fd
.def
.hdr
.prc
.pc3
Data files:
OK, so .dat is the data file.
.k1 -> .k15 are index files.
These are the critical data files for runtime. (Combined with filelist.cfg or pffiles.tab similar to define what files are available overall).
.fd is the file definition, needed for compiling programs
.tag (which you did not mention) is needed only if you need to access field names at run time (such as using a generic report tool)
.def is the file definition in human readable form, and is not needed by any process but is produced so a programmer or user can understand the file structure.
Run time:
The .ptc files are the compiled threads interpreted by the powerflex runtime.
The .prc file is a resource file that is used at runtime in conjunction with the .ptc file - it defines how a character based program is to look in a gui environment in "g-mode". It was the cheap way to upgrade character based programs when windows first started getting popular usage.
.hdr and .pc3 escape me at the moment, but are vaguely familiar - .hdr is probably another data file used with compression or special field types for later versions of pfxplus. .pc3 may in fact be the .ptc files...