search

SEMICeu / iso-19139-to-dcat-ap

Reference XSLT-based implementation of GeoDCAT-AP
European Union Public License 1.2
15 stars 9 forks source link

vcard:organization should be foaf:org? #10

Closed pvgenuchten closed 3 years ago

pvgenuchten commented 3 years ago

At https://github.com/SEMICeu/iso-19139-to-dcat-ap/blob/e7aa2d802f6e337ffce64c9167c66b835916f421/iso-19139-to-dcat-ap.xsl#L1662 a vcard:Organisation is mentioned, I get a conflict with a foaf:organization with same uri at https://github.com/SEMICeu/iso-19139-to-dcat-ap/blob/e7aa2d802f6e337ffce64c9167c66b835916f421/iso-19139-to-dcat-ap.xsl#L1577

andrea-perego commented 3 years ago

If I correctly understood, the issue is that the same URI is associated with a resource which is both a vcard:Organization and a foaf:Organization.

In RDF, this is not a problem: a resource may be the instance of multiple classes, and vcard:Organization and foaf:Organization are not disjoint.

Is this causing a problem at the implementation level?

pvgenuchten commented 3 years ago

Yes, it raises a problem, because we encode from each iso record the organisations listed, minting a identifier consisting of organisationname+email, in that case many instances of a single organisation arrive in the end result, some being foaf:organisations some vcard:organisation, a validator we use then complains about "too many types" for the entity.

i'm not sure if the approach to create many organisations with the same identifier is valid (in some implementations we notice the final entity receives a title property from each instance of the record.

pvgenuchten commented 3 years ago

Mmm, seems in our case a foaf:agent is required for publisher and vCard:org for contact point, solving it by creating 2 organizations with unique identifier