w3c/sparql-dev

Extend the SPARQL Service Description with prefix declarations

Opened this issue · 7 comments

wouterbeek commented

Why?

It is useful to specify prefix declarations for:

  • queries, endpoints, graphs (definitely in scope for the SPARQL Service Description),
  • ontologies, datasets (probably in scope),
  • and possibly for others resources as well (maybe in scope, or maybe not).

Previous work

VANN includes the following properties for specifying at most one prefix declaration for an ontology:

SHACL includes the following class and properties that allow an arbitrary number of prefix declarations to be specifying for ontologies:

Proposed solution

Add a new property that allows prefix declarations to be asserted for queries, endpoints, and possibly other resources as well. An example of such a property is tp:prefixDeclaration, but that one is not part of any formal standard.

Considerations for backward compatibility

Prefix declarations specified in the SPARQL 1.2 Service Description should integrate well with prefix declarations specified in other ways / with SPARQL 1.1 constructs (e.g. prefix declarations in SPARQL 1.1 Query strings).

kasei commented

I had always hoped that there would be community alignment on using something like VANN in service descriptions. That's still an option, but guidance from a REC or NOTE on how to actually declare prefixes in a service description would probably help.

wouterbeek commented

@kasei Yes, I was also looking for existing properties that could be used to this effect. Then guidance would indeed be sufficient.

The downside of VANN is that you can only specify one prefix declaration, because prefix and alias are directly asserted on the ontology instead of on a separate node. (So asserting two VANN prefix declarations for the same ontology makes it impossible for users to distinguish the alias from the prefix.)

Another issue that I see with existing vocabularies is that "prefix" is sometimes used to refer to the IRI prefix that is abbreviated, and is also sometimes used to refer to the alias that replaces (and in practice: often abbreviates) the IRI prefix (followed by a colon in N3 notation). This is made worse by the fact that most vocabularies do not excel in lexicalization / the explanation of their properties in human-understandable terms. For example, SHACL documents sh:prefix as "The prefix of a prefix declaration." :-P

kasei commented

@wouterbeek I've used something like this in the past (but abusing the vann terms instead of using the sd: namespace):

[] a sd:Service ;
    sd:endpoint </sparql> ;
    sd:namespaces
        [
            sd:namespacePrefix "crm" ;
            sd:namespaceUri "http://www.cidoc-crm.org/cidoc-crm/" ;
        ] ,
        [
            sd:namespacePrefix "rdf" ;
            sd:namespaceUri "http://www.w3.org/1999/02/22-rdf-syntax-ns#" ;
        ]
	.

What do you think of just trying to document these terms and pattern?

wouterbeek commented

@kasei Yes, this is already quite close to what I envision people could use!

Some small things:

  • Maybe the property should be called sh:namespaceIri for consistency with RDF 1.1?
  • Maybe the values of sh:namespaceIri should be IRIs i.o. literals?

^ This is already quite nit-picky / close to what I imagine the standardization process would look like ;-)

JervenBolleman commented

Just to note for a few of our SIB endpoints we add prefixes/namespaces in the endpoint itself using shacl syntax.

SELECT ?prefix ?namespace
WHERE { [] sh:namespace ?namespace;sh:prefix ?prefix}
kasei commented

@wouterbeek

Yes, agreed on changing namespaceUri to namespaceIri.

Regarding the use of IRIs, I think care needs to be taken here since what happens with these values is a syntactic construction (you use prefix names like rdf:type to append "type" to the namespace IRI). You want to avoid dumping the SD data into an inferencing engine and accidentally have some stray owl:sameAs assertion imply that the endpoint supports an entirely different set of prefixes and IRIs. I think something like a xsd:anyURI typed literal would be appropriate here, but worry about differences between it's URI-based definition and our need for an IRI-based definition.

wouterbeek commented

@kasei Good point regarding owl:sameAs (and in general: the potential interaction between reasoning and prefix declarations)!

I fully agree that xsd:anyURI is better. But then I would also retract my other suggestion, and keep the namespaceUri property. That at least makes explicit that prefix declarations can only be represented for URI prefixes (and not for IRI prefixes that are not also URIs).

It's too bad that there is not a datatype IRI that denotes IRIs yet...