schema.org is better for SEO
From https://lov.linkeddata.es/dataset/lov/ it seems FOAF has more adoption?
I have used the ontology:
#prefix dcterms: <http://purl.org/dc/terms/> .
#prefix foaf: <http://xmlns.com/foaf/0.1/> .
#prefix gr: <http://purl.org/goodrelations/v1#> .
GoodRelations is worry free as it is mostly compatible with schema.org, but what about the other two? i.e.
dcterms:creator vs https://schema.org/creator
foaf:Person vs https://schema.org/Person
You can use multiple vocabularies/ontologies to describe the same entity.
If a consumer (like a search engine) only recognizes terms from a specific vocabulary (like Schema.org), it will simply ignore the terms from the other vocabularies (like FOAF).
So, for an entity that represents a person, you could use the types schema:Person, foaf:Person and/or dcterms:Agent. And for a book this person wrote, you could use the properties schema:creator, foaf:maker, and/or dcterms:creator.
If your primary motivation is SEO (instead of Linked Data), I would recommend to use the vocabulary Schema.org as far as possible, and other vocabularies in addition (at least where Schema.org is lacking, or, if you prefer, wherever it’s possible).
Related
I've often seen a SPARQL query starting with this prefix:
PREFIX : <http://dbpedia.org/resource/>
But what exactly does it mean to use only a colon ":" in a prefix? I usually know it as putting another abbreviation in front of it. Like for example here:
PREFIX foaf: <http://xmlns.com/foaf/0.1/>
Is there a reason to write it this way, and if so, what is the function of the prefix?
I would imagine that this would cover any other abbreviations that were not assigned. But unfortunately I've not found anything specific about this on the Internet
There’s no special functionality involved. It’s a regular prefix label, which happens to be empty.
SPARQL: Prefixed Names (bold emphasis mine):
The PREFIX keyword associates a prefix label with an IRI. A prefixed name is a prefix label and a local part, separated by a colon ":". A prefixed name is mapped to an IRI by concatenating the IRI associated with the prefix and the local part. The prefix label or the local part may be empty.
So these three snippets are equivalent:
SELECT * WHERE {
?person a <http://xmlns.com/foaf/0.1/Person> .
}
PREFIX foaf: <http://xmlns.com/foaf/0.1/>
SELECT * WHERE {
?person a foaf:Person .
}
PREFIX : <http://xmlns.com/foaf/0.1/>
SELECT * WHERE {
?person a :Person .
}
Using an empty prefix label in SPARQL queries might make sense if all, or almost all, IRIs come from the same ontology, because the query might become more readable then.
I wrote this query but it does't work. Anyone knows what is the problem.
PREFIX : <http://www.semanticweb.org/ontologies/2009/pizza.owl#>
SELECT ?X ?Y
WHERE {?X :hasCountryOfOrigin "Italy".
?Y :hasCalorificValue "400"}
According to the Pizza ontology tutorial here, there are two main issues with your query:
hasCountryOfOrigin is an object property, thus, the values can't be literals. Italy is an individual, thus, you have to use the correct URI, probably http://www.semanticweb.org/ontologies/2009/pizza.owl#Italy
The data property hasCalorificValue has values of type integer, i.e. literals should be used like "400"^^xsd:integer (or maybe xsd:int, depends on what you've chosen in Protege)
Both triple patterns in your query are not connected, i.e. no shared variable. I don't see the goal of your query.
PREFIX : <http://www.semanticweb.org/ontologies/2009/pizza.owl#>
SELECT ?X ?Y
WHERE {?X :hasCountryOfOrigin :Italy.
?Y :hasCalorificValue "400"^^xsd:integer}
I have a question :
In sparql what does the #prefix do:
#prefix : http://example.org/animals/
and why write like this?
Jeen Broekstra's answer is correct; #prefix <...> is not legal SPARQL syntax, and will only produce syntax errors for you. However, there is a similar construction in the Turtle and N3 serializations of RDF. In those syntaxes, the code
#prefix animals: <http://example.org/animals/>.
#prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
animals:Moose rdfs:subClasof animals:Animal
is the graph with the single triple:
<http://example.org/animals/Moose> <http://www.w3.org/2000/01/rdf-schema#subClassOf> <http://example.org/animals/Animal>
The #prefix lines define prefixes that make it easier to reference IRIs in the serialization of the graph. SPARQL also has prefix declarations, but the syntax is a bit different. In a SPARQL query, there is no # at the beginning of the line, and no . at the end of the line. So, continuing the example above, you might query for all things of subclasses of animal:Animal with the following query:
prefix an: <http://example.org/animals/>
prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>
select ?subclass where {
?subclass rdfs:subClassOf an:Animal
}
Note that in the first serialization, we used animals: but in the SPARQL query, we used an: with the same prefix. The particular prefix doesn't matter, so long as the actual (portion of a) URI that it expands to is the same. Strictly speaking, prefixes are for human convenience; they aren't strictly necessary.
"#PREFIX" doesn't do anything in SPARQL, except possibly generate a syntax error.
"PREFIX", however (without the "#"), is the SPARQL instruction for a declaration of a namespace prefix. It allows you to write prefixed names in queries instead of having to use full URIs everywhere. So it's a syntax convenience mechanism for shorter, easier to read (and write) queries.
There seems to be no consistent way to query for programming languages based on name. Examples:
http://dbpedia.org/page/D_(programming_language)
rdfs:label "D (programming language)"#en
dbpprop:name "D programming language"
owl:sameAs freebase:"D (programming language)"
foaf:name "D programming language"
vs.
http://dbpedia.org/page/C++
rdfs:label "C++"#en
dbpprop:name "C++"
owl:samwAs freebase:"C++"
foaf:name "C++"
Since there's no standard convention for whether "programming language", "(programming language)", "programming_language", "(programming_language", or "" is part of a name for a programming language in dbpedia, I have no idea how to consistently search by name.
I'd like to create some sort of SPARQL query that returns http://dbpedia.org/page/D_(programming_language) for "D" and http://dbpedia.org/page/C++ for "C++", but I don't know how do to this.
Unless at least one of the various triples for programming languages uses a consistent naming convention, I'll have to hack it by querying first against name + " (programming_language)", and falling back to name + "(programming language", name + " programming language" when no results are found. But I'd like a much more robust method.
You could of course just match using a basic substring match or a regex, e.g. like this to find a match for "C++":
SELECT DISTINCT ?pl ?label
WHERE {
?pl a dbpedia-owl:ProgrammingLanguage ;
rdfs:label ?label .
FILTER(langMatches(lang(?label), "en"))
FILTER(regex(str(?label), "C\\+\\+"))
}
Of course, the above will be problematic for a programming language name like "D", since you will get back several matches ("D", "Dylan", "MAD", etc.). In those cases, you might want to do some clever postprocessing of the result, for example tokenizing the returned label and seeing if your input string occurs as a standalone word.
Regex matching in SPARQL is notoriously expensive (in terms of evaluation time), but since you combine it with a type constraint to a particular category, the DBPedia endpoint should be able to handle this kind of query just fine.
I'd use
SELECT distinct ?pl ?label
WHERE {
?pl a dbpedia-owl:ProgrammingLanguage ;
rdfs:label ?label.
?label bif:contains "'C++'" .
filter (str (?label) like '%C++%')
filter (lang(?label)="en")
}
?label bif:contains "'C++'" would filter to some degree, more specifically to C++, C, Objective-C etc., because ++ would be treated as a noise and excluded from actual search pattern.
After that you have C and need two pluses, so filter (str (?label) like '%C++%') would check for them faster than regex.
Add filter (lang(?label)="en") or filter (langmatches(lang(?label),"en")) or no lang check at all by taste.
Say if I want to return the result "having fun" of the triple. I don't know how to account for the space in between the words. Below is a query I tried but it didn't work. Let me know if anyone can spot what I doing wrong
<rdf:Description rdf:about="http://website.com/urls/playing games">
<owl:sameAs rdf:resource="http://website.com/urls/having fun"/>
</rdf:Description>
"PREFIX owl: <http://www.w3.org/2002/07/owl#> SELECT * WHERE { ?y owl:sameAs+ <http://website.com/urls/playing fun> }";
Short answer: You can't, at least not directly.
Slightly longer answer: RDF itself uses RDF URI references. The SPARQL query language, on the other hand, uses IRIs (the reason is that RDF predates IRIs and the notion of RDF URI references was developed in anticipation of what IRIs were expected to eventually look like. They almost got it right :)).
Unfortunately, there is a discrepancy between the definitions of RDF URI references and IRIs, and you have just hit one of the cases: while RDF URI references allow whitespaces, IRIs do not. The SPARQL syntax can not cope with URI references such as the one in your example. Have a look at this discussion for more details.
Your best bet? Avoid using spaces in URI refs. Replace them with underscores or just remove them.
All that being said, there is a workaround to make your query work:
PREFIX owl: <http://www.w3.org/2002/07/owl#>
SELECT ?y
WHERE {
?y owl:sameAs+ ?x
FILTER (str(?x) = "http://website.com/urls/playing fun")
}
It's owl:sameAs not owl:sameas. Note capital A.
You can't have spaces in IRIs.