I have wondered this, especially in terms of compressing URIs in storage. It turns out that http is the preferred approach (which simplifies things, for which I am grateful)

It's not that you can't use https, but recall that these are URIs (actually, IRIs), which means that they are identifiers, and don't necessarily indicate a retrievable resource

Best practice suggests that relevant data be stored at a resource's IRI, but that is not necessary, and in many cases never happens

changing from http to https is changing the protocol for retrieval, but since retrieval need never happen, then why would you need to?

Another best practice is to use 303 status codes (See Other). That's because the resource that you're asking for may not be a digital one. For instance, if I have inventory information for my company, I might identify each object with IRIs like: If I were to make an http request to this address, then the digital information I get back will represent the object, but it won't be the object. Ceci n'est pas une pipe

anywhere you've set up the service can use 303 to redirect to an https url

Anyway... my point is that it's a philosophical difference and technically doesn't matter. But also that it's worthwhile sticking to http

Thanks Paula. 🙏

I use http for my own namespaces, but in this particular case I am generating URIs for a third party's resources and 1) they don't redirect from http to https, 2) there is actually content at the URIS I am generating (they have inadvertently made something very RDF'able).

Just to add to the point that IRIs don’t need to be http, for a little while I would publish a foaf file with a gopher:// IRI 😊

I mean, that was the IRI that I used to refer to myself, and also the URL where you could get the document

makes sense

I think it depends on whether you’re just doing RDF or are doing linked data. Assuming you’re doing linked data then I think these days you should try and use https for your identifiers instead of http. You can redirect from http to https, but the problem is that if you’re also offering linked data to API consumers then anyone “following their nose” will be making insecure requests, potentially susceptible to tampering/mitm etc. Anyway it entirely depends on your users and use cases and trade offs — but all things being equal I think https is the right choice; though it may add a small complexity tax to some consumers — for example if they don’t have TLS easily available to them; though I don’t think many languages will suffer that issue these days.

I had not considered that there could different considerations concerning rdf vs. linked data—in fact I think I mostly considered them synonyms till now. I think I might go with https. There is no RDF at the other end though, just HTML pages.

Yeah. They’re frequently considered synonyms as they often overlap; and I think a big problem with the vision statement is that it complects them all together; where as the ideas and technologies underneath are really de-complected: I tend to view the breakdown as: 1. RDF is the data model (the platonic triples). 2. Linked Data is the principle of hosting representations of your identifiers at the same location as their identifier - so they can be looked up. Strictly speaking that principle could be implemented in anything; but in practice it implies URI’s and the web — and RDF is a good fit for it because it was built from first principles with this world view. 3. The Semantic Web. This is the idea of supporting formal reasoning, and logical entailments on such an architecture or information model; but both those things are optional — and you can just take the reasoning if you want. So in my mind you can have linked data without RDF and you can have RDF without linked data. You can also have the “semantic web” without Linked Data or even RDF, as OWL also supports non RDF syntaxes. Does that make sense?

Incidentally, Snomed appears to use OWL without RDF. It’s a bit annoying to extract Snomed into RDF, (though not too hard)

yeah OWL can be pretty verbose as turtle

Hmm, I haven’t found it so. Probably on raw character count then Manchester or functional syntaxes may be a little shorter, but not by a lot. I think that I t’s mostly white space and indentation that makes Turtle look longer. I definitely prefer to write my OWL in ttl

I think it’s a little more than that — iirc in turtle you need to do a bit more plumbing e.g. adding a owl:Restriction; ... etc But I agree it’s not that bad; and in practice it makes the RDFization much more obvious — for example if you’re going to SPARQL for things etc… though there was TERP syntax — but nobody uses that.

I skip the restriction type declaration, because it gets inferred due to the domain of the restriction properties 😉

… fair point 🙂

My inclination is usually blank nodes representing the concept being represented with a rdfs:label, then skos to connect the nodes. Skos notes could be used instead of the rdfs label, as could Dublin Core properties, but I generally wouldn’t use either of those for this sort of thing.

Very nice! If I hadn't already written most of my queries, I would probably use this. The query system of Aristotle is very basic and I have had to resort to SPARQL a few times already.