In an RDF file that describes a resource I would like to include a link to a HTML document that provides background information. The document is HTML, not RDF. I have the feeling that this should be made clear, probably with some kind of format specification (like dcterms:format).
My questions are:
What is the best way to link to non-RDF resources (URIs) in Linked
Data / RDF?
Which is the best vocabulary term to use for a
document/resource that provides background information on the
subject?
The general property for providing additional information is rdfs:seeAlso. As the spec says, you can create a sub-property of seeAlso to convey more specific semantics. As for encoding the metadata, personally I'd stick to Dublin Core and I would add a bNode so that the various properties of the external source can be recorded in the triple store.
So, if some_resource is the thing that you have more information about:
example:some_resource
rdfs:seeAlso [
dcTerms:source "http://your.si.te/docs/foo.html"^^xsd:anyURI ;
dcTerms:format "text/html" ;
dcTerms:title "Foo user manual"#en ;
dcTerms:language "en"
].
Related
For creating an anonymization/de-identification tool I would like to delete/overwrite all tags/attributes from the DICOM file that are not necessary. I've searched around the internet, but have not found a clear list of which tags are mandatory for a DICOM file.
I found out that there are multiple types, type 1 is mandatory, type 2 must at least be an empty string and type 3 can just be deleted. But so far I have not found an easy list online with all tags and their types. Does anyone have list of tags and types or a list of mandatory tags for DICOM file?
The mandatory attributes (given by their tags) depend on the SOP Class of the DICOM file.
read the Media Storage SOP Class UID (0002,0002) from the File Meta Information (meta header)
in the DICOM standard, locate the IOD correspondent to the SOP Class UID (e.g. "1.2.840.10008.5.1.4.1.1.1" = Computed Radiography Image Storage)
the IOD specification lists the mandatory and optional modules (e.g. Patient Module, General Image Module, etc). The modules marked with M are mandatory, C=conditional, U=optional (user option)
each module lists the mandatory and optional attributes (e.g. the Patient module includes the patient name, the patient ID, sex, etc). Attributes marked with 1 are mandatory, 2=mandatory but can be empty, 3=optional, 1C=mandatory if some conditions are satisfied, 2C=mandatory but can be empty if some conditions are satisfied
There is a nice Presentation about "De-Identification" by David Clunie here: https://www.dclunie.com/papers/D2_1045_Clunie_Deidentification.pdf
The concepts presented went into the DICOM Standard Part 15, Annex E - De-Identification
The current list of attributes to handle for a valid de-identifier is clearly described in the DICOM standard PS 3.15:
Attribute Confidentiality Profiles
In particular see the table:
Table E.1-1. Application Level Confidentiality Profile Attributes
As a side pay special attention to the private tags, as described in the following profile:
Retain Safe Private Option
For historical reference, you should also pay attention that the DICOM standard has greatly changed since the 2008 edition:
ftp://medical.nema.org/medical/dicom/2008/08_15pu.pdf
Some tool (eg. gdcmanon) implements the old section PS 3.15 / E.1 / Basic Application Level Confidentiality Profile (Implementation of E.1.1 De-identify & E.1.2 Re-identify).
Finally, DicomCleaner should give you an idea of what a quality implementation looks like:
How to use DicomCleaner
The original wording of the question: "I would like to delete/overwrite all tags/attributes from the DICOM file that are not necessary" seems to be in conflict with the definition of "de-identification". So either the question is poorly formulated, or you are missing the fact that Type 1 attribute may contain Protected Health Information.
I'm Implementing a mini http server using boost beast. the server has two different routes POST /upload/... and the other one is POST /info. The first one is used for uploading some big files and the other one is for hadling json objects. To keep the performance as hight as possible am I trying to parse each route with the suitable parser file_body and string_body/dynamic_body.
I was hoping that it is possible to do something like:
http::async_read_header(
socket_,
buffer_,
request_,
[self](beast::error_code ec, std::size_t)
{
if (!ec)
self->request_.body().data();
});
but it seems not possible.
Is there any way to use different request bodies depending on header info?
Many thanks in advance
This should be covered in the docs but here's how to do it: Use the type beast::request_parser<beast::empty_body> to first read the header, and then depending on the contents of the header you move-construct a new parser from the old one with the body type you want. Example:
// Deferred body type commitment
request_parser<empty_body> req0;
...
request_parser<string_body> req{std::move(req0)};
You can read the complete documentation on switching body types here:
https://www.boost.org/doc/libs/1_69_0/libs/beast/doc/html/beast/ref/boost__beast__http__parser/parser/overload5.html
I'm very new to drupal and have to do some real quick small work. While going through the documentation at https://www.drupal.org/docs/8/theming/twig/functions-in-twig-templates, I saw string parameter to url() function.
{{ 'View all content'|t }}
what is the value that url() is taking?
Infact, i'm trying to get relative path. I used
Solutions
But, it didn't work for me because {{directory}} changed each time and led to url append. Is there any best practices? Thank you for suggestions.
When adding a URL into a string, for instance in a text description, core recommends we use the \Drupal\Core\Url class. This has a few handy methods:
Internal URL based on a route - Url::fromRoute(), Example: Url::fromRoute('acquia_connector.settings')
Internal URL based on a path - Url::fromInternalUri(), Example: Url::fromInternalUri('node/add')
External URL - Url::fromUri, Example: Url::fromUri('https://www.acquia.com')
The last two methods are very similar, the main difference is, that fromInternalUri() already assumes an 'internal:' prefix, which tells Drupal to build an internal path. It's worth reading up on what prefixes are supported, for instance the ':entity' prefix can help in building dynamic URIs.
When you need to constrict and display the link as text you can use the toString() method: Url::fromRoute('acquia_connector.settings')->toString().
If you need additional information please ask.
The question is clear enough, but let me flesh it out with the actual example I am encountering:
In interpreting an RSS feed, there is an image specified sometimes where it is not known what kind of image it is, but it is nonetheless clear that the link type is an image, such as in this example:
<itunes:image href="http://static1.doda.com/57914/1500w/" />
That iTunes spec does not enter the image type attribute for the image. So then let's say I am taking this image link (with others) and re-syndicating it, but now as a standard ATOM link. To specify it is an image, the type attribute of the link needs to start with image (as an image MIME type), and yet what should I do about the subtype:
<link href="http://static1.doda.com/57914/1500w/" type="image" /> //??
I'm guessing MIME types can never do this, but is that the case? Can the subtype ever be left off? Another solution is not so happy either: to enter a FALSE but common subtype (e.g.: "image/jpeg").
--- update ---
Thanks to Julien for that research. So one solution just occurred to me: using a generic subtype of a given value such as: unknown, or none.
image/unknown
image/none
Maybe just go with 'unknown', but 'none' has it's benefits as well. This might be especially useful if a lot of people started using one (or both) of these values when they don't know the subtype.
I would love to hear in the comments how that idea strikes you guys, yea or nea? Good idea or bad?
Yes, in theory, the RFC4287 says:
Whatever a media type is, it contains at least one slash
atomMediaType = xsd:string { pattern = ".+/.+" }
Now, from experience, there are many feeds out there which do not include the sub-type. Be robust: if you publish a feed, make sure you include both... and if you consume feeds, be ready to handle feeds where it's missing!
I was reading some questions trying to find a good solution to preventing XSS in user provided URLs(which get turned into a link). I've found one for PHP but I can't seem to find anything for .Net.
To be clear, all I want is a library which will make user-provided text safe(including unicode gotchas?) and make user-provided URLs safe(used in a or img tags)
I noticed that StackOverflow has very good XSS protection, but sadly that part of their Markdown implementation seems to be missing from MarkdownSharp. (and I use MarkdownSharp for a lot of my content)
Microsoft has the Anti-Cross Site Scripting Library; you could start by taking a look at it and determining if it fits your needs. They also have some guidance on how to avoid XSS attacks that you could follow if you determine the tool they offer is not really what you need.
There's a few things to consider here. Firstly, you've got ASP.NET Request Validation which will catch many of the common XSS patterns. Don't rely exclusively on this, but it's a nice little value add.
Next up you want to validate the input against a white-list and in this case, your white-list is all about conforming to the expected structure of a URL. Try using Uri.IsWellFormedUriString for compliance against RFC 2396 and RFC 273:
var sourceUri = UriTextBox.Text;
if (!Uri.IsWellFormedUriString(sourceUri, UriKind.Absolute))
{
// Not a valid URI - bail out here
}
AntiXSS has Encoder.UrlEncode which is great for encoding string to be appended to a URL, i.e. in a query string. Problem is that you want to take the original string and not escape characters such as the forward slashes otherwise http://troyhunt.com ends up as http%3a%2f%2ftroyhunt.com and you've got a problem.
As the context you're encoding for is an HTML attribute (it's the "href" attribute you're setting), you want to use Encoder.HtmlAttributeEncode:
MyHyperlink.NavigateUrl = Encoder.HtmlAttributeEncode(sourceUri);
What this means is that a string like http://troyhunt.com/<script> will get escaped to http://troyhunt.com/<script> - but of course Request Validation would catch that one first anyway.
Also take a look at the OWASP Top 10 Unvalidated Redirects and Forwards.
i think you can do it yourself by creating an array of the charecters and another array with the code,
if you found characters from the array replace it with the code, this will help you ! [but definitely not 100%]
character array
<
>
...
Code Array
& lt;
& gt;
...
I rely on HtmlSanitizer. It is a .NET library for cleaning HTML fragments and documents from constructs that can lead to XSS attacks.
It uses AngleSharp to parse, manipulate, and render HTML and CSS.
Because HtmlSanitizer is based on a robust HTML parser it can also shield you from deliberate or accidental
"tag poisoning" where invalid HTML in one fragment can corrupt the whole document leading to broken layout or style.
Usage:
var sanitizer = new HtmlSanitizer();
var html = #"<script>alert('xss')</script><div onload=""alert('xss')"""
+ #"style=""background-color: test"">Test<img src=""test.gif"""
+ #"style=""background-image: url(javascript:alert('xss')); margin: 10px""></div>";
var sanitized = sanitizer.Sanitize(html, "http://www.example.com");
Assert.That(sanitized, Is.EqualTo(#"<div style=""background-color: test"">"
+ #"Test<img style=""margin: 10px"" src=""http://www.example.com/test.gif""></div>"));
There's an online demo, plus there's also a .NET Fiddle you can play with.
(copy/paste from their readme)