Re: PROV-ISSUE-222 (used-objectproperty): Datatype property for used? [Ontology]

On Thu, Apr 26, 2012 at 5:53 AM, Graham Klyne <graham.klyne@zoo.ox.ac.uk> wrote:
> On 17/04/2012 18:48, Jim McCusker wrote:
>>
>> For filenames, I would figure that one should use a file:// URI. Are there
>> any reasons not to?
>
>
> Maybe, but I'm not aware of the full context, so ignore me if this doesn't
> make sense.
>
> file:// URIs are interpreted with respect to a specific host environment
> (commonly localhost, but can be named).  While it's possible to separately a
> denotation, I think it could prove tricky to use this in a global reasoning
> environment.
>
> So, if the example is strictly local-use then file://... might be OK, but if
> the idea is to create provenance that can be shipped across the web I'd
> suggest avoiding file:// URIs.
>
> (This reminds me that there's a proposal for a ni: URI scheme that
> identifies by way of cryptographic hash, which might be useful for some
> aspects of provenance ...
> http://www.ietf.org/proceedings/81/slides/decade-3.pdf,
> http://tools.ietf.org/html/draft-farrell-decade-ni-04)

Tim and I are using that scheme (as part of fstack, part of
https://github.com/timrdf/csv2rdf4lod-automation/wiki/frbr:mccusker2012parallel)
as well as a tag: subnamespace that can securely hash a system UUID
including file modification time and hostname plus a hash for a path
that identifies a particular file on a particular computer without
revealing the identity of that computer. Alternatively, file:// URIs
actually are supposed to look like this:
file://hostname.domain.net/path/to/file, which is why file:// URIs
usually end up looking like file:///path/to/file (you can leave the
hostname out, but you need the extra slash to indicate that).

Jim
-- 
Jim McCusker
Programmer Analyst
Krauthammer Lab, Pathology Informatics
Yale School of Medicine
james.mccusker@yale.edu | (203) 785-6330
http://krauthammerlab.med.yale.edu

PhD Student
Tetherless World Constellation
Rensselaer Polytechnic Institute
mccusj@cs.rpi.edu
http://tw.rpi.edu

Received on Thursday, 26 April 2012 13:02:38 UTC