[topbraid-users] rdfs using owl

['Bohms, H.M. (Michel)' via TopBraid Suite Users]

Dear Irene, David

We got the following question on our EU standard proposal:

Why are you using owl in your rdfs spec (for owl:Ontology and owl:imports).

Isn't this simply best practice?
Could you do without ie be RDFS pure?

But how then do you specify the graph uri and how to deal with imports??

Thx for your views, Michel





Dr. ir. H.M. (Michel) Bohms
Scientist Specialist
Structural Reliability

T +31 (0)88 866 31 07
M +31 (0)63 038 12 20
E michel.bo...@tno.nl

Location



[cid:image001.gif@01D761F2.11844520]

This message may contain information that is not intended for you. If you are 
not the addressee or if this message was sent to you by mistake, you are 
requested to inform the sender and delete the message. TNO accepts no liability 
for the content of this e-mail, for the manner in which you use it and for 
damage of any kind resulting from the risks inherent to the electronic 
transmission of messages.




-- 
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-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/topbraid-users/16aed2c420a14a8eae0a9fc7db8b772a%40tno.nl.

Re: [topbraid-users] rdfs using owl

[Holger Knublauch]

owl:imports is the only feature of OWL that even SHACL mentions because 
there is no real alternative, and it is quite harmless.


Holger


On 15/06/2021 10:23 pm, 'Bohms, H.M. (Michel)' via TopBraid Suite Users 
wrote:


Dear Irene, David

We got the following question on our EU standard proposal:

Why are you using owl in your rdfs spec (for owl:Ontology and 
owl:imports).


Isn’t this simply best practice?

Could you do without ie be RDFS pure?

But how then do you specify the graph uri and how to deal with imports??

Thx for your views, Michel



Dr. ir. H.M. (Michel) Bohms
Scientist Specialist
Structural Reliability



T +31 (0)88 866 31 07
M +31 (0)63 038 12 20
E michel.bo...@tno.nl 



Location 



This message may contain information that is not intended for you. If 
you are not the addressee or if this message was sent to you by 
mistake, you are requested to inform the sender and delete the 
message. TNO accepts no liability for the content of this e-mail, for 
the manner in which you use it and for damage of any kind resulting 
from the risks inherent to the electronic transmission of messages.



--
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-users+unsubscr...@googlegroups.com 
.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/topbraid-users/16aed2c420a14a8eae0a9fc7db8b772a%40tno.nl 
.


--
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-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/topbraid-users/3ea7c130-956a-b9bf-ae03-679b73dd3773%40topquadrant.com.

Re: [topbraid-users] rdfs using owl

[David Price]

> On 15 Jun 2021, at 14:07, Holger Knublauch  wrote:
> 
> owl:imports is the only feature of OWL that even SHACL mentions because there 
> is no real alternative, and it is quite harmless.
> 
> Holger
> 
> 
> 
I was writing something which I guess explains Holger's “no real alternative” 
statement. Modularization of RDF-based ontologies and data is the business use 
case being supported and it cannot be done in formally defined, not 
implementation-specific way using only RDF and RDFS.

TBC uses owl:import to define the graph closure for a domain of interest.

RDFS says zero about named graphs, depending on RDF. RDF talks about RDF 
Datasets and the default graph which is the union of everything visible to the 
RDF tool (as far as I can interpret it) but the spec says nothing about how the 
“collection of RDF graphs” is defined or located. It also says nothing about 
how the “set of RDF Triples” that constitute the RDF Graph is defined or 
located.

Give that neither the “set of triples” or “collection of graphs” is formally 
defined, it’s easy to argue that the SPARQL GRAPH keyword actually has little 
or no formal meaning (does one graph need another and if so how is that 
relation specified?).

OWL introduces a more powerful way to manage and relate named graphs and TBC 
takes advantage of that so users can control what triples are visible where. 
Technically I think that is what the RDF spec means by “RDF source” and I think 
that equates to the Ontology Document idea in the OWL2 spec.

