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

Relations of the Main elements #19

Open
igrangel opened this issue May 25, 2017 · 7 comments
Open

Relations of the Main elements #19

igrangel opened this issue May 25, 2017 · 7 comments
Assignees

Comments

@igrangel
Copy link
Contributor

Is the relation of RoleClass - Attributes covered?

@omarrana
Copy link
Contributor

Eclass Eversion and Eclassirdi are basically attributes and not specific to RoleClass. So no they cant be included unless we want it then we will have to give specific name to attributes.

@igrangel
Copy link
Contributor Author

I do not mean eClassIRDI, what I mean is the following:

<RoleClass Name="RoleClass1">
	<Attribute Name="Attribute1" AttributeDataType="xs:string">
		<RefSemantic CorrespondingAttributePath="010101" />
	</Attribute>
	<Attribute Name="Attribute2" AttributeDataType="xs:string">
		<RefSemantic CorrespondingAttributePath="020202" />
	</Attribute>
</RoleClass>

In this case, there is one RoleClass and two Attributes. Say we want to randomly generate N - M, e.g., One RoleClass and 4 appended Attritbutes: 1 - 4.

@omarrana
Copy link
Contributor

yes please close it

@igrangel
Copy link
Contributor Author

Would be possible to model this information in a way that we can make the generator extensible? For example, if we want to have the generator for AML, we would plug-in an AML-related ontology or RDF description and the generator would work. If we want another, e.g., OPC UA, and the ontology contains what is needed then the generator will work as well. What do you think?

@omarrana
Copy link
Contributor

omarrana commented Oct 2, 2017

Difficult with Rdf but might be possible with XSD.
We have to choose which path we go, current generator is based on XSD information.

@igrangel
Copy link
Contributor Author

igrangel commented Oct 2, 2017

Yes, it is based on XSD, but our center language is RDF. Our examples have been developed in XML, thus we have used XSD-based solutions but they can be CSV, text, etc and, for them, RDF would be the same. If we have our conceptualization of the model in RDF/OWL then we can map it from any language we used. Therefore, we can do it with XSD - RDF as well.

@omarrana
Copy link
Contributor

omarrana commented Oct 3, 2017

Just to clarify the current process of the generator, it generates the XML examples given its XSD mapping.
Later we convert xml to rdf for our processing.
We can incorporate RDF conversion in Generator, but our rdf conversion is limited to XML only.
Does this mean we need rdf model for other formats such as csv, text, database e.t.c?

Secondly , by XSD i mean the process is not automatic, we get the XSD file and generate java classes based on XSD and modify our generator.
This process can work for OPCUA as well if it has the provided XSD.
I have looked into it and it's possible to create for any XSD.

Now reading your comment, your idea is instead of XSD, we use RDF/OWL ontology to do the generation because some formats might not have xsd but another format such as csv, text e.t.c.

So the generator would basically generate RDF examples based on the ontology.

Please confirm me if i am on right path.

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

No branches or pull requests

2 participants