Yesterday we discussed, but did not conclude anything on, R-171
"Validation of IRIs by Dereferencing". The general idea was that we have
two different cases:
1) Make sure that the IRI returns *something* -- i.e. that there is a
successful dereferencing
2) Make sure that the IRI returns a particular kind of thing -- i.e.
that it returns an image file for "ex:image", or a graph whose subject
is a SKOS:Concept.
#1 is fairly simple: check returned http status code.
#2 is much more difficult, and I have some doubts for some cases.
Case 2a) a media-typed resource
If your IRI is "http://example.com/blah.jpg" the action will be to
retrieve a resource with that same IRI. Unless you are going to run a
check against the retrieved bits, the information that you have in the
IRI (that it is identified as type ".jpg") is your fallback. In that
case, this is a check on your IRI, not on the resource retrieved. It
seems to me that checking that actual resource is a tall order. Even
retrieving the actual resource may not be desirable in a "real-time"
application.
Case 2b) an RDF resource
If your IRI resolves to an RDF resource, and you want to check further
(e.g. that it is defined as a SKOS:Concept), then we seem to be talking
about checking the rdf:type of the referenced information resource. Are
there other cases that are not just about rdf:type? I'm thinking whether
there could be language code requirements, etc. However, you almost
certainly have to retrieve the resource to first determine that it *is*
an RDF resource, and definitely any further checking requires that you
retrieve the resource and possibly the entire vocabulary (to check for
sub/super conditions that affect the decision.
Case 2a could be resolved by checking the last ".x" pattern of the IRI
against a list of types (.jpg, .tiff, .txt, .pdf). Case 2b presupposes
that you can recognize when you have resolved to an RDF resource.
What the application actually *does*, however, is not directly our
concern. We need to determine what the application needs from the
application profile, and how we can express it. My concern here is that
we not try to include information in the AP that will support a case
that is so burdensome that it is almost never used. Therefore, I
conclude with: can someone point to actual use cases for any or all of
the above, from #1 to #2a, #2b. What are you already doing today?
Thanks,
kc
--
Karen Coyle
[log in to unmask] http://kcoyle.net
m: 1-510-435-8234
skype: kcoylenet/+1-510-984-3600
|