Anyway … RDFS purists can simply ignore (or remove) anything in the OWL 
namespace if they have some other way to build RDF Datasets and Named Graphs 
and graph relations in their tooling. In a way the OWL simply provides hints 
about what the graph URIs are and how they are related to other graphs for 
humans when ignored by the tool. In your standards case, you started with OWL 
and “dumbed down" everything you could into RDFS leaving only what formally 
defines the named graph closure.  Note that the OSLC which produces RDFS 
standard ontologies uses owl:Ontology to manage named graphs, so TBC is also 
just following industry usage patterns (as are you).

WRT “best practice” I do sometimes find RDFS that has nothing defining how the 
named graphs relate, sometimes with multiple named graphs in the same RDF/XML 
or TTL file. Usually what you find is that the developers of that content 
actually manage everything separately and then concatenate it into a singe TTL 
at the end. It seems they assume whatever triples they produce is *all* the 
triples and/or can be concatenated with anything else - IMO very odd indeed and 
not nearly as useful to others as having the original separate files.

Not sure if that helps the EU, but explains how TBC works and why. 

Cheers,
David


> On 15/06/2021 10:23 pm, 'Bohms, H.M. (Michel)' via TopBraid Suite Users wrote:
>> Dear Irene, David
>>  
>> We got the following question on our EU standard proposal:
>>  
>> Why are you using owl in your rdfs spec (for owl:Ontology and owl:imports).
>>  
>> Isn’t this simply best practice?
>> Could you do without ie be RDFS pure?
>>  
>> But how then do you specify the graph uri and how to deal with imports??
>>  
>> Thx for your views, Michel
>>  
>>  
>>  
>>  
>> Dr. ir. H.M. (Michel) Bohms
>> Scientist Specialist
>> Structural Reliability
>> T +31 (0)88 866 31 07
>> M +31 (0)63 038 12 20
>> E michel.bo...@tno.nl    
>> Location 
>> 
>>  
>>  
>> This message may contain information that is not intended for you. If you 
>> are not the addressee or if this message was sent to you by mistake, you are 
>> requested to inform the sender and delete the message. TNO accepts no 
>> liability for the content of this e-mail, for the manner in which you use it 
>> and for damage of any kind resulting from the risks inherent to the 
>> electronic transmission of messages. 
>> 
>>  
>> -- 
>> 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-users+unsubscr...@googlegroups.com 
>> .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/topbraid-users/16aed2c420a14a8eae0a9fc7db8b772a%40tno.nl
>>  
>> .
> 
> -- 
> 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-users+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/topbraid-users/3ea7c130-956a-b9bf-ae03

RE: [topbraid-users] rdfs using owl

['Bohms, H.M. (Michel)' via TopBraid Suite Users]

Thank you Holger, David

Very useful arguments we can use in our justification for choices,
Michel



Dr. ir. H.M. (Michel) Bohms
Scientist Specialist
Structural Reliability

T +31 (0)88 866 31 07
M +31 (0)63 038 12 20
E michel.bo...@tno.nl

Location



[cid:image001.gif@01D7620B.89133A60]

This message may contain information that is not intended for you. If you are 
not the addressee or if this message was sent to you by mistake, you are 
requested to inform the sender and delete the message. TNO accepts no liability 
for the content of this e-mail, for the manner in which you use it and for 
damage of any kind resulting from the risks inherent to the electronic 
transmission of messages.




Van: topbraid-users@googlegroups.com  Namens 
David Price
Verzonden: dinsdag 15 juni 2021 15:30
Aan: topbraid-users@googlegroups.com
Onderwerp: Re: [topbraid-users] rdfs using owl




On 15 Jun 2021, at 14:07, Holger Knublauch 
mailto:hol...@topquadrant.com>> wrote:

owl:imports is the only feature of OWL that even SHACL mentions because there 
is no real alternative, and it is quite harmless.
Holger

