search

w3c / vsso

The Vehicle Signal Ontology (VSSo) based on COVESA VSS and making use of the SOSA/SSN modeling patterns
Other
15 stars 12 forks source link

Define namespace for vsso-core / vsso #17

Closed danielwilms closed 2 years ago

danielwilms commented 2 years ago

We would have to define the namespace for:

@tguild: could you help with that?

rtroncy commented 2 years ago

What will be the difference between vsso and vsso-core? Both namespaces host vocabulary terms definitions and triples ultimately.

danielwilms commented 2 years ago

I was thinking, that we have a stable core and generated triples from vss, which updates with the speed of VSS and follows VSS versioning. I think it could be could to show this explicitly. What do you think @rtroncy?

rtroncy commented 2 years ago

I'm not against separating a core from possibly more dynamic extensions (SOSA did this too) but namespaces need to be carefully chosen. Can you make explicit what you will put in the core versus what you believe will be more dynamic (in terms of concrete examples)?

danielwilms commented 2 years ago

@rtroncy, split I would see as following:

Core stays (more) stable, vsso gets generated with every version and will always 'live'

rtroncy commented 2 years ago

Does really vss change so often? Without any proper snapshot / versioning mechanism in place? I find that doubling the number of namespaces is an obstacle for data consumers since any user of vsso would need to always embark the 2 namespaces.

tguild commented 2 years ago

I apparently didn't register vsso as a namespace when Raphael made the Member Submission, probably as that would be too early.

@caribouW3 can we have these namespaces before FPWD (now targeting January)

https://www.w3.org/ns/vsso and https://www.w3.org/ns/vsso-core

@danielwilms what can be at a namespace URI can vary, it could be a simple placeholder HTML document with links to resources, fuller html document, ttl, rdfs and other alternatives that get served via content negotiation. I prefer a human readable document with links to resources but that is a personal preference. Content negotiation can cause some confusion.

caribouW3 commented 2 years ago

@tguild yes, I can set those up even without meaningful content to start with.

rtroncy commented 2 years ago

+1 for a HTML document behind these URLs that would point out to the machine readable representation (ttl, jsonld, etc.).

I'm still asking why do we need 2 namespaces though.

danielwilms commented 2 years ago

Does really vss change so often? Without any proper snapshot / versioning mechanism in place?

VSS has proper versioning behind it and is released in the ideal case up to 4 times per year. I see that VSS focuses on the VehiclePropery while others can define VehicleComponent in more details. We have the case for example defining concepts for traceability, where you want to get the bill of materials for a certain VehicleComponent. In this case all you need for that is a stable vsso-core.

I find that doubling the number of namespaces is an obstacle for data consumers since any user of vsso would need to always embark the 2 namespaces.

I relate to that argument. Maybe we can start with two documents under one namespace for the ontology and then see if a separation is useful. What do you think @rtroncy? @felixloesch, @tguild any opinion on that?

felix-loesch commented 2 years ago

I have the following comments:

  1. I agree that splitting VSSo into 2 namespaces makes sense to separate the definition of core concepts from the actual VSS content, i.e. concrete signal and component definitions. "vsso-core": for core concepts (e.g. VehicleComponent, StaticVehicleProperty, DynamicVehicleProperty, ....) "vss": for the content coming from VSS (e.g. concrete properties
  2. Regarding the "vss" namespace we should also include the VSS version number to differentiate different VSS versions. This is needed to prevent naming clashes between different VSS versions in VSSo.
rtroncy commented 2 years ago

@danielwilms moving terms from one namespace to another could also bring confusion for future data consumers so I would rather think carefully now what we imagine.

If applications making use of the sole envisioned vsso-core (e.g. for billing certain VehicleComponent components) will exist, then this justifies the separation of the ontology in two different namespaces and we could follow your original idea.

A few caveats:

danielwilms commented 2 years ago

@danielwilms moving terms from one namespace to another could also bring confusion for future data consumers so I would rather think carefully now what we imagine.

I think you're right here.

If applications making use of the sole envisioned vsso-core (e.g. for billing certain VehicleComponent components) will exist, then this justifies the separation of the ontology in two different namespaces and we could follow your original idea.

That's what I see now, when using it internally that this is a valid use case. I think it could be beneficial that way.

You're saying that VSS is updated 4 times a year ... but what type of updates is proposed? I assume rather monotonic ones, such as the new terms being added, maybe some being renamed but no profound changes in the structure, correct?

Correct. As a consequence the vsso-core wouldn't be touched.

OWL has owl:versionInfo and owl:priorVersion as Annotation Properties to indicate which version of the ontology a user agent is consuming.

Fully agree here.