Dear Martin, All >> And we are trying to find one appropriate space (or schema) for >> identification. > Absolutely not: We are trying to find a minimal number of schemata. There is > no > single schema. The necessary dimensions are not equally known for all > persons or objects.
It is good that my "strong" statement isn't true ) Some thoughts about possible basis for objects identificators: It is much better when object identifier contains "relatively stable" values. I mean, values that do not (or rarely) change while the identified object is in documentation. If so, an identifier of an object should contain minimal number of role values the object has. (Ideally, an object identifier should not change, when a context of the object changes) 1. Predicates "P2.has type" or "rdf:type" and similar do not represent roles between objects, but a categorisation. So, they go together with different types of object numbers. (Of course, they all may change one day!) 2. If one use time-related roles (such as "belongs to museum"), then it is good to include time (when the role holds) into an identifier. This could directly point to sets of related documents in different museums. I wonder, if some museums may reuse deprecated numbers for new objects? 3. Geo names: It wouldn't be very good if one day (when a part of USSR "transformed to" Russian Federation in 1991) we derive millions of new (and millions of "outdated") identifiers of the same objects. (But, of course, it is recoverable situation) Best regards, Vladimir P.S.: Reinventing rigid properties from [http://www.loa-cnr.it/Papers/EKAW-2000.pdf] ? 2008/12/17 martin <[email protected]>: > Dear Vladimir, > > This is not what I described: > > Vladimir Ivanov wrote: >> >> Dear All, >> >> It is common point of view that, >> real world objects could be represented in a >> multidimensional (data) space >> (I suppose that in our case the space correspond to schema of URN etc.). >> >> Martin's example: >> >> ID of P.Picasso in 4-dimensional space: >> urn:crm_actor:aacr2:picasso.pablo/1881-1973 >> >> If I get the idea of discussion correctly, there are >> a lot of proposals for such a (necessary & sufficient) spaces >> that could be used to create(refer to) an unique identifier >> of a given object (e.g. museum). > > Yes, correct. >> >> And we are trying to find one appropriate space (or schema) for >> identification. > > Absolutely not: We are trying to find a minimal number of schemata. There is > no > single schema. The necessary dimensions are not equally known for all > persons or objects. >> >> Maybe we should talk not about spaces and dimensions themselves, but >> about transformations between different spaces with different dimensions >> that preserve identity. > > This is the coreference problem. > > The job is to find a minimal number of schemata, that optimizes the mapping > between > the spaces, and makes recovery from wrong mappings affordable. > > Another point is, that institutions must begin to define rules how their > things > should appear in RDF graphs. Since this is a user group mailing list: > museums are > asked to understand that there is a job to do. > > Either in the cidoc coreference group, or in crm-sig, or in both, or in a > new > CIDOC working group, someone should begin to make recommendations for people > and > object identifiers. > > Best, > > Martin > > >> >> Best regards, >> Vladimir >> >> 2008/12/17 Maximilian Schich <[email protected]>: >>> >>> Dear Martin, >>> >>> from an even more flexible point of view, your solution and a swamp of >>> local IDs do not exclude each other. >>> Your solution may be necessary from a technical point. Without the local >>> IDs however most of the published data will be useless for scholarship. >>> I think we need both, and therefore I am very strongly in favor of not >>> drying out the swamp. >>> >>> Please let me explain this with two real world examples. The first >>> example will deal with local IDs as the basis of scholarship. The second >>> example will deal with the problem of wikinomic scaling: >>> >>> First: Local IDs as the basis of scholarship: >>> >>> In New York there are 10 to the power of 7 inhabitants, which are >>> surrounded by 10 to the power of 10 barcoded objects. In other words, >>> there are at least one thousand objects with an ID per inhabitant. >>> Obviously it is possible to survive in New York. >>> Consider the following situation: Say a guy has an urgent appointment in >>> an upper floor of a high-rise building. He runs against a >>> fire-extinguisher and breaks the fixture. The fixture and the >>> fire-extinguisher both carry two barcodes, a global one (representing >>> the brand and the model) and a local one (representing the inventory >>> number of the high-rise-building). >>> Now if the guy (who does not belong to the high-rise!) calls the front >>> desk, both IDs are significant. The global ID will enable service to >>> order a new fixture, the local ID will point to the exact location of >>> the rotten extinguisher, i.e. the particular instance. >>> >>> In the same way we need global IDs as well as local IDs for people or >>> any other instance we are talking about. Most of our cultural heritage >>> data is made by local activity and serves further research. As any >>> research material, the data needs to be citeable. Just like scholarly >>> documents have a publication location and page numbers, our data needs a >>> publication location and local identifiers. >>> If I discuss the identity of an actor in someone else's data, for e.g. >>> by saying "The guy you are talking about is not identical with Picasso", >>> I break the fixture of a fire extinguisher. Now if I call the front >>> desk, for e.g. by publishing a scholarly paper, my own rdf-data or a >>> blog-post, I also need two IDs: a local one and a global one. Otherwise >>> it will not be possible to write my machine-readable opinon that "local >>> ID x is not the same actor as global ID y". >>> >>> >>> Second: The problem of wikinomic scaling: >>> >>> It will be a real 'pain-point' for local authors to look up all the >>> relevant 'global-IDs'. My guess is, that it simply will not happen, much >>> in the same way as some people write articles in Wikipedia and others >>> correct the typos and assign the links. In such a scenario, local IDs >>> will significantly facilitate the assignment of global IDs to local >>> instances. >>> >>> I agree that: >>> >>> "The ultimate way to identify a person mentioned in a source is via the >>> source itself. It is the " 'he' , word nr. 576, in ISBN 76476-706-757" or >>> so." >>> >>> However we should not forget, that our data belongs to the Giant Global >>> Graph as opposed to the documents in the World Wide Web. Users will >>> visually spot a person projected onto a map, which is constructed from a >>> selection of a resorted list which is based on a hidden rdf graph. As a >>> consequence it would make much more sense, if the 'he' person in the >>> rdf-graph would carry a true 'local person-id' instead of 'some global >>> person-id in line 576 in the hidden rdf-document'. >>> >>> Best wishes, >>> max. >>> >>> Dr. des. Maximilian Schich M.A. >>> adr.: Westendstrasse 80 | D-80339 München | Germany >>> tel.: +49-179-6678041 | skype: maximilian.schich >>> mail: [email protected] | home: www.schich.info >>> >>> CONFIDENTIALITY NOTICE: This e-mail message including attachments, if >>> any, is intended only for the person or entity to which it is addressed >>> and may contain confidential and/or privileged material. Any >>> unauthorized review, use, disclosure or distribution is prohibited. If >>> you are not the intended recipient, please contact the sender by reply >>> e-mail and destroy all copies of the original message. Thank you. >>> >>> >>> >>> martin schrieb: >>>> >>>> The problem of identifier creation and co-reference resolution needs >>>> much more >>>> flexible thinking than we are used to. Obviously, there is no one >>>> recipe. >>>> But the problem is not so bad: >>>> >>>> If I am sure I talk about Picasso, I do not see any point to swamp the >>>> world with >>>> my local IDs. >>>> >>>> If I talk about Picasso, I am sure there are millions of references. >>>> >>>> If I talk about Picasso, it is good not create new URNs >>>> >>>> If I talk about John Smith's marriage registered in Small Village >>>> county, >>>> it is good to use a local ID. >>>> >>>> There will hardly be a central resource. >>>> >>>> If I talk about John Smith's marriage registered in Small Village >>>> county, >>>> there will be very few sources pointing to it. >>>> >>>> So, in both cases, we achieve the goal: Very few URNs per person. >>>> >>>> Think flexible, design adaptive algorithms. If you don't find your >>>> person X >>>> in a global resource, create a local ID, possibly with a complete >>>> different >>>> algorithm. >>>> >>>> For instance, if I have a document saying: >>>> >>>> "He, who set the Pireaus Bank of Heraklion on fire in 2008, was >>>> never identified" >>>> >>>> I may use better a different identifier generation algorithm >>>> representation >>>> from Smith, John George, (1901-1917). >>>> >>>> How many more cases do we have to discuss? I think this is already >>>> quite exhaustive. >>>> >>>> Would that be a topic for the coreference working group? >>>> >>>> Best, >>>> >>>> Martin >>>> >>>> Maximilian Schich wrote: >>>>> >>>>> I think you are right, referring to a more 'central' ID is always >>>>> preferable. >>>>> The date-range thing will probably work for Picasso, but I am not >>>>> sure if it would allow for a disambiguation of all the Lees, Kims, >>>>> Singhs and Smiths. >>>>> >>>>> In general I think, it would be nice, if there would be a local ID >>>>> for every person/instance, accompanied by a 'central' ID wherever >>>>> possible. This would allow for a much better discussion of the >>>>> provided data. Otherwise, i.e. with 'central' IDs only, it would not >>>>> be possible say for e.g. "I don't believe your person (local ID x) is >>>>> identical with Pablo Picasso ('central' ID y)". >>>>> In other words, all parties should publish their existing local IDs, >>>>> i.e. their database record numbers... , in addition to the 'central' >>>>> IDs which allow for better normalization. >>>>> >>>>> Basically I just don't like hidden information, which could be >>>>> explicit. >>>>> >>>>> Best wishes, >>>>> max. >>>>> >>>>> Dr. des. Maximilian Schich M.A. >>>>> adr.: Westendstrasse 80 | D-80339 München | Germany >>>>> tel.: +49-179-6678041 | skype: maximilian.schich >>>>> mail: [email protected] | home: www.schich.info >>>>> >>>>> CONFIDENTIALITY NOTICE: This e-mail message including attachments, if >>>>> any, is intended only for the person or entity to which it is addressed >>>>> and may contain confidential and/or privileged material. Any >>>>> unauthorized review, use, disclosure or distribution is prohibited. If >>>>> you are not the intended recipient, please contact the sender by reply >>>>> e-mail and destroy all copies of the original message. Thank you. >>>>> >>>>> >>>>> On 16.12.2008 20:36 Uhr, martin wrote: >>>>>> >>>>>> I agree. The point is very simple: >>>>>> >>>>>> There will be a long tail of URNs anyhow. If every local database >>>>>> creates its >>>>>> own identifier, the list will be much, much longer. >>>>>> >>>>>> For guys like Picasso, >>>>>> referring either to VIAF or to ULAN would be currently a very >>>>>> sensible choice. >>>>>> (viaf.org : "Picasso, Pablo, ‡d 1881-1973" or "DNB|118594206") >>>>>> The likelihood of the two would be very high. That makes the world >>>>>> very small. >>>>>> Alternatively, we could create a normalized access point "Picasso, >>>>>> Pablo (1881-1973), >>>>>> such as : urn:crm_actor:aacr2:picasso.pablo/1881-1973 >>>>>> >>>>>> Do you like it? >>>>>> >>>>>> I don't know, how many people have exactly the same birth and death >>>>>> dates and names. >>>>>> >>>>>> Best, >>>>>> >>>>>> Martin >>>>>> >>>>>> Maximilian Schich wrote: >>>>>>> >>>>>>> (posted in this thread for continuity - also relevant for URI >>>>>>> policies) >>>>>>> >>>>>>> Dear All, >>>>>>> >>>>>>> I agree with Martin: There should be a URN or something equivalent >>>>>>> for Picasso in ULAN. >>>>>>> >>>>>>> However, we should not underestimate the long tail phenomenon: >>>>>>> >>>>>>> * There will be loads of URNs for some single guys (like Picasso). >>>>>>> Indeed the co-reference of all those Picasso-Identifiers will be >>>>>>> hard to resolve. (I would bet there will not only be a long tail >>>>>>> of URN frequency, i.e. how many URNs a Person has, but even a >>>>>>> long >>>>>>> tail of normalization, i.e. in the distribution how often >>>>>>> specific >>>>>>> URNs are used for a person). >>>>>>> * On the other hand there will be a huge load of people in the >>>>>>> long >>>>>>> tail without any URN in norm-data sources like ULAN (think of >>>>>>> 'the >>>>>>> guy, who did the non-art sculpture my schoolyard' or 'the guy >>>>>>> who >>>>>>> paints sheep from Naples, but isn't the guy who paints sheep >>>>>>> form >>>>>>> Naples'). >>>>>>> >>>>>>> As far as we know, there is no way to avoid the long tail! >>>>>>> >>>>>>> As a consequence, everybody has (to be able) to generate unique >>>>>>> identifiers. >>>>>>> >>>>>>> Kind regards, max. >>>>>>> >>>>>>> >>>>>>> On 16.12.2008 13:23 Uhr, martin wrote: >>>>>>>> >>>>>>>> Dear All, >>>>>>>> >>>>>>>> To my opinion, Pablo Picasso should be represented by a URN. I'd >>>>>>>> expect from the Getty >>>>>>>> a proposal how to write URNs for persons identified in ULAN. See >>>>>>>> discussion about URNs. >>>>>>>> >>>>>>>> Best, >>>>>>>> >>>>>>>> Martin >>>>>>>> >>>>>>>> Maximilian Schich wrote: >>>>>>>>> >>>>>>>>> I think we should encourage the owners of databases to use their >>>>>>>>> existing 'database record numbers'/ /in conjunction with an >>>>>>>>> identifier for their Institution as IDs for every conceivable >>>>>>>>> instance. >>>>>>>>> >>>>>>>>> Of course for 'Pablo Picasso' we would have a number of IDs: >>>>>>>>> an AKL number, another ULAN number, an ID from his city's birth >>>>>>>>> registry, a record number in every private database, and probably >>>>>>>>> an ID in the future all encompassing database (like for e.g. >>>>>>>>> http://en.wikipedia.org/w/index.php?oldid=257931703 for >>>>>>>>> http://en.wikipedia.org/wiki/Pablo_Picasso ). >>>>>>>>> >>>>>>>>> The String 'Pablo Picasso' is one of the worst IDs, as there >>>>>>>>> might be multiple language versions and different name formats. >>>>>>>>> For e.g. in the ISI Web of Science the (ambiguous) ID would be 'P >>>>>>>>> Picasso'; many people simply call him 'Picasso'; and his birth >>>>>>>>> name is 'Pablo Diego José Francisco de Paula Juan Nepomuceno >>>>>>>>> María de los Remedios Cipriano de la Santísima Trinidad Martyr >>>>>>>>> Patricio Clito Ruíz y Picasso' - (not a joke!). >>>>>>>>> >>>>>>>>> How to normalize the IDs is another question. As real data >>>>>>>>> usually comes in long tails, norm data is of limited help. >>>>>>>>> >>>>>>>>> Best wishes, max. >>>>>>>>> >>>>>>>>> Dr. des. Maximilian Schich M.A. >>>>>>>>> adr.: Westendstrasse 80 | D-80339 München | Germany >>>>>>>>> tel.: +49-179-6678041 | skype: maximilian.schich >>>>>>>>> mail: [email protected] | home: www.schich.info >>>>>>>>> >>>>>>>>> CONFIDENTIALITY NOTICE: This e-mail message including >>>>>>>>> attachments, if >>>>>>>>> any, is intended only for the person or entity to which it is >>>>>>>>> addressed >>>>>>>>> and may contain confidential and/or privileged material. Any >>>>>>>>> unauthorized review, use, disclosure or distribution is >>>>>>>>> prohibited. If >>>>>>>>> you are not the intended recipient, please contact the sender by >>>>>>>>> reply >>>>>>>>> e-mail and destroy all copies of the original message. Thank you. >>>>>>>>> >>>>>>>>> >>>>>>>>> On 15.12.2008 16:20 Uhr, Vadim Soshkin wrote: >>>>>>>>>> >>>>>>>>>> I am agree with approach of moving English terms from class and >>>>>>>>>> property identifiers to rdf:label. >>>>>>>>>> Why user's instance identifiers are different? What identifier >>>>>>>>>> are you are proposing for 'Pablo Picasso'? >>>>>>>>>> >>>>>>>>>> Best regards >>>>>>>>>> >>>>>>>>>> Vadim >>>>>>>>>> -----Original Message----- >>>>>>>>>> *From:* [email protected] >>>>>>>>>> [mailto:[email protected]]*On Behalf Of >>>>>>>>>> *Maximilian Schich >>>>>>>>>> *Sent:* Saturday, December 13, 2008 6:05 AM >>>>>>>>>> *To:* [email protected] >>>>>>>>>> *Cc:* 'crm-sig' >>>>>>>>>> *Subject:* Re: [Crm-sig] RDFS class identifiers >>>>>>>>>> >>>>>>>>>> "I want the version that has the class (E) or property (P) >>>>>>>>>> number plus the text in the label and just the class (E) or >>>>>>>>>> property (P) number in the ID." >>>>>>>>>> >>>>>>>>>> me too! This clarifies that the node with the ID 'E21' indeed >>>>>>>>>> represents a CIDOC-CRM concept like 'E21_Person' and not the >>>>>>>>>> word >>>>>>>>>> 'Person'. However we should clarifiy to the users, that they >>>>>>>>>> should not use a similar strategy in their rdf instances: The >>>>>>>>>> person 'Pablo Picasso' should not have an ID like '1495r3' >>>>>>>>>> and a >>>>>>>>>> label/appelation like '1495r3_Pablo_Picasso'. This seems >>>>>>>>>> logical >>>>>>>>>> from our point of view, but users may be tempted to do so. >>>>>>>>>> >>>>>>>>>> Can't we leave out * and #...? >>>>>>>>>> >>>>>>>>>> Kind regards, >>>>>>>>>> max. >>>>>>>>>> >>>>>>>>>> Dr. des. Maximilian Schich M.A. >>>>>>>>>> adr.: Westendstrasse 80 | D-80339 München | Germany >>>>>>>>>> tel.: +49-179-6678041 | skype: maximilian.schich >>>>>>>>>> mail: [email protected] | home: www.schich.info >>>>>>>>>> >>>>>>>>>> CONFIDENTIALITY NOTICE: This e-mail message including >>>>>>>>>> attachments, if >>>>>>>>>> any, is intended only for the person or entity to which it >>>>>>>>>> is addressed >>>>>>>>>> and may contain confidential and/or privileged material. Any >>>>>>>>>> unauthorized review, use, disclosure or distribution is >>>>>>>>>> prohibited. If >>>>>>>>>> you are not the intended recipient, please contact the >>>>>>>>>> sender by reply >>>>>>>>>> e-mail and destroy all copies of the original message. Thank >>>>>>>>>> you. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 13.12.2008 8:32 Uhr, Stephen Stead wrote: >>>>>>>>>>> >>>>>>>>>>> I want the version that has the class (E) or property (P) >>>>>>>>>>> number plus the text in the label and just the class (E) or >>>>>>>>>>> property (P) number in the ID. >>>>>>>>>>> Rgds >>>>>>>>>>> SdS >>>>>>>>>>> >>>>>>>>>>> Stephen Stead >>>>>>>>>>> Tel +44 20 8668 3075 Mob +44 7802 755 013 >>>>>>>>>>> E-mail [email protected] >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: [email protected] >>>>>>>>>>> [mailto:[email protected]] On Behalf Of Vladimir >>>>>>>>>>> Ivanov >>>>>>>>>>> Sent: 13 December 2008 07:15 >>>>>>>>>>> To: martin >>>>>>>>>>> Cc: crm-sig >>>>>>>>>>> Subject: Re: [Crm-sig] RDFS class identifiers >>>>>>>>>>> >>>>>>>>>>> Dear all, >>>>>>>>>>> >>>>>>>>>>> I agree with Nick. >>>>>>>>>>> This approach realises the statement that >>>>>>>>>>> CRM is not about (Entity and Proprty) names >>>>>>>>>>> but about (common, language independent) concepts. >>>>>>>>>>> >>>>>>>>>>> It also helps to manage multilingual version of the CRM when >>>>>>>>>>> we have EXX in scope notes and can extend it with "full name" >>>>>>>>>>> in a certain language. >>>>>>>>>>> >>>>>>>>>>> Example: >>>>>>>>>>> >>>>>>>>>>> <rdfs:Class rdf:ID="E21_"> >>>>>>>>>>> <rdfs:label xml:lang="en">Person</rdfs:label> >>>>>>>>>>> <rdfs:comment xml:lang="en">[Engish text]... E21_ [Engish >>>>>>>>>>> text].......</rdfs:comment>. >>>>>>>>>>> ... >>>>>>>>>>> <rdfs:label xml:lang="ru">????????</rdfs:label> >>>>>>>>>>> <rdfs:comment xml:lang="ru">[Russian text]... E21_ [Russian >>>>>>>>>>> text]...</rdfs:comment>. >>>>>>>>>>> ---------------- >>>>>>>>>>> >>>>>>>>>>> But natural language descriptions with codes and names are >>>>>>>>>>> simplier >>>>>>>>>>> than descriptions with codes only! >>>>>>>>>>> >>>>>>>>>>> Dear Martin, >>>>>>>>>>> I'am afraid that "stars" (or any other symbol) in >>>>>>>>>>> xml atributes may lead to some problems: >>>>>>>>>>> >>>>>>>>>>> 1. <rdfs:label xml:lang="*en*"> >>>>>>>>>>> Some systems do not recognize *en* as English (en). >>>>>>>>>>> >>>>>>>>>>> 2. <rdfs:subClassOf rdf:resource="*#E21*" /> >>>>>>>>>>> and <rdfs:Class rdf:ID="*E21*"> >>>>>>>>>>> refer to different entities . >>>>>>>>>>> >>>>>>>>>>> Maybe, we should write <rdfs:subClassOf >>>>>>>>>>> rdf:resource="#*E21*" /> ? >>>>>>>>>>> >>>>>>>>>>> Best regards, >>>>>>>>>>> Vladimir >>>>>>>>>>> >>>>>>>>>>> 2008/12/12 martin <[email protected]>: >>>>>>>>>>>> >>>>>>>>>>>> Dear Nick, >>>>>>>>>>>> >>>>>>>>>>>> I support this proposal as issue. >>>>>>>>>>>> >>>>>>>>>>>> I'd prefer however this form: >>>>>>>>>>>> >>>>>>>>>>>> <rdfs:Class rdf:ID="*E21*"> >>>>>>>>>>>> * * <rdfs:label xml:lang="*en*">*E21 Person*</rdfs:label> >>>>>>>>>>>> * * <rdfs:label xml:lang="*fr*">*E21 Personne*</rdfs:label> >>>>>>>>>>>> * * <rdfs:label xml:lang="*gr*">*E21 ???s?p?*</rdfs:label> >>>>>>>>>>>> * * <rdfs:subClassOf rdf:resource="*#E20*" /> >>>>>>>>>>>> * * <rdfs:subClassOf rdf:resource="*#E39*" /> >>>>>>>>>>>> </rdfs:Class> >>>>>>>>>>>> >>>>>>>>>>>> Opinions? >>>>>>>>>>>> >>>>>>>>>>>> Best, >>>>>>>>>>>> >>>>>>>>>>>> Martin >>>>>>>>>>>> >>>>>>>>>>>> Nicholas Crofts wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Dear all, >>>>>>>>>>>>> >>>>>>>>>>>>> I've been doing some work recently using the CRM rdfs. >>>>>>>>>>>>> http://cidoc.ics.forth.gr/rdfs/cidoc_v4.2.rdfs >>>>>>>>>>>>> >>>>>>>>>>>>> The naming convention adopted for the class and property >>>>>>>>>>>>> identifiers >>>>>>>>>>>>> strikes me as inconvenient in some respects. >>>>>>>>>>>>> Currently, the names used for the class and property >>>>>>>>>>>>> identifiers contain >>>>>>>>>>>>> both the CRM code and the English label. >>>>>>>>>>>>> >>>>>>>>>>>>> 1. If the labels get changed at any time in the future, >>>>>>>>>>>>> the identifiers >>>>>>>>>>>>> are broken >>>>>>>>>>>>> 2. Non English speakers are put at a disadvantage >>>>>>>>>>>>> 3. The rdf syntax is more verbose than necessary ... this >>>>>>>>>>>>> may sound >>>>>>>>>>>>> trivial but that overhead can be huge when migrating >>>>>>>>>>>>> large datasets. >>>>>>>>>>>>> 4. The names have been mangled with underscores to make >>>>>>>>>>>>> them respect >>>>>>>>>>>>> xml/rdf syntax. >>>>>>>>>>>>> >>>>>>>>>>>>> I would suggest using just the codes (i.e. E1, P2, etc.) >>>>>>>>>>>>> as class >>>>>>>>>>>>> identifiers and including the names (in various >>>>>>>>>>>>> languages) as rdf:labels. >>>>>>>>>>>>> >>>>>>>>>>>>> The result would like something like this: >>>>>>>>>>>>> >>>>>>>>>>>>> <rdfs:Class rdf:ID="*E21*"> >>>>>>>>>>>>> * * <rdfs:label xml:lang="*en*">*Person*</rdfs:label> >>>>>>>>>>>>> * * <rdfs:label xml:lang="*fr*">*Personne*</rdfs:label> >>>>>>>>>>>>> * * <rdfs:label xml:lang="*gr*">*???s?p?*</rdfs:label> >>>>>>>>>>>>> * * <rdfs:subClassOf rdf:resource="*#E20*" /> >>>>>>>>>>>>> * * <rdfs:subClassOf rdf:resource="*#E39*" /> >>>>>>>>>>>>> </rdfs:Class> >>>>>>>>>>>>> >>>>>>>>>>>>> Rather than this: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> <rdfs:Class rdf:ID="*E21.Person*"> >>>>>>>>>>>>> * * <rdfs:subClassOf >>>>>>>>>>>>> rdf:resource="*#E20.Biological_Object*" /> >>>>>>>>>>>>> * * <rdfs:subClassOf rdf:resource="*#E39.Actor*" /> >>>>>>>>>>>>> </rdfs:Class> >>>>>>>>>>>>> >>>>>>>>>>>>> (NB I've removed the rdfs:comments for clarity) >>>>>>>>>>>>> >>>>>>>>>>>>> It would be nice, of course, to be able to have both >>>>>>>>>>>>> forms and define >>>>>>>>>>>>> equivalence relationships between them. >>>>>>>>>>>>> This could perhaps be done with the rdfs:isDefinedBy >>>>>>>>>>>>> property? but I'm >>>>>>>>>>>>> not sure that it's meant for this. >>>>>>>>>>>>> >>>>>>>>>>>>> Best wishes >>>>>>>>>>>>> >>>>>>>>>>>>> Nick Crofts >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> ------------------------------------------------------------------------ >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> Crm-sig mailing list >>>>>>>>>>>>> [email protected] >>>>>>>>>>>>> http://lists.ics.forth.gr/mailman/listinfo/crm-sig >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -------------------------------------------------------------- >>>>>>>>>>>> Dr. Martin Doerr | >>>>>>>>>>>> Vox:+30(2810)391625 | >>>>>>>>>>>> Principle Researcher | >>>>>>>>>>>> Fax:+30(2810)391638 | >>>>>>>>>>>> | Email: >>>>>>>>>>>> [email protected] | >>>>>>>>>>>> >>>>>>>>>>>> | >>>>>>>>>>>> Center for Cultural >>>>>>>>>>>> Informatics | >>>>>>>>>>>> Information Systems >>>>>>>>>>>> Laboratory | >>>>>>>>>>>> Institute of Computer >>>>>>>>>>>> Science | >>>>>>>>>>>> Foundation for Research and Technology - Hellas >>>>>>>>>>>> (FORTH) | >>>>>>>>>>>> >>>>>>>>>>>> | >>>>>>>>>>>> Vassilika Vouton,P.O.Box1385,GR71110 >>>>>>>>>>>> Heraklion,Crete,Greece | >>>>>>>>>>>> >>>>>>>>>>>> | >>>>>>>>>>>> Web-site: >>>>>>>>>>>> http://www.ics.forth.gr/isl | >>>>>>>>>>>> >>>>>>>>>>>> -------------------------------------------------------------- >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> Crm-sig mailing list >>>>>>>>>>>> [email protected] >>>>>>>>>>>> http://lists.ics.forth.gr/mailman/listinfo/crm-sig >>>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Crm-sig mailing list >>>>>>>>>>> [email protected] >>>>>>>>>>> http://lists.ics.forth.gr/mailman/listinfo/crm-sig >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Crm-sig mailing list >>>>>>>>>>> [email protected] >>>>>>>>>>> http://lists.ics.forth.gr/mailman/listinfo/crm-sig >>>>>>>>> >>>>>>>>> >>>>>>>>> ------------------------------------------------------------------------ >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Crm-sig mailing list >>>>>>>>> [email protected] >>>>>>>>> http://lists.ics.forth.gr/mailman/listinfo/crm-sig >>>>>>> >>>>>>> Dr. des. Maximilian Schich M.A. >>>>>>> adr.: Westendstrasse 80 | D-80339 München | Germany >>>>>>> tel.: +49-179-6678041 | skype: maximilian.schich >>>>>>> mail: [email protected] | home: www.schich.info >>>>>>> >>>>>>> CONFIDENTIALITY NOTICE: This e-mail message including attachments, if >>>>>>> any, is intended only for the person or entity to which it is >>>>>>> addressed >>>>>>> and may contain confidential and/or privileged material. Any >>>>>>> unauthorized review, use, disclosure or distribution is prohibited. >>>>>>> If >>>>>>> you are not the intended recipient, please contact the sender by >>>>>>> reply >>>>>>> e-mail and destroy all copies of the original message. Thank you. >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Crm-sig mailing list >>>>>>> [email protected] >>>>>>> http://lists.ics.forth.gr/mailman/listinfo/crm-sig >>>>>>> >>>>>>> >>>>> _______________________________________________ >>>>> Crm-sig mailing list >>>>> [email protected] >>>>> http://lists.ics.forth.gr/mailman/listinfo/crm-sig >>>>> >>>>> >>>> >>> _______________________________________________ >>> Crm-sig mailing list >>> [email protected] >>> http://lists.ics.forth.gr/mailman/listinfo/crm-sig >>> >> >> _______________________________________________ >> Crm-sig mailing list >> [email protected] >> http://lists.ics.forth.gr/mailman/listinfo/crm-sig >> >> > > > -- > > -------------------------------------------------------------- > Dr. Martin Doerr | Vox:+30(2810)391625 | > Principle Researcher | Fax:+30(2810)391638 | > | Email: [email protected] | > | > Center for Cultural Informatics | > Information Systems Laboratory | > Institute of Computer Science | > Foundation for Research and Technology - Hellas (FORTH) | > | > Vassilika Vouton,P.O.Box1385,GR71110 Heraklion,Crete,Greece | > | > Web-site: http://www.ics.forth.gr/isl | > -------------------------------------------------------------- > >