I was writing something which I guess explains Holger's “no real alternative” 
statement. Modularization of RDF-based ontologies and data is the business use 
case being supported and it cannot be done in formally defined, not 
implementation-specific way using only RDF and RDFS.

TBC uses owl:import to define the graph closure for a domain of interest.

RDFS says zero about named graphs, depending on RDF. RDF talks about RDF 
Datasets and the default graph which is the union of everything visible to the 
RDF tool (as far as I can interpret it) but the spec says nothing about how the 
“collection of RDF graphs” is defined or located. It also says nothing about 
how the “set of RDF Triples” that constitute the RDF Graph is defined or 
located.

Give that neither the “set of triples” or “collection of graphs” is formally 
defined, it’s easy to argue that the SPARQL GRAPH keyword actually has little 
or no formal meaning (does one graph need another and if so how is that 
relation specified?).

OWL introduces a more powerful way to manage and relate named graphs and TBC 
takes advantage of that so users can control what triples are visible where. 
Technically I think that is what the RDF spec means by “RDF source” and I think 
that equates to the Ontology Document idea in the OWL2 spec.

Anyway … RDFS purists can simply ignore (or remove) anything in the OWL 
namespace if they have some other way to build RDF Datasets and Named Graphs 
and graph relations in their tooling. In a way the OWL simply provides hints 
about what the graph URIs are and how they are related to other graphs for 
humans when ignored by the tool. In your standards case, you started with OWL 
and “dumbed down" everything you could into RDFS leaving only what formally 
defines the named graph closure.  Note that the OSLC which produces RDFS 
standard ontologies uses owl:Ontology to manage named graphs, so TBC is also 
just following industry usage patterns (as are you).

WRT “best practice” I do sometimes find RDFS that has nothing defining how the 
named graphs relate, sometimes with multiple named graphs in the same RDF/XML 
or TTL file. Usually what you find is that the developers of that content 
actually manage everything separately and then concatenate it into a singe TTL 
at the end. It seems they assume whatever triples they produce is *all* the 
triples and/or can be concatenated with anything else - IMO very odd indeed and 
not nearly as useful to others as having the original separate files.

Not sure if that helps the EU, but explains how TBC works and why.

Cheers,
David



On 15/06/2021 10:23 pm, 'Bohms, H.M. (Michel)' via TopBraid Suite Users wrote:
Dear Irene, David

We got the following question on our EU standard proposal:

Why are you using owl in your rdfs spec (for owl:Ontology and owl:imports).

Isn’t this simply best practice?
Could you do without ie be RDFS pure?

But how then do you specify the graph uri and how to deal with imports??

Thx for your views, Michel





Dr. ir. H.M. (Michel) Bohms
Scientist Specialist
Structural Reliability

T +31 (0)88 866 31 07
M +31 (0)63 038 12 20
E michel.bo...@tno.nl

Location





This message may contain information that is not intended for you. If you are 
not the addressee or if this message was sent to you by mistake, you are 
requested to inform the sender and delete the message. TNO accepts no liability 
for the content of this e-mail, for the manner in which you use it and for 
damage of any kind resulting from the risks inherent to the electronic 
transmission of messages.




--
You received this message because you are subscribed to the Google Groups 
"TopBraid Suite Users" group.
To unsubscribe from this group and stop 

Re: [topbraid-users] rdfs using owl

[robatki...@gmail.com]

On the subject of

 " WRT “best practice” I do sometimes find RDFS that has nothing defining 
how the named graphs relate, sometimes with multiple named graphs in the 
same RDF/XML or TTL file. Usually what you find is that the developers of 
that content actually manage everything separately and then concatenate it 
into a singe TTL at the end. It seems they assume whatever triples they 
produce is *all* the triples and/or can be concatenated with anything else 
- IMO very odd indeed and not nearly as useful to others as having the 
original separate files."

This "flattening of imports in a selective way that suits some specific 
needs I have.. " is a very common pattern (and IMHO an anti-pattern that 
loses information about interoperability intent ..)

