[SPIN API] Queries using sp:text short form cannot have other properties?

[pu...@xml.lt]

Hey,

I have some SPIN queries in my RDF, like this:

<#DescribeProducts> a       sp:Describe ;
    sp:text """PREFIX ... """^^xsd:string .

It works fine. However, if I add some more properties to the <#DescribeProducts> resource (such as rdfs:isDefinedBy), SPINFactory.asQuery() starts returning weird results like "DESCRIBE *", which is not what the original query is.

Does it mean the short query form can only have sp:text property? Is this an intentional limitation?


Martynas
graphityhq.com

[Holger Knublauch]

Yes this is implemented in ARQ2SPIN:
   
    public static String getTextOnly(Resource spinCommand) {
        // Return sp:text if this is the only property of the command apart from the rdf:type triple
        Statement s = spinCommand.getProperty(SP.text);
        if(s != null) {
            if(SPTextUtil.hasSPINRDF(spinCommand)) {
                return null;
            }
            else {
                return s.getString();
            }
        }
        return null;
    }

and the crucial line is

                if(!RDF.type.equals(o.getPredicate()) && !SP.text.equals(o.getPredicate()) && !SPIN.thisUnbound.equals(o.getPredicate())) {

which means that it only allows rdf:type or spin:thisUnbound apart from the sp:text triple. I guess I didn't want to enumerate all possible other properties that may exist, so you are running into an unexpected use case. In most use cases those SPIN RDF structures are created by editing in TBC and those would discard the extra triple anyway, so I am afraid this is not a high priority issue for us right now. If you want to submit a patch for your use case, I'd be happy to fold it into the next release. I guess we could either hard-code the properties that you want to allow or otherwise find a better implementation of hasSPINRDF (maybe looking for sp:where is enough if that always exists - I don't know off the top of my head).

Thanks,
Holger

--
-- You received this message because you are subscribed to the Google
Group "TopBraid Suite Users", the topics of which include Enterprise Vocabulary Network (EVN), TopBraid Composer, TopBraid Live, TopBraid Insight, SPARQLMotion, SPARQL Web Pages and SPIN.
To post to this group, send email to
topbrai...@googlegroups.com
To unsubscribe from this group, send email to
topbraid-user...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/topbraid-users?hl=en
---
You received this message because you are subscribed to the Google Groups "TopBraid Suite Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to topbraid-user...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Martynas Jusevicius]

Holger,

sorry to pick up an old thread.

Why would you want to constrain properties on queries at all? I wouldn't think they interfere with the rest of your code, as long there is sp:text among them?

What about adding simple metadata to queries, like dct:title and dct:description - how do you solve a use case like that?

Martynas

[Holger Knublauch]

Hi Martynas,

as I stated earlier, this was rather due to laziness and trying to play safe as I didn't want to spend the time to enumerate all possible "valid" SPIN RDF properties that could have shown up. This is certainly doable though, and a simple solution may be to allow everything outside of SP, SPL, SPIN namespaces.

If this is an issue that affects you, we now have a better solution to accept user contributions. I have basically stopped working on the SPIN API as a separately hosted entity, and the code base now lives on GitHub as part of the SHACL API:

    https://github.com/TopQuadrant/shacl

My working process is that I am first applying and testing changes to SPIN or SHACL in our private TopBraid repo. From time to time I copy those changes over to the public repo above. We could now also go in the reverse direction. If someone has a patch to contribute then I would accept them into the public and (from there) into the TopBraid repo. It would be great if you could test a suitable fix for "my" code and send me a patch, e.g. as a pull request.

Thanks
Holger

You received this message because you are subscribed to the Google Group "TopBraid Suite Users", the topics of which include Enterprise Vocabulary Network (EVN), Reference Data Manager (RDM), TopBraid Composer, TopBraid Live, TopBraid Insight, SPARQLMotion, SPARQL Web Pages and SPIN.

To post to this group, send email to topbrai...@googlegroups.com