Re: [Crm-sig] HTML Page – identifiable portion of the HTML page / of a manuscript

[George Bruseker]

Dear Francesco,


> On Aug 29, 2018, at 5:01 PM, Francesco Beretta 
>  wrote:
> 
> Dear all,
> 
> How would you model in CRM 6.2 a HTML page that you can retrieve by entering 
> a URL in a web browser (and is therefore identified by the URL at a given 
> date) ? As a E90 Symbolic Object or a E73 Information Object ?
> 

I would say E73 as it is symbolic and propositional. Better yet, use D1 from 
CRMdig. As to the URL, it’s an appellation (since you could put that 
information object at a different point).

To capture read at, one would need an observation event or maybe a/the reading 
class?

> And if in this page I identify a spot, or arbitrarily defined portion of text 
> (e.g. paragraphs 3 to 5) , or in a manuscript a well identified portion of 
> the paper surface (by my description, e.g. the left corner of the manuscript 
> page, 3 x 3 inches) which is meaningful to me but not necessarily carries a 
> specific identifiable meaning in itself : how would you model this ?
For physical object, some E53 on the thing. For digital object, is more 
difficult… part with type? If it is just the text then you can just say that 
the E73 has part or incorporates this bit of text. If it is a screen shot, you 
could say that the one D1 carries features of the other D1. Depends on use case.

Those are my two cents anyhow.

G
> 
> Thans for your help !
> 
> 
> Francesco
> 
> ___
> Crm-sig mailing list
> Crm-sig@ics.forth.gr
> http://lists.ics.forth.gr/mailman/listinfo/crm-sig

Re: [Crm-sig] Issue: Solution for Dualism of E41 Appellation and rdfs:label

[Richard Light]

Hi,

Apologies for being so quiet on this front.

I'm puzzled by Martin's final declaration test: it says the intention is
to see if P1 can be a /superproperty /of rdfs:label, yet the declaration
(and consequent SPARQL query) asserts/tests that it is a /subproperty
/of rdfs:label:

> The next question is, if P1 can be declared superproperty of
> rdfs:label, so that the query for P1 returns everything CRM regards as
> Appellation. It works:
>
> It was tested by altering the cidoc-crm rdfs file, importing it in
> virtuoso and asking for the subproperties of rdfs:label as follows:
>
> 
>
>  is identified by
>
>  идентифицируется посредством
>
>  est identifiée par
>
>  é identificado por
>
>  
>
>   
>
> *  rdf:resource="http://www.w3.org/2000/01/rdf-schema#label
> "
> />*
> 
>
> 
>
> Query (Give me all the subproperties of rdfs:label) :
>
> select * where {
>
> ?p rdfs:subPropertyOf rdfs:label
>
> }
>
> Result from Virtuoso:
>
> p:
>
> http://www.cidoc-crm.org/cidoc-crm/P1_is_identified_by
> 
>
I suspect that in practice this distinction doesn't particularly matter
(though it does make my brain hurt :-)). Presumably the thinking is that
when you search for P1 relationships you will get all the rdfs:label
shortcuts as well?  (And not the other way round ...?)

Anyway, my point is that a single SPARQL expression cannot pick up both
fully-expressed P1's with an E41 on the end, and 'short cut' P1's with
rdfs:label.  This is because the shape of the RDF is different in the
two cases.  So you're going to have to query for both variant patterns
explicitly, and declaring P1 as a sub- or super-property of rdfs:label
isn't going to save you any time or effort.  Doing so might lead to
unwanted consequences, especially if CRM data forms part of a larger RDF
resource.

As regards your proposed short-cuts (and bearing in mind that P1 is
already a short-cut), I don't have strong views on which approach to
take.  I think that your experiments with Virtuoso demonstrate the 'open
world' nature of the RDFS framework; it allows multiple alternative
possibilities.

If we look at the definition of rdfs:label, it says it represents "a
human-readable version of a resource's /name/" (my italics).  As such,
it is certainly semantically close to our P1 property, whose range is an
E41 Appellation.  So that might be an argument for your second option:
using rdfs:label at the point where P1 would otherwise occur.

Like George, I originally liked the idea of using rdfs:value to
represent values (!), but on re-reading their definitions I now tend to
agree with Martin that rdfs:label is a closer fit, semantically, for our
purposes.  rdfs:value may still be useful for representing more complex
values (e.g. those involving values and units), and we may want to
consider deriving some useful CRM-specific subproperties of rdfs:value. 
But that's a discussion for another day ...

