Is the RDF output correct?

[JeroenDeDauw]

When having two mapping like in the mockup:

Should we get this RDF output?

[despens]

Jeroen, could you post a sample in TTL format as well? I'm always struggling to interpret XML. @paulduchesne could you weigh in?

[paulduchesne]

Ensuring that a valid URL has been supplied in the URL field would be ideal, as there would be no circumstance I can imagine in which we would want a user to supply a mapping to a string. Looping back to an earlier question, I would also assume that the supplied URL cannot use prefixes.

Regarding checking that the provided URL does terminate in RDF, this would be a nice feature to prevent typos, although if the resulting displayed URL is clickable the user could always click through to verify that they are linking to the correct resource.

[JeroenDeDauw]

At the moment we do not validate the input of the URL field yet, since we first need to clarify what the requirements are.

It is clear that we need to support URLs in this field. Do we also need to support "prefix notation" in the URL field? The mockup has owl:subClassOf as a value for the URL field:

And if we do need to support that notation, should we restrict the allowed values somehow? For instance, only allow certain prefixes?

If there is no big benefit to supporting the prefix notation, then our suggestion is to only allow URLs in this field. This will allow us to be more strict with validation, and it also makes it simpler for other systems to deal with these values, since they only need to deal with 1 case.

[paulduchesne]

I personally like the idea of only allowing URLs in this field as they are unambiguous, but I would note that for day-to-day usability, having the ability to use prefixes for RDF, RDFS, OWL and SKOS would be extremely useful. Again, I would be interested if @despens has a strong opinion either way.

[paulduchesne]

@JeroenDeDauw Just doing some testing with the extension and noticed that any text is permitted in the URL field (eg https://rdf.wikibase.wiki/wiki/Item:Q4). Is this something I should open a ticket for, or is it already on your roadmap?

[JeroenDeDauw]

We can restrict the input to only allow URLs easily enough but have not done so due to unclear requirements. We cannot require both URLs and allow prefixes. #55. So this is something to talk about with @despens.

[paulduchesne]

@JeroenDeDauw just continuing this conversation now that we have the test wikibase running, I was a bit concerned that the TTL which the extension is releasing via EntityData seems to be in the form of strings (as in "string" not "things").

For instance I have declared an item at https://rdf.wikibase.wiki/wiki/Special:EntityData/Q2.ttl with some owl:sameAs clauses, but under the turtle these are coming through as literals (eg "https://www.wikidata.org/wiki/Q455552") not entities (eg <https://www.wikidata.org/wiki/Q455552> ).

[paulduchesne]

I can see that this was also the case in the original example provided and my concern is that a triplestore would interpret "http://www.example.com/foo" as a string literal, but I will test loading this into jena and see what happens.

[JeroenDeDauw]

Please let us know if this turns out to be a problem, then we will see if it can be changed.

[paulduchesne]

I believe this will be a problem, as the difference between the URL in triangle brackets and quotation marks affects how the triplestore interprets it. Just to step through an example, using Apache Jena.

manually convert the URL for the Wikidata target of our Wikibase item -> owl:sameAs statement

we can then run the obvious SPARQL query, show me all entities which are declared sameAs

using the current extension ttl output we get no results for the same query

and have to alter our query to search for a match on the URL as string

In this instance we can achieve the same result by altering our SPARQL query, but the intention of the extension as far as I understood was that we could also make declarations which influence inferencing within the triple store.

At this point if we declare a Wikibase property as -> owl:sameAs -> owl:ReflexiveProperty the triple store will not make use of the Reflexive Property statement to infer new triples, it will just be an inactive string sitting in the graph.

Let me know if this all makes sense, I will also just run the same tests in Blazegraph to check the same behaviour.

[malberts]

If my understanding is correct, we currently export something like this:

wd:Q2 a wikibase:Item ;
	rdfs:label "Thing2"@en ;
	skos:prefLabel "Thing2"@en ;
	schema:name "Thing2"@en ;
	owl:sameAs "http://wwww.w3.org/2000/01/rdf-schema#subClassOf",
		"https://www.wikidata.org/wiki/Q455552" .

And we want it to be:

wd:Q2 a wikibase:Item ;
	rdfs:label "Thing2"@en ;
	skos:prefLabel "Thing2"@en ;
	schema:name "Thing2"@en ;
	owl:sameAs <http://wwww.w3.org/2000/01/rdf-schema#subClassOf>,
		<https://www.wikidata.org/wiki/Q455552> .

When the mappings are defined like this:

Is this correct?

[paulduchesne]

Yes, this is correct.

Also bleeding into a different conversation, this points to a necessity for full URLs only. A triple store will understand explicitly what is meant by https://www.wikidata.org/wiki/Q455552, but have no handle on what is intended by wd:Q455552, without the ability to define that prefix.