Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SPARQL endpoint #147

Merged
merged 4 commits into from Nov 18, 2013
Merged

SPARQL endpoint #147

merged 4 commits into from Nov 18, 2013

Conversation

cbeer
Copy link
Contributor

@cbeer cbeer commented Nov 13, 2013

@cbeer
Copy link
Contributor Author

cbeer commented Nov 14, 2013

@barmintor @ajs6f I've added all the DC 1.1 elements and decided against trying to do all the dcterms. Anyone want to argue for dcterms support in core (which seems like a shame not to do, but all those ranges and domains give me pause..)?

@ajs6f
Copy link
Contributor

ajs6f commented Nov 14, 2013

The argument that I can think of is that DC terms are really meant for use in an RDF world, whereas DC elements are not. I'm not sure how much bite that argument really has in terms of what our users actually do. I get the issues with the domains/codomains of DC terms being restricted to typed things, but if people are filling those slots with URIs, I don't see that we have to do much about it. IOW, if I say, foo dcterms:something info:bar/thing and info:bar/thing is not the right type for an object of dcterms:something, that's not the fault of my software (unless my software makes guarantees about validity that we don't make and would never make in the core). That's my fault. At most, we might distinguish between literals and URIs, and that we can do. I'm not even sure I would want to do that.

@cbeer
Copy link
Contributor Author

cbeer commented Nov 14, 2013

I wouldn't squash these commits when this gets merged. 993bb63 is pretty scary, and we should know what to blame when something goes terribly wrong.

@@ -203,6 +203,8 @@
createProperty("http://microformats.org/wiki/rel-subscription");
public static final Property NOT_IMPLEMENTED =
createProperty(REPOSITORY_NAMESPACE + "notImplemented");
public static final Property HAS_SPARQL_ENDPOINT =
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does the admin search SPARQL query actually qualify as a SPARQL endpoint? I was thinking the external triplestore would be the "SPARQL Endpoint".

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it does, and this should give us a way to advertise both (or, if you have an external one, we just don't inject out admin search triple)

awoods pushed a commit that referenced this pull request Nov 18, 2013
@awoods awoods merged commit 7564c9b into master Nov 18, 2013
@awoods awoods deleted the sparql branch November 18, 2013 22:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants