Unfortunately not: > This property is intended to be used with non-literal values. This property is an inverse property of Is Replaced By. I may have another use for it though. Thanks. I’m just gonna go with my own property 🙂

(I forgot to answer you directly: yes, the IDs are strings.)

Why is that better than using a custom ^^regex datatype?

I’m with Rick on this one. Repurposing language tags may work for an internal application, but it hurts the portability of your data

That’s specifically the reason — it’s purely for internal use (we use it to drive generated outputs from the authoritative RDF) and really shouldn’t have much meaning outside. More specifically, it’s how a downstream processor should interpret a given literal. We don’t currently use it, but the sub-tag mechanism could also be useful for future applications (e.g. en-US-x-regex). I think subtypes are the wrong way to do this, but haven’t really thought too hard about it.

As Rick also alluded to, unlike custom literal datatypes, filtering by language tags is (at least in theory) already built in to query engines. I should add that in this particular use case it’s always only a filter condition, and never part of a search query (“find all the s,p,o where o is a literal@x-private”). That may affect the choice we made.

All that said, we did sort of start down that path for the reasons I mentioned above, without exhaustively considering the custom ^^regex approach. I still think it’s the right one for us, but could be convinced to revisit it.

Appreciate the responses!

Well all compliant query engines should let you filter with something like:

FILTER(datatype(?foo) = regex:datatypeuri)

yeah… and I suspect (but have not validated) that the language code path is such a common filter that it’s optimized in some ways, where the datatype path seems less likely to be. (naïvely: one possibly-interned string compare vs. two lookups and a uri comparison)

standard have-not-written-my-own-query-engine-disclaimer.rdf

I think they generalise to the same thing, so solving one would solve 99% of the other. Though in my experience I’ve never found a store which optimised filters by converting them into direct index lookups analogous to BGPs. Though I do vaguely recall @U051N6TTC mentioning she knew of a store that did this.

This is actually the approach used in SQL engines

they use filters, unless the tested column is indexed, in which case the index is used instead

If we have this in SPARQL then a WHERE clause that looks like:

?entity ex:property ?x . FILTER(?x = 42)

?entity ex:property 42

I know we did do this in Mulgara, since if the filter said FILTER(?x > 42) then it became an index lookup, and this was extended to booleans operations in filters, so that if you had: FILTER(?x > 42 && ?x < 64) or even multiple patterns like: FILTER(?x > 42) . FILTER(?x < 64) Then this became a single range lookup in the index. (I know this because I was the one to implement it! It was back in 2004, IIRC. I think I blogged about it)

Indeed, that was the whole thing behind Netezza — just put filters in an FPGA at the hard drive controller and Always Be Table Scanning. 😛

obviously less directly applicable without the seek penalty of spinning rust, but still was a neat idea at the time.