Attributes | Values |
---|
has container
| |
Date Created
| |
maker
| |
described by
| |
Date Modified
| |
link
| |
id
| - f65c054038b683c870f74ce2582f5b3f
|
content
| - I also think the whole plan is poor, and I wonder why you'd even keep the coonls if you were doing random-suffix-matching like that. But, it seems like there might be a useful trick buried in here if foaf:name and doap:name both had rdfs:label of name . Your unresolved predicates could each be replaced with a variable that matches a predicate with rdfs:label name that's in one of the namespaces that you know about (here, it would be foaf and doap). SELECT DISTINCT ?projectName ?personNameWHERE { ?person ?name0 ?personName . # name gets translated to ?name0 ?person ?project0 ?project . ?project ?name1 ?projectName .# below here can be generated automatically ?name0 rdfs:label name ; :partOf foaf: . ?name1 rdfs:label name ; :partOf foaf: . ?project0 rdfs:label project ; :partOf foaf: .}My impromptu sparql is not good enough to specify foaf *or* doap , and I don't know how :partOf is really written. But otherwise, it's valid, well-constrained sparql that doesn't need a special processor (after the addition of my automatic stuff). It won't mysteriously change behavior if I merge in some data that uses the predicate drewp:name. The query results could tell you where name0 and name1 got resolved. I think it's still a silly plan, but it might possibly have a use if the user is insisting on omitting prefixes.
|
reply of
| |
is described using
| |
atom:source
| |
atom:updated
| |
atom:published
| |
http://rdfs.org/si...ices#has_services
| |
type
| |
is topic
of | |
is has reply
of | |
is atom:contains
of | |
is atom:entry
of | |
is container of
of | |
is http://rdfs.org/si...vices#services_of
of | |