Hi Rob,
the best way to create new project types is to clone an existing one.
Look at ontologyprojects for example: each of the project types comes
with an instance of teamwork:ProjectType (e.g.
ontologyprojects:ProjectType) and a vocabulary type (e.g.
ontologyprojects:Ontology) that is used as rdf:type of the instances
(specific graphs).
You don't need to subclass teamwork:UserDefinedProjectType.
Holger
On 17/07/2018 19:40, Rob Atkinson wrote:
spiralling back into chaos here:
i now get properties label vocabulary and vocabularyType.
I have a project that shows up OK in EDG.
If I try to add that as the projectType us add existing it doesnt show
up as an option... but what show up is
teamwork:UserDefinedProjectType with the message
Customers who wish to define their own vocabulary types should
subclass teamwork:UserDefinedProjectType
but of course, having followed instructions - my EDG projectType is an
instance
and in that file the class teamwork:UserDefinedProjectType is not
visible - so its not imported.
so how to interpret this?
(IMHO every single instruction in TBC needs to have a context that
clearly lists the assumed imports - and maybe dynamic document
building could check when some sub-instruction needs different imports
from where it is being referenced as a context... )
On Tuesday, 17 July 2018 18:34:17 UTC+10, Holger Knublauch wrote:
On 17/07/2018 17:49, Rob Atkinson wrote:
what does "The script's function must use either
teamworkscripts:suitableProjectType or
teamworkscripts:suitableVocabulary to declare the scope of asset
collections that it can be applied to." mean
does that mean i need to access the function as en entity in the
form and set its supertype? Or are these properties (do not show
up in properties view)
so where is teamworkscripts.ttl ? Do i need to find it and import
it for this to work? It doesnt appear to exist in TBC (5.5)
If you don't know where a file is, try Open Resource (Ctrl-Shift-R).
This one is at teamwork.topbraidlive.org
<http://teamwork.topbraidlive.org>\system\teamworkscripts.ttl
and the properties should be self-explanatory when you navigate
into them.
Holger
On Tuesday, 17 July 2018 17:15:26 UTC+10, Holger Knublauch wrote:
On 17/07/2018 17:00, Rob Atkinson wrote:
OK - I think i understand this.
So a quick question - if I want to pre- test the SM function
in TBC using the rather nice visual debugger (and ability to
document and explain the workflow logic!) how best to wrap
the script with a module to load the input file and save the
results? Is it possible to embed one SM script in another?
(or in this case refactor a visual script that imports files
and saves results and turn it into a function without losing
the ability to test it this convenient way? )
Just select the ReturnRDF module and press the usual run
button. You will then be asked to paste the content of the
file (upload) into a dialog. Alternatively, the function is
also a SPARQL function that can be called as such.
Another question relating to generating visual overview
documentation - there is a implicit and interesting graph of
how a set of EDG components fit together - if i graph this
as instances its kind of nice - but is there a way to
persist this graph as an editable entity, in the same way
sparqlmotion persists its rendered workflow graph?
Not exactly sure what you mean (which instances are the "EDG
components"), but the Graph tab in TBC has a save snapshot
button to save the coordinates.
Holger
On Tuesday, 17 July 2018 16:34:20 UTC+10, Holger Knublauch
wrote:
Hi Rob,
I am updating the documentation of this feature and will
include a text such as the following, on teamworkscripts.ttl
--
A small vocabulary that can be used to annotate
SPARQLMotion scripts so that they can be used in the
"Import File using Script" feature with selected asset
collections. The user interface of such script-based
importers asks for a file to be uploaded and then uses a
script created by a SPARQLMotion expert to produce RDF
triples as output. These RDF triples then are added to
the currently open production copy or working copy. The
uploaded file may be of any text-based format including
comma-separated values, JSON or XML.
To get started, create a SPARQLMotion file (with
.sms.ttl ending) and import this teamworkscripts.ttl
namespace into it. The file must define one sm:Function
that takes exactly one argument of type string. The name
of this argument is arbitrary. When called, the argument
will have the text content of the uploaded file as its
value.
The script can access the current context graph (either
the production or working copy) using sml:ImportCurrentRDF.
The return module of the script must be of type
sml:ReturnRDF.
The script's function must use either
teamworkscripts:suitableProjectType or
teamworkscripts:suitableVocabulary to declare the scope
of asset collections that it can be applied to.
Once the script has been declared correctly, as above,
and the .sms.* file is in the workspace of the EDG
installation, users would see a fully clickable entry
for the script on the Import tab. For custom
teamwork:ProjectTypes, make sure that
teamwork:ScriptBasedImportPlugin is declared as a
teamwork:projectPlugin.
--
Maybe this helps?
I noticed that this feature is currently on visible for
production copies (master graph) but I will enable it
for working copies too.
On 17/07/2018 10:08, Rob Atkinson wrote:
The EDG developer guide states
"There is also a generic SPARQLMotion-based importer
mechanism that applies to all vocabulary types. Such
importers receive an uploaded file as input and produce
triples that shall be added to the current vocabulary
or working copy. In order to create such importers,
store them in a file ending with |.sms.*|. Import the
file |teamworkscripts.ttl| and use the properties
defined therein to link your |sm:Function| either with
a vocabulary type or specific vocabularies for which
the function shall show up. The script needs to end
with |sml:ReturnRDF| and take exactly one string
argument - the body of the uploaded file."
there are no links and am not finding anything via
google or help.
- so i'm trying to interpret just what "to the current
vocabulary or working copy" means - and what it means
for design of custom importers.
poking around in the code base I find reference to
teamwork:scriptBasedFileImport
and teamwork:ScriptBasedFileImportService
with an arg:script: sm:Function parameter
so presumably this means a sparqlmotion script that
returns a RDF graph?
There are a few moving parts in an EDG importer -
the plugin
which references a entry page
which calls a service
which calls a function inside a transaction
context
there seems to be a fair bit of contract implied in
each of these layers - and teamwork logic is at the
heart of it all.
There are three separate graphs involved (?) - the data
being imported, the project (data asset) and its
"teamwork graph". How does the "working copy" concept
and the importer relate?
EDG default importers appear to put data into the
production copy, but there are also transactions
involved - so what state is the production copy in
during the import process?
The importer script only produces new triples. The
surrounding engine then adds those triples as a
transaction. The state of the current graph is whatever
triples are in there before the import.
Holger
Maybe there is some resource that lays this out like a
proper Use Case with specified pre-conditions and
post-conditions. In a design-by-contract environment
like TBC we need to know the contract :-(
I suspect there is probably some resource out there
that explains all this - but neither links or search
are my friend..
--
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
[email protected].
For more options, visit
https://groups.google.com/d/optout
<https://groups.google.com/d/optout>.
--
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 [email protected].
For more options, visit https://groups.google.com/d/optout
<https://groups.google.com/d/optout>.
--
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 [email protected] <javascript:>.
For more options, visit https://groups.google.com/d/optout
<https://groups.google.com/d/optout>.
--
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 [email protected]
<mailto:[email protected]>.
For more options, visit https://groups.google.com/d/optout.
--
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 [email protected].
For more options, visit https://groups.google.com/d/optout.
