Hi Adrian,
On 9/24/12 10:36 AM, Adrian Gschwend wrote:
I can post now but figured out one change to the release before which is
not handy for me: When I uploaded an ontology from file/POST I could
before create the name like this:
curl -i -H "Content-type: text/turtle" -d @dc-elements.ttl
http://data.gemeindezukunft.ch:8080/ontonet/ontology/ACME/http://purl.org/dc/elements/1.1/
You could do that earlier? Hmmmmm, that's odd, it should have never been
that way - not very RESTful.
Now I have to post it to ../ACME and what I get is a identifier like
/ontonet/ontology/ACME/org.apache.stanbol.ontologymanager.ontonet.api.io.GraphContentInputSource-time:1348474817978
That's because the DublinCore elements ontology [1] is anonymous, so a
public key is generated on the fly (in your case
org.apache.stanbol.ontologymanager.ontonet.api.io.GraphContentInputSource-time:1348474817978
)
To be named, an ontology needs to have a single named resource typed
with owl:Ontology . DC elements is in RDFS and has no OWL statements.
Resource "http://purl.org/dc/elements/1.1/"; is not even typed in the
schema.
Some APIs implement additional methods to guess ontology IDs (e.g. the
xml:base or xmlns for RDF/XML documents), but they are nonstandard and
not implemented in Stanbol right now.
[1] http://dublincore.org/2012/06/14/dcelements.rdf
Also the content of the POSTed ontology is totally different:
--
Prefix: xsd: <http://www.w3.org/2001/XMLSchema#>
Prefix: owl: <http://www.w3.org/2002/07/owl#>
Prefix: xml: <http://www.w3.org/XML/1998/namespace>
Prefix: rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
Prefix: rdfs: <http://www.w3.org/2000/01/rdf-schema#>
Ontology:
Import: <http://data.gemeindezukunft.ch:8080/ontonet/ontology/ACME/core>
AnnotationProperty: rdfs:seeAlso
AnnotationProperty: <http://purl.org/dc/terms/modified>
AnnotationProperty: <http://www.w3.org/2004/02/skos/core#note>
AnnotationProperty: rdfs:isDefinedBy
AnnotationProperty: <http://purl.org/dc/terms/issued>
AnnotationProperty: <http://purl.org/dc/terms/description>
AnnotationProperty: <http://purl.org/dc/terms/hasVersion>
AnnotationProperty: rdfs:label
AnnotationProperty: rdfs:comment
AnnotationProperty: <http://purl.org/dc/terms/publisher>
AnnotationProperty: <http://purl.org/dc/terms/title>
Datatype: xsd:date
Datatype: rdf:PlainLiteral
--
Aside from the owl:imports statement (added by the Scope export), this
should be exactly the Manchester Syntax version of the ontology. It is
the format returned by default when you use the browser, but you can
negotiate other formats such as RDF/XML, JSON-LD, Turtle etc. Any POSTed
ontology can be exported to any supported format.
You see all those annotation properties because there is no statement in
the ontology that claims them to be something more powerful, such as
object properties. That's normal for OWL axiom interpretation praxis
(and a known cause of problems e.g. for OWL reasoners - but we're
working on that).
I could successfully post an ontology which had a URI in there which was
defined as an OWL:Ontology. Do you check for that? If so, what happens
if this is not the case like in my example with dc-elements?
A generated public key is applied, as in the above case. I understand
this can be awkward but at least it is conservative.
It seems however that you would like to specify a public key manually.
To my knowledge this wasn't possible earlier, but since I have now
implemented aliasing, I guess it is not a problem to have the client
specify new aliases. We can figure out together the best way to do so,
though.
The example you specified is intuitively ok, but does not totally
conform to the REST guidelines. If you know exactly the URI of the
resource to create, you should PUT it. However, I'm not sure what's the
best way to pass parameters such as the ontology content to a PUT.
Some ways to do so could be:
1) Create the resource, which will be an orphan until you POST the
content to it:
PUT
http://data.gemeindezukunft.ch:8080/ontonet/ontology/ACME/http://purl.org/dc/elements/1.1/
and then:
POST -d @dc-elements.ttl
http://data.gemeindezukunft.ch:8080/ontonet/ontology/ACME/http://purl.org/dc/elements/1.1/
2) let Stanbol use its generated public key and then add an alias:
POST -F "alias=http://purl.org/dc/elements/1.1/";
http://data.gemeindezukunft.ch:8080/ontonet/org.apache.stanbol.ontologymanager.ontonet.api.io.GraphContentInputSource-time:1348474817978
P.S. I've begun to code some dependency management for ontology
deletion, will keep you posted here.
I saw that I can delete stuff now, thanks!
What you saw was not for deleting ontologies, yet. An HTTP DELETE on an
ontology within a scope or session will simply release the handle from
that scope/session on the ontology - hopefully making it deletable if
there are no other handles.
Later on, scopes and sessions will have specific policies for deleting
released ontologies automatically (e.g. when a session is destroyed, it
will try to clear whatever ontologies were added to it, if they have no
other handles).
The actual deletion of ontologies was implemented in the commit I did a
few minutes ago. You may want to update and rebuild the ontologymanager
and try it out.
you have to DELETE [stanbol-host]/ontonet/[ontologyId] but it will only
work (200 OK) if there are no handles on it (i.e. no scopes/sessions
managing it, and no other ontologies importing it), otherwise you will
get 409 Conflict and will have to release those handles first.
I will later add a few services to get the list of handles and aliases
in JSON or something like that.
Best,
Alessandro
--
M.Sc. Alessandro Adamou
Alma Mater Studiorum - Università di Bologna
Department of Computer Science
Mura Anteo Zamboni 7, 40127 Bologna - Italy
Semantic Technology Laboratory (STLab)
Institute for Cognitive Science and Technology (ISTC)
National Research Council (CNR)
Via Nomentana 56, 00161 Rome - Italy
"I will give you everything, just don't demand anything."
(Ettore Petrolini, 1917)
Not sent from my iSnobTechDevice