Best wishes,

Richard

On 10/09/2018 20:20, George Bruseker wrote:
> Dear all,
>
> I am a fan of the traditional solution:
>
> 1) E1 -> p1 -> E41 
>
> here the encoding all the way down to a value would be rdfs:value
> VALUE because we want to track the actual string used to represent the
> name (separate from the URI of the name)
>
> We use this solution whenever we want to name something about which we
> care for the name (much of the time)
>
> 2) rdfs:label Value
>
> This should be used on all nodes to give a human readable label. This
> is often enough if we don’t study the names used.
>
> Best,
>
> George
>

-- 
*Richard Light*

Re: [Crm-sig] Issue: Solution for Dualism of E41 Appellation and rdfs:label

[Nicola Carboni]

Dear all, 
>> I propose this method for the RDFS implementation of the CRM: two ranges for 
>> P1, namely E41 and rdf:Literal, and P1 superproperty of rdfs:label.
>> 

While punning could be a solution, I have to admit it not my favourite either.

In our daily practice, for encoding appellation strings we defined as best 
practice[1]:

Approach 1)  E1 → P1 is identified by → E41 Appellation → rdfs:Label → 
rdfs:Literal

The modelling above allow us the possibility to add further statements about 
the Appellation. Nevertheless, I have to admit that there has been cases where 
using rdfs:label on the entity (without using the appellation) was very much 
desired, because it would easier to display, and it would not create extra 
unnecessary triples (which could be a problem in big datasets).

We are, for now, sticking with the modelling above, which seems to be the most 
comprehensive and able to accomodate the most diverse needs. 
If I would vote, I would suggest Approach 1 as standard practice and the 
deprecation of the approaches 2 and 3 below:

Approach 2) E1 → P1 is identified by → E41 Appellation → P3 has note → 
rdfs:Literal
and
Approach 3) E1 → P1 is identified by → E41 Appellation → rdf:value → 
rdfs:Literal


If I may suggest, specification should also need be discussed for the preferred 
appellation, which does not have a corresponding property in CRM. Personally, 
we define each of the strings of a name as different appellation (unless they 
are transliteration) and specify the preferred one using P2 has type (more 
details here [2]).

Best, 

Nicola


[1] https://docs.cordh.net/modelling/#modelling-the-appellation 

[2] https://docs.cordh.net/modelling/#preferred-appellations-identifiers 




--
Nicola Carboni,
Semantic Architect
Swiss Art Research Infrastructure 
University of Zurich 
Post Box 23 
Ramistrasse 71 
8006 Zurich 
Switzerland