Having come across this repeatedly when trying to determin or check the 
scope of application of standardised models,  I generated a "little" tool 
that addressed a few other issues as well, including non-resolution of 
identifiers for vocabularies only accessible via idiosyncratic repository 
interfaces...

Its at https://github.com/RDFLib/profilewiz

my hope is to be able to incorporate some of this in future into the TQ 
environment to support interoperable interfaces to graph using JSON-LD with 
controlled JSON schemas.  I can imagine using an EDG instance to support 
the SHACL generation component and validation services as well as 
publishing the results.


On Wednesday, 16 June 2021 at 01:26:15 UTC+10 Bohms, H.M. (Michel) wrote:

> Thank you Holger, David
>
>  
>
> Very useful arguments we can use in our justification for choices,
>
> Michel
>
>  
>
>  
>
> Dr. ir. H.M. (Michel) Bohms
> Scientist Specialist
> Structural Reliability
>
> T +31 (0)88 866 31 07
> M +31 (0)63 038 12 20
> E michel...@tno.nl
>
> Location 
>
>  
>
> 
>
> This message may contain information that is not intended for you. If you 
> are not the addressee or if this message was sent to you by mistake, you 
> are requested to inform the sender and delete the message. TNO accepts no 
> liability for the content of this e-mail, for the manner in which you use 
> it and for damage of any kind resulting from the risks inherent to the 
> electronic transmission of messages. 
>
>  
>
> *Van:* topbrai...@googlegroups.com  *Namens 
> *David 
> Price
> *Verzonden:* dinsdag 15 juni 2021 15:30
> *Aan:* topbrai...@googlegroups.com
> *Onderwerp:* Re: [topbraid-users] rdfs using owl
>
>  
>
>  
>
>
>
> On 15 Jun 2021, at 14:07, Holger Knublauch  wrote:
>
>  
>
> owl:imports is the only feature of OWL that even SHACL mentions because 
> there is no real alternative, and it is quite harmless.
>
> Holger
>
>  
>
> I was writing something which I guess explains Holger's “no real 
> alternative” statement. Modularization of RDF-based ontologies and data is 
> the business use case being supported and it cannot be done in formally 
> defined, not implementation-specific way using only RDF and RDFS.
>
>  
>
> TBC uses owl:import to define the graph closure for a domain of interest.
>
>  
>
> RDFS says zero about named graphs, depending on RDF. RDF talks about RDF 
> Datasets and the default graph which is the union of everything visible to 
> the RDF tool (as far as I can interpret it) but the spec says nothing about 
> how the “collection of RDF graphs” is defined or located. It also says 
> nothing about how the “set of RDF Triples” that constitute the RDF Graph is 
> defined or located.
>
>  
>
> Give that neither the “set of triples” or “collection of graphs” is 
> formally defined, it’s easy to argue that the SPARQL GRAPH keyword actually 
> has little or no formal meaning (does one graph need another and if so how 
> is that relation specified?).
>
>  
>
> OWL introduces a more powerful way to manage and relate named graphs and 
> TBC takes advantage of that so users can control what triples are visible 
> where. Technically I think that is what the RDF spec means by “RDF source” 
> and I think that equates to the Ontology Document idea in the OWL2 spec.
>
>  
>
> Anyway … RDFS purists can simply ignore (or remove) anything in the OWL 
> namespace if they have some other way to build RDF Datasets and Named 
> Graphs and graph relations in their tooling. In a way the OWL simply 
> provides hints about what the graph URIs are and how they are related to 
> other graphs for humans when ignored by the tool. In your standards case, 
> you started with OWL and “dumbed down" everything you could into RDFS 
> leaving only what formally defines the named graph closure.  Note that the 
> OSLC which produces RDFS standard ontologies uses owl:Ontology to manage 
> named graphs, so TBC is also just following industry usage patterns (as are 
> you).
>
>  
>
> WRT “best practice” I do sometimes find RDFS that has nothing defining how 
> the named graphs relate, sometimes with multiple named graphs in the same 
> RDF/XML or TTL file. Usually what you fin