- From: Brent Shambaugh <brent.shambaugh@gmail.com>
- Date: Thu, 24 Nov 2016 20:47:05 -0500
- To: "semantic-web@w3.org" <semantic-web@w3.org>
Hi all, I have question about URIs in ontology development. Do terms referenced in rdf:about need to be dereferenceable? For an example, I created a file called isp.rdf at http://data.thespaceplan.com/isp.rdf . Each one of my properties and classes have the base http://data.thespaceplan.com/isp# . Thus I created another file called isp with a full path of http://data.thespaceplan.com/isp . >From #swig on IRC: [Thursday, November 24, 2016] [5:39:02 PM EST] <brent_> I have a question about URIs in ontology development [Thursday, November 24, 2016] [5:39:11 PM EST] <brent_> I have a file called x.rdf [Thursday, November 24, 2016] [5:39:47 PM EST] <brent_> and rdf:about="x#something" in an xml file [Thursday, November 24, 2016] [5:41:06 PM EST] <brent_> so I created a file called x.rdf and a file called x in a directory on my webserver I lost connection, but I saw this: [20:29] <poka> it's all implementation-detail minutia, but i personaly dont use symlinks for doc -> doc.ttl, the symlink resolution actually takes a noticeable amount of time on crappy hardware with a bunch of files, [20:30] <poka> and dumb implementations start returning MIME types of application/x-symlink or something for the file, you end up with files without extensions which means other SW will try to sniff it internally [20:30] <poka> plus, it's one POSIX feature you can probably do away with if you arent using a FS backend , or are on some miserable OS like Windows where a symlink is a "NT Junction" or whatever [20:31] <poka> using hardlinks all over the place for index containers though [20:31] <poka> which proably makes deletion harder , but i dont consider deletion a feature As an additional question, how would I answer this question if I had something like http://data.thespaceplan.com/isp/classname with the root http://data.thespaceplan.com/isp/ ? Thanks, Brent
Received on Friday, 25 November 2016 01:47:39 UTC