> On 10 Sep 2018, at 21:20, George Bruseker  wrote:
> 
> Dear all,
> 
> I am a fan of the traditional solution:
> 
> 1) E1 -> p1 -> E41 
> 
> here the encoding all the way down to a value would be rdfs:value VALUE 
> because we want to track the actual string used to represent the name 
> (separate from the URI of the name)
> 
> We use this solution whenever we want to name something about which we care 
> for the name (much of the time)
> 
> 2) rdfs:label Value
> 
> This should be used on all nodes to give a human readable label. This is 
> often enough if we don’t study the names used.
> 
> Best,
> 
> George
> 
> --
> Dr. George Bruseker
> R & D Engineer
> 
> Centre for Cultural Informatics
> Institute of Computer Science
> Foundation for Research and Technology - Hellas (FORTH)
> Science and Technology Park of Crete
> Vassilika Vouton, P.O.Box 1385, GR-711 10 Heraklion, Crete, Greece
> 
> Tel.: +30 2810 391619   Fax: +30 2810 391638   E-mail: bruse...@ics.forth.gr 
> 
> URL: http://www.ics.forth.gr/isl 
> 
>> On Sep 10, 2018, at 5:06 PM, Mark Fichtner > > wrote:
>> 
>> Dear all,
>> 
>> the main question for me is: Is the use of rdf:label in this case really the 
>> intended way by the CIDOC CRM? In fact P1 currently has a valid range and 
>> E41 is a valid class and not a primitive datatype. Why should we substitute 
>> this?
>> 
>> I agree with Martin that we should integrate old data that has a different 
>> model and therefore the proposal and the work is very nice to see. However I 
>> think we should have exactly one best practice. At the GNM we typically have 
>> regular instances of E41, which in my eyes follows the CIDOC CRM better, so 
>> I would love to see this in the best practice.
>> 
>> Best,
>> 
>> Mark Fichtner
>> 
>> 2018-09-04 21:29 GMT+02:00 Robert Sanderson > >:
>> Hi Detlev,
>> 
>>  
>> 
>> Apologies, I meant that the pattern makes it more complicated to understand, 
>> as opposed to it being ambiguous in the data (which would be much worse!). 
>> More difficult for a human rather than for the machine :)
>> 
>>  
>> 
>> For example, in JSON-LD, it would result in
>> 
>>  
>> 
>> {
>> 
>>   “P1_is_identified_by”: [
>> 
>>   “uri-as-string”,
>> 
>>   {
>> 
>>  “@id”: “uri-as-identifier”
>> 
>>   }
>> 
>>   ]
>> 
>> }
>> 
>>  
>> 
>> Which then makes developers cross, as there are mixed data types in the 
>> array, and the current specification doesn’t allow the string to be 
>> expressed in an object with only @value as a key.
>> 
>>  
>> 
>> Currently that would be the simpler compaction of:
>> 
>>  
>> 
>> {
>> 
>>   “P1_is_identified_by: [
>> 
>>   “uri-as-identifier”
>> 
>>   ]
>> 
>> }
>> 
>>  
>> 
>> Because P1 can only ever have a resource as its object.
>> 
>>  
>> 
>> Or (if you don’t care for the singleton 

Re: [Crm-sig] Issue: Solution for Dualism of E41 Appellation and rdfs:label

[Martin Doerr]

Dear All,

Firstly, apologies, the RDF was wrong, it was intended to be P1 is 
superproperty of rdfs:label.


Semantically, the range of rdfs:label, when used, is ontologically an 
Appellation in the sense of the CRM.


I agree with George, that all RDF nodes should have a human readable 
label. They name the thing, even if it is a technical node.
I would find it confusing to say, labels are not to be queried, only to 
be read, and the "real" names must have a URI,

regardless weather I have more to say about it.

I am really not a fan of punning, we definitely forbid it in the CRM.

The point with Appellations is that some, the simple ones, can directly 
be represented in the machine, or be outside. The solution to assign a 
URI in all cases, and then a value or label, does not make the world 
easier. It is extremely bad performance. We talk here about 
implementation, not about ontology.
You get simply a useless explosion of the graph for a purpose of 
theoretic purity.


Those claiming confusing should be more precise. Has someone looked at 
query benchmarks? Has someone looked at graphical representations of RDF 
graphs. Do they really look better?


So either we either ignore the issue, and write queries that collect 
names either via P1, URI and a value/label, or via a label, because this 
is where names appear in RDF, we make no punning, but our queries 
implement exactly this meaning. So, we are not better, but do as if we 
wouldn't know.


Or, we describe the fact by punning, have one superproperty for all 
cases, which we can query, and stop thereby the discussion if labels are 
allowed or not, and how they relate to appellations. The punning comes 
in, because the range of the superproperty must comprise the ranges of 
the subproperties. We can play a bit more, make the punning with a 
superproperty of P1, and have both P1 and rdfs:label subproperties of 
it, if this is preferred.
The solution I describe is just a logical representation of the 
situation, not creating a different situation. It just says that names 
can be complex objects or simple literals.


The problem is, that the RDF literals do have meaning beyond being 
symbol sequences.


The punning does not introduce the problem. With or without, the queries 
have to cope with names in either form.
This holds similarly for space primitives and large geometry files, for 
short texts and equivalent files etc.


Opinions?

Best

Martin


--
--
 Dr. Martin Doerr  |  Vox:+30(2810)391625|
 Research Director |  Fax:+30(2810)391638|
   |  Email: mar...@ics.forth.gr |
 |
   Center for Cultural Informatics   |
   Information Systems Laboratory|
Institute of Computer Science|
   Foundation for Research and Technology - Hellas (FORTH)   |
 |
   N.Plastira 100, Vassilika Vouton, |
GR70013 Heraklion,Crete,Greece   |
 |
 Web-site: http://www.ics.forth.gr/isl   |